𝗢𝘀 𝗦𝗲𝘂 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗘𝘀𝗰𝗮𝗹á𝘃𝗲𝗹 é 𝘂𝗺𝗮 𝗕𝗼𝗺𝗯𝗮 𝗥𝗲𝗹ó𝗴𝗶𝗼?
Muitos desenvolvedores pensam que escalar significa adicionar mais servidores. Eles usam ferramentas cloud-native e bancos de dados distribuídos para lidar com mais usuários. Mas isso frequentemente cria um novo problema. Você não está construindo uma fortaleza. Você está construindo um castelo de cartas.
Escalar horizontalmente sem um plano apenas expande seus domínios de falha. Se o seu sistema carece de tolerância a falhas, um pequeno erro pode derrubar tudo.
Você deve focar em duas áreas para construir um sistema real:
- Tolerância a Falhas Adicionar mais instâncias não evita falhas correlacionadas. Você deve isolar as falhas para que elas não se espalhem.
- Use múltiplas Availability Zones (Zonas de Disponibilidade).
- Distribua pequenas instâncias de serviço em vez de usar duas grandes.
- Use consenso baseado em quorum, como Raft ou Paxos. Isso evita cenários de split-brain, onde duas regiões pensam que são o líder.
- Use mecanismos de fencing para desligar regiões com falhas durante uma partição de rede (network split).
- Consistência de Dados A consistência eventual é ótima para velocidade. Ela é terrível para lógica de negócios crítica. Para pagamentos ou saldos de conta, você precisa de consistência forte.
- Não dependa de transações distribuídas que tornam seu sistema lento.
- Use o Transactional Outbox Pattern.
- Escreva seus dados principais e uma tarefa de "outbox" em seu banco de dados local em uma única transação.
- Use um relayer para enviar essas tarefas para uma fila de mensagens (message queue).
- Garanta que seus serviços downstream sejam idempotentes para que possam lidar com mensagens duplicadas de forma segura.
A verdadeira escalabilidade trata de resiliência. Se você ignorar esses princípios, estará apenas construindo um parquinho maior para falhas. Projete para o pior cenário hoje mesmo.
Fonte: https://dev.to/prabashanadev/is-your-scalable-backend-a-ticking-time-bomb-6o7