Networking para Engenheiros de Backend

Sistemas de backend são projetados para receber requisições, executar lógica e retornar respostas. Na prática, essas requisições geralmente se originam de outras máquinas, e não do mesmo computador onde o backend está em execução.

Quando um usuário interage com uma aplicação web ou mobile, o dispositivo dele envia uma requisição pela internet para um servidor remoto. Essa requisição passa por vários componentes de rede antes de chegar à aplicação de backend.

Sistemas de backend também se comunicam internamente. Um serviço pode chamar outro serviço, consultar um servidor de banco de dados ou enviar requisições para APIs externas. Todas essas interações acontecem por meio de uma rede.

Por causa disso, muitos problemas de sistema se originam do comportamento da rede, e não do código da aplicação. Chamadas de API lentas podem ser causadas por latência de rede, conexões interrompidas podem interromper requisições, e tentativas de repetição costumam ocorrer quando as respostas não chegam a tempo.

Entender como as máquinas se comunicam por redes ajuda os engenheiros a raciocinar sobre desempenho, confiabilidade e cenários de falha em sistemas distribuídos.

Quando uma aplicação cliente envia uma requisição para um sistema de backend, várias etapas de rede ocorrem antes mesmo de o código de backend começar a ser executado.

O processo normalmente começa com um nome de domínio como api.example.com. Computadores não conseguem se comunicar diretamente usando nomes de domínio, então o cliente primeiro faz uma consulta DNS para determinar o endereço IP do servidor de destino.

Depois que o endereço IP é conhecido, o cliente estabelece uma conexão TCP com essa máquina. Essa conexão cria um canal confiável para enviar dados entre o cliente e o servidor.

Após a conexão ser estabelecida, o cliente envia uma requisição HTTP. Essa requisição contém o método, os headers e quaisquer dados necessários para o sistema de backend.

Em arquiteturas modernas, a requisição frequentemente passa por um load balancer antes de chegar ao application server. O load balancer decide qual máquina de backend deve tratar a requisição, ajudando a distribuir o tráfego entre vários servidores.

Por fim, a requisição chega ao application server, onde a aplicação de backend a processa, executa a lógica de negócio e gera uma resposta que retorna ao cliente.

Os computadores se comunicam entre si usando endereços IP numéricos, como 142.250.72.14. No entanto, os humanos interagem com serviços por meio de nomes de domínio como api.example.com, porque eles são mais fáceis de lembrar.

O Domain Name System (DNS) atua como um diretório distribuído que mapeia esses nomes de domínio para seus respectivos endereços IP. Quando um cliente quer contatar um servidor usando um nome de domínio, ele envia uma consulta DNS para determinar o endereço IP correto.

Esse processo de consulta pode envolver vários servidores DNS trabalhando juntos. O sistema eventualmente retorna o endereço IP associado ao domínio solicitado, para que o cliente saiba para onde enviar a requisição.

Para melhorar a eficiência, as respostas DNS geralmente são armazenadas em cache por sistemas operacionais, navegadores e servidores intermediários. Se uma consulta recente já existir no cache, o sistema pode reutilizar o endereço IP armazenado em vez de fazer uma nova consulta DNS.

DNS é um componente fundamental da infraestrutura da internet. Sem ele, usuários e aplicações precisariam lembrar e gerenciar manualmente endereços IP numéricos para cada serviço com o qual interagem.

Depois que um cliente conhece o endereço IP de um servidor, ele ainda precisa determinar qual aplicação nesse servidor deve tratar a requisição. É aqui que as portas são usadas.

Uma porta é um endpoint lógico de comunicação em uma máquina. Enquanto o endereço IP identifica o próprio host, a porta identifica o serviço específico que está escutando conexões de entrada.

Por exemplo, um servidor web normalmente escuta na porta 80 para tráfego HTTP ou na porta 443 para tráfego HTTPS. Bancos de dados e outros serviços também usam portas conhecidas. O PostgreSQL normalmente escuta na porta 5432, enquanto o Redis frequentemente é executado na porta 6379.

Como as portas separam os serviços, uma única máquina pode executar muitas aplicações diferentes ao mesmo tempo. Um servidor backend pode hospedar uma API HTTP, um banco de dados e um serviço de cache ao mesmo tempo, cada um vinculado a uma porta diferente.

Juntos, a combinação de um endereço IP e um número de porta define um endpoint de rede. Esse endpoint identifica de forma única onde uma requisição deve ser entregue.

Transmission Control Protocol (TCP) é um dos principais protocolos de comunicação usados na internet. Ele foi projetado para fornecer comunicação confiável entre duas máquinas.

Antes que qualquer dado seja transmitido, o TCP estabelece uma conexão por meio de um processo chamado three-way handshake. O cliente começa enviando uma mensagem SYN para o servidor. O servidor responde com SYN-ACK para confirmar a solicitação e sinalizar que está pronto. Em seguida, o cliente envia uma mensagem ACK confirmando a conexão. Depois dessa troca, ambas as máquinas podem começar a enviar dados.

O TCP divide os dados em unidades menores chamadas pacotes e os transmite pela rede. Como as redes podem perder ou reordenar pacotes, o TCP inclui mecanismos que detectam dados ausentes e retransmitem pacotes, se necessário.

Outra característica importante do TCP é a ordenação dos pacotes. Mesmo que os pacotes cheguem em uma ordem diferente daquela em que foram enviados, o TCP os reagrupa corretamente antes de entregar os dados à aplicação.

Esses mecanismos tornam o TCP confiável para aplicações que exigem transferência precisa de dados, como requisições web, comunicação com bancos de dados e a maioria das interações com APIs.

TCP e UDP são dois protocolos de transporte importantes usados para comunicação entre máquinas, mas resolvem problemas diferentes.

TCP (Transmission Control Protocol) foi projetado para confiabilidade. Ele estabelece uma conexão entre duas máquinas, garante que os pacotes cheguem com sucesso, retransmite dados perdidos e assegura que os pacotes sejam entregues na ordem correta. Por causa dessas garantias, o TCP é usado em aplicações em que a precisão é crítica.

Muitos sistemas de backend dependem de TCP. Protocolos da web como HTTP funcionam sobre TCP, e conexões de banco de dados também normalmente usam TCP porque a integridade dos dados é essencial.

UDP (User Datagram Protocol) adota uma abordagem diferente. Ele não estabelece uma conexão e não garante entrega nem ordenação. Em vez disso, simplesmente envia pacotes ao destino o mais rápido possível.

Como o UDP remove a sobrecarga de confiabilidade, ele é mais rápido e mais leve. Isso o torna adequado para aplicações em que alguma perda ocasional de pacotes é aceitável, como streaming de vídeo em tempo real, jogos online e muitas consultas DNS.

A compensação entre TCP e UDP é, fundamentalmente, entre confiabilidade e velocidade. Os sistemas escolhem o protocolo que melhor atende às necessidades da aplicação.

HTTP (Hypertext Transfer Protocol) é o protocolo da camada de aplicação usado pela maioria dos sistemas web. Ele define a estrutura das mensagens trocadas entre clientes e servidores.

A comunicação segue um modelo de requisição–resposta. Um cliente envia uma requisição HTTP descrevendo o que deseja fazer, e o servidor processa essa requisição e retorna uma resposta HTTP.

As requisições incluem vários componentes. O método HTTP indica a ação pretendida, como GET para recuperar dados ou POST para enviar novos dados. A requisição também inclui cabeçalhos que carregam metadados como tokens de autenticação, tipo de conteúdo ou instruções de cache.

Depois de processar a requisição, o servidor retorna uma resposta. A resposta inclui um código de status que indica o resultado da operação. Por exemplo, 200 OK indica sucesso, enquanto códigos como 404 ou 500 sinalizam erros.

HTTP fornece a linguagem padronizada que permite que navegadores, aplicativos móveis e serviços de backend se comuniquem de forma consistente pela internet.

Latência se refere ao tempo que uma requisição leva para viajar de um cliente até um servidor e para a resposta retornar. Em sistemas distribuídos, até operações simples envolvem várias etapas que contribuem para esse atraso.

Primeiro, a requisição precisa viajar pela rede. Os dados passam por roteadores, switches e, às vezes, vários data centers antes de chegar ao servidor de destino. A distância geográfica por si só pode introduzir atrasos perceptíveis, porque os sinais levam tempo para se propagar por longas distâncias.

Depois que a requisição chega ao servidor, o sistema de backend precisa processá-la. Isso pode envolver executar a lógica da aplicação, realizar validações ou executar outras operações internas.

Muitas requisições também dependem de outros sistemas, como bancos de dados, caches ou APIs externas. Cada dependência adicional introduz seu próprio tempo de processamento e latência de rede.

Outros fatores, como congestionamento de rede ou serviços sobrecarregados, podem aumentar ainda mais a latência. Como sistemas distribuídos dependem de muitos componentes interconectados, pequenos atrasos em vários pontos podem se acumular e resultar em tempos de resposta perceptíveis.

A comunicação em rede é inerentemente não confiável. As requisições podem sofrer atraso, as conexões podem cair e os serviços podem deixar de responder. Por isso, os sistemas de backend devem ser projetados para lidar com chamadas de rede lentas ou com falha de forma segura.

Uma proteção comum é o timeout. Um timeout define o tempo máximo que um sistema vai esperar por uma resposta. Se a resposta não chegar dentro desse intervalo, a requisição é abortada e o sistema segue em frente.

Retries são outra estratégia comum. Quando uma requisição falha por causa de um problema temporário de rede, o sistema pode tentar a requisição novamente após um pequeno atraso. Isso pode ajudar a se recuperar de falhas transitórias, como interrupções breves na rede.

No entanto, os retries precisam ser controlados com cuidado. Se muitos serviços tentarem repetidamente requisições com falha, eles podem sobrecarregar os sistemas downstream e criar falhas em cascata, em que um serviço lento causa indisponibilidades generalizadas.

Por esse motivo, os sistemas modernos de backend configuram cuidadosamente timeouts, retries e estratégias de tratamento de falhas para manter a confiabilidade mesmo quando partes da rede se comportam de forma imprevisível.

À medida que as aplicações crescem, um único servidor muitas vezes não consegue lidar com todo o tráfego de entrada. Para atender mais usuários e manter o desempenho, os sistemas executam vários servidores de backend que fornecem a mesma funcionalidade.

Um balanceador de carga atua como ponto de entrada para as requisições de entrada. Em vez de os clientes se conectarem diretamente a servidores individuais, eles enviam requisições ao balanceador de carga. O balanceador de carga então decide qual servidor de backend deve processar cada requisição.

Essa distribuição espalha o tráfego entre os servidores, evitando que qualquer máquina fique sobrecarregada. Diferentes algoritmos podem ser usados, como distribuição round-robin, roteamento com menos conexões ou roteamento baseado em latência.

O balanceamento de carga também melhora a tolerância a falhas. Se um servidor ficar indisponível, o balanceador de carga pode direcionar o tráfego para outros servidores saudáveis para que o sistema continue funcionando.

Essa abordagem permite escalabilidade horizontal, em que os sistemas aumentam a capacidade adicionando mais máquinas em vez de fazer upgrade de um único servidor. A escalabilidade horizontal é uma estratégia fundamental para construir sistemas de backend grandes e confiáveis.