O que faz um desenvolvedor backend? Da requisição à resposta

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 recomenda verificar as permissões em cada requisição.

Essas verificações fazem parte do trabalho backend. A visão cliente-servidor da MDN 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.

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 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 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.

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 e seu identificador. Um conflito de disponibilidade pode usar 409 Conflict, 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.

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. 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. 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.