# O que faz um desenvolvedor backend? Da requisição à resposta
Acompanhe uma reserva de livro para entender o trabalho backend: receber pedidos, aplicar regras, proteger dados, usar o banco e investigar falhas.
Por Bruno Rana
Publicado em: 2026-11-04
Atualizado em: 2026-11-04
Artigo original: https://buildrun.com.br/blog/o-que-faz-desenvolvedor-backend/
O backend recebe solicitações, aplica regras e acessa dados antes de devolver o resultado.
Quando você começa a pesquisar sobre backend, encontra uma lista de tecnologias antes de entender o trabalho. Java, banco de dados, API, servidor. Os nomes aparecem juntos, mas ainda falta perceber o que você faria com eles.
**O trabalho de backend é transformar um pedido em uma operação confiável:** verificar a identidade e as permissões de quem pediu, aplicar as regras do sistema, consultar ou alterar dados e devolver uma resposta. Depois que a aplicação está no ar, o trabalho continua na investigação de falhas, na melhoria do desempenho e nas mudanças de comportamento.
Você não precisa dominar essas responsabilidades agora. Primeiro vale entender como elas se conectam. Isso dá sentido ao estudo das ferramentas e ajuda a perceber se gosta desse tipo de problema.
## O clique vira um pedido que o servidor precisa entender
O **frontend** apresenta a interface e seus comportamentos. O **backend**, em uma aplicação web, executa operações em um servidor: um programa que recebe solicitações pela rede, rodando em uma máquina preparada para atendê-las. Um mesmo profissional pode trabalhar nas duas partes, mas as responsabilidades precisam continuar claras.
Para que essas partes se comuniquem, o backend oferece uma **API**: uma interface que define quais operações outro programa pode solicitar, quais dados deve enviar e que respostas pode receber. Uma rota é um dos pontos de acesso dessa interface.
Para acompanhar essa passagem, vamos usar uma reserva de livro. Você escolhe um exemplar no catálogo e toca em “Reservar”. A tela envia uma **requisição HTTP**, uma mensagem usando o protocolo comum da web. A aplicação poderia oferecer a rota `POST /reservas`: o método `POST` solicita a criação da reserva, enquanto `/reservas` identifica o recurso. O pedido informa o exemplar escolhido, aqui o número 42.
Receber essa mensagem ainda não significa aceitar a reserva. O backend confere o formato da entrada e verifica quem fez o pedido. **Autenticação** trata da identidade; **autorização**, da permissão para realizar a ação. Uma conta pode ser reconhecida pelo sistema e, mesmo assim, não ter acesso a determinada operação.
Por isso, a identidade deve vir do mecanismo de autenticação validado pelo servidor. Aceitar livremente um campo com o nome de outra pessoa permitiria agir em nome dela. Esconder um botão também não protege a operação: uma requisição pode ser enviada sem a interface oficial. A [orientação de autorização da OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recomenda verificar as permissões em cada requisição.
Essas verificações fazem parte do trabalho backend. A [visão cliente-servidor da MDN](https://developer.mozilla.org/pt-BR/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview) explica a troca de solicitações e respostas que sustenta esse percurso.
## A regra de negócio decide se a reserva pode acontecer
**Regra de negócio** é uma condição do problema que o programa atende. “Cada pessoa pode ter até duas reservas ativas” é uma regra da nossa biblioteca. “O campo precisa conter um número inteiro” é uma validação do formato da entrada. As duas importam, mas respondem perguntas diferentes.
Na biblioteca do exemplo, a pessoa precisa ter cadastro ativo, pode manter no máximo duas reservas e só pode reservar um exemplar disponível. Essas condições vêm do funcionamento da biblioteca. Você conversa com quem conhece a operação, esclarece exceções e transforma o acordo em comportamento verificável.
| Situação da conta | Exemplar 42 | Resultado esperado |
| --- | --- | --- |
| Cadastro ativo e uma reserva | Disponível | Criar a segunda reserva |
| Cadastro ativo e duas reservas | Disponível | Recusar por limite atingido |
| Cadastro inativo | Disponível | Recusar sem alterar dados |
| Cadastro ativo e nenhuma reserva | Já reservado | Informar indisponibilidade |
Essa tabela vale mais do que começar escrevendo classes sem saber o resultado esperado. Ela também revela dúvidas: reservas expiradas contam no limite? Por quanto tempo o exemplar fica separado? Cancelar libera a vaga imediatamente? As respostas mudam a implementação e os testes.
As condições precisam ser conferidas no backend. A mesma reserva deve obedecer às regras mesmo quando o pedido chega por outra interface.
Testar essas situações é uma atividade cotidiana. Um teste automatizado prepara uma condição, executa a operação e compara o resultado com o esperado. Se uma mudança permitir uma terceira reserva por engano, o teste deve denunciar a diferença.
## Gravar os dados também exige proteger a decisão
O **banco de dados** mantém informações que precisam sobreviver ao encerramento do programa: exemplares, pessoas e reservas. O backend usa consultas para encontrar dados e comandos para modificá-los. SQL é uma linguagem utilizada para essas operações em bancos relacionais, que organizam dados em tabelas relacionadas.
Suponha que o sistema guarde a reserva em uma tabela e a disponibilidade do exemplar em outra. Confirmar o pedido exige atualizar as duas de forma coerente. Se apenas a reserva for gravada, mas o exemplar continuar disponível, uma próxima consulta poderá apresentá-lo como livre. A forma de organizar esses dados já é uma decisão de desenvolvimento.
Uma **transação** permite agrupar mudanças que devem ser confirmadas juntas ou desfeitas juntas. Ela ajuda a evitar um estado pela metade. O [tutorial de transações do PostgreSQL](https://www.postgresql.org/docs/18/tutorial-transactions.html) apresenta esse compromisso de tudo ou nada.
Mesmo com essa proteção contra gravações pela metade, ainda existe outra dificuldade. Dois pedidos podem disputar o mesmo exemplar quase ao mesmo tempo. As duas telas podem ter mostrado “disponível” antes do primeiro pedido terminar. Consultar a disponibilidade e depois salvar, sem coordenar essa disputa, pode gerar duas confirmações.
O backend precisa coordenar operações concorrentes. Uma implementação pode bloquear temporariamente os registros relevantes durante a decisão, além de aplicar restrições no banco. A [documentação de bloqueios do PostgreSQL](https://www.postgresql.org/docs/18/explicit-locking.html) explica esses mecanismos. Apenas colocar comandos dentro de uma transação não resolve automaticamente qualquer disputa.
O limite de reservas também merece proteção: duas solicitações simultâneas da mesma pessoa não podem ultrapassá-lo. O desenho precisa considerar as duas regras, testar a concorrência e tratar eventuais conflitos. Não estamos implementando esse controle aqui; estamos identificando um problema real que o profissional precisa resolver.
Disponibilidade na tela é uma fotografia anterior. A decisão final precisa proteger o exemplar e o limite da pessoa durante a gravação.
## A resposta precisa dizer o que realmente aconteceu
Depois da confirmação no banco, o servidor devolve uma resposta. Em nosso contrato, uma reserva criada pode retornar o status HTTP [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201) e seu identificador. Um conflito de disponibilidade pode usar [409 Conflict](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/409), acompanhado de uma mensagem que a interface consiga apresentar. São escolhas que o time deve documentar de forma consistente.
A tela usa essa resposta para mostrar o resultado. Se a reserva não aconteceu, não deve confirmar só porque o clique funcionou. Se houve falha interna, a mensagem também não deve expor senha, comando SQL ou detalhes privados.
Há um caso mais sutil: o banco confirmou a reserva, mas a conexão caiu antes da resposta chegar. Você tenta novamente porque não sabe se o primeiro pedido funcionou. O backend precisa de uma estratégia para reconhecer repetições e evitar duplicidade, conforme o contrato da operação. Desabilitar o botão durante o envio ajuda a experiência, mas não resolve sozinho esse problema.
Perceba como "fazer uma API" envolve mais do que abrir uma rota. O contrato precisa ligar entradas, resultados, permissões e comportamento diante de falhas. É esse acordo que permite ao frontend informar o que aconteceu sem adivinhar o estado do sistema.
## Boa parte do trabalho é entender o que saiu do esperado
No dia a dia, você pode receber um relato como “o sistema confirmou duas reservas para o mesmo exemplar”. Antes de mudar o código, precisa descobrir como isso aconteceu. Vai reproduzir a disputa, examinar os registros da aplicação e distinguir uma falha de regra de um problema na gravação. Depois da correção, adiciona um teste para perceber se o defeito voltar.
Outras tarefas envolvem discutir uma nova condição com a biblioteca, revisar código de um colega ou investigar lentidão. Você passa bastante tempo lendo, fazendo perguntas e conferindo hipóteses. Escrever código é parte desse processo, não uma atividade separada do entendimento do problema.
**Logs** são registros de eventos; **métricas** são medidas, como quantidade de erros e tempo das operações. Eles ajudam a observar o sistema, desde que evitem dados pessoais desnecessários e segredos. Publicar o programa começa outra responsabilidade, explorada no guia de [como colocar uma aplicação no ar](https://buildrun.com.br/blog/como-colocar-aplicacao-no-ar/).
Para experimentar esse raciocínio, desenhe as fichas de duas contas e de um único exemplar disponível. Simule os pedidos em sequência e anote o estado final. Depois faça os dois pedidos partirem do mesmo estado inicial. Localize o momento em que seria preciso impedir a segunda confirmação e explique sua solução. Esse exercício não implementa concorrência; ele ajuda a formular a regra que você terá de proteger.
Se esse tipo de decisão desperta sua curiosidade, o próximo passo pode ser uma [reserva implementada como projeto backend](https://buildrun.com.br/blog/portfolio-backend-alem-do-tutorial/). Em Java, comece pela regra e seus testes antes de acrescentar HTTP e banco. Se ainda estiver explorando possibilidades, compare também [a rotina de frontend, backend e dados](https://buildrun.com.br/blog/frontend-backend-ou-dados/). Você terá uma visão mais concreta do trabalho para orientar sua escolha.
As referências técnicas deste artigo foram consultadas em 04/11/2026. O cenário simplifica uma biblioteca real: não cobre multas, filas de espera, privacidade completa ou integração com sistemas externos.
