DEV Community

Brenda Valadares
Brenda Valadares

Posted on

Resumindo Projetando Sistemas Distribuídos: Conceitos Importantes

O livro Projetando Sistemas Distribuídos, de Brendan Burns, apresenta os fundamentos essenciais para lidar com a complexidade desses ambientes. No capítulo 2 - Conceitos Importantes dos Sistemas Distribuídos, ele traz conceitos práticos que ajudam desenvolvedores a projetar sistemas escaláveis, confiáveis e resilientes. A seguir, um resumo dos principais conceitos:

APIs e RPC

As APIs definem o contrato de comunicação entre serviços: quais operações podem ser chamadas e como os dados devem ser trocados.
O RPC (Remote Procedure Call) é a técnica que permite executar essas chamadas entre servidores remotos como se fossem locais. Em resumo, a API descreve o que pode ser feito e o RPC é um dos meios de fazer isso acontecer pela rede.

Latência
Latência é o tempo entre o envio de uma requisição e a chegada da resposta.
Em sistemas distribuídos, esse tempo pode aumentar, pois a comunicação acontece entre várias máquinas. Quanto maior a latência, pior a experiência do usuário. Por isso, monitorar e otimizar a latência é essencial para garantir rapidez e fluidez no sistema.

Percentis
Médias podem enganar. Imagine que 90% das requisições são rápidas, mas 10% demoram muito. A média pode parecer “boa”, mas os usuários que caírem nesses 10% terão má experiência. É aí que entram os percentis:

  • p95 → mostra o tempo em que 95% das requisições foram concluídas.
  • p99 → mostra o tempo em que 99% das requisições foram concluídas. Ou seja: eles ajudam a identificar problemas que ficam “escondidos” pela média.

Confiabilidade
Um sistema distribuído deve ser confiável, ou seja, continuar funcionando mesmo quando partes dele falham.
Isso é alcançado com estratégias como:

  • Replicação: manter cópias de dados em mais de um lugar.
  • Redundância: ter mais de uma instância do mesmo serviço.
  • Retries: repetir operações que falharam temporariamente.

Idempotência
A idempotência garante que executar a mesma operação várias vezes tenha sempre o mesmo efeito.
Exemplo: se um usuário clicar duas vezes no botão de pagamento, o sistema precisa registrar apenas uma cobrança. Esse comportamento evita erros graves em sistemas que recebem requisições repetidas.

Semântica da Entrega
Quando falamos de mensagens em sistemas distribuídos, é importante definir como elas serão entregues:

  • At-most-once → a mensagem pode se perder, mas nunca será duplicada.
  • At-least-once → a mensagem sempre chega, mas pode ser entregue mais de uma vez.
  • Exactly-once → a mensagem chega apenas uma vez (modelo ideal, porém difícil de implementar na prática).

Integridade Relacional
A integridade relacional garante que os dados guardem relações corretas entre si.
Exemplo: um pedido só faz sentido se estiver vinculado a um cliente existente. Sem essa garantia, o sistema poderia armazenar pedidos “órfãos”, sem referência a quem os fez.

Consistência de Dados
Manter os dados consistentes em diferentes partes de um sistema distribuído é um dos maiores desafios. Existem dois modelos principais:

  • Consistência forte: todos os nós do sistema enxergam a mesma informação imediatamente. Ideal para operações críticas (como transferências bancárias).
  • Consistência eventual: diferentes partes do sistema podem ver informações diferentes por algum tempo, mas os dados se alinham depois. É comum em sistemas que priorizam alta disponibilidade. A escolha do modelo depende do equilíbrio entre precisão, desempenho e disponibilidade.

Orquestração e Kubernetes
Gerenciar muitos serviços distribuídos manualmente seria inviável. A orquestração automatiza tarefas como deploy, escalabilidade e monitoramento.

O Kubernetes é a principal ferramenta de orquestração hoje. Ele gerencia containers, distribui a carga de trabalho e mantém o sistema funcionando mesmo diante de falhas.

Verificações de Integridade
As health checks monitoram se um serviço está funcionando corretamente. No Kubernetes, isso é feito principalmente de duas formas:

  • Liveness: confirma se a aplicação está viva. Se falhar, o Kubernetes reinicia o serviço.
  • Readiness: confirma se a aplicação está pronta para receber requisições. Se não estiver, o tráfego não é direcionado para ela. Essas verificações mantêm o sistema saudável e evitam que usuários sejam afetados por instâncias com problemas.

Top comments (0)