Fala pessoal.
Hoje, dando sequência no tema Fundamentos e Arquitetura de TI, vamos falar sobre o Paradigma da Computação Distribuída - Desafios de Consistência e Tolerância a Falhas.
A computação distribuída é um dos pilares fundamentais da arquitetura moderna em TI. À medida que sistemas crescem em escala e complexidade, torna-se impossível manter toda a lógica e dados centralizados em um único servidor ou em um único processo. Em vez disso, aplicações passam a existir em múltiplas máquinas, múltiplas zonas de disponibilidade e até múltiplas regiões. Esse novo paradigma — distribuído por natureza — traz poder, performance e resiliência, mas também impõe desafios significativos, especialmente na consistência de dados, disponibilidade, latência e tolerância a falhas. Para entender esses desafios, três conjuntos de conceitos são essenciais:
- o Teorema CAP,
- os modelos de consistência,
- os algoritmos de consenso.
1. O Teorema CAP: o dilema central da computação distribuída
O Teorema CAP afirma que em qualquer sistema distribuído é impossível garantir simultaneamente os três atributos:
-
C – Consistência: todos os nós veem os mesmos dados ao mesmo tempo.
-
A – Disponibilidade: o sistema sempre responde, mesmo que a resposta não seja a mais atual.
-
P – Tolerância à Partição: o sistema continua funcionando mesmo quando há falhas na comunicação entre nós.
O teorema diz que, quando ocorre uma partição na rede (P), o sistema precisa escolher entre C e A.
E como falhas de rede são inevitáveis, P não é opcional. Portanto, arquiteturas reais precisam escolher seu foco:
✔ Sistemas CP (Consistência + Partição)
Priorizam que todos os nós tenham o mesmo dado, mesmo que isso custe disponibilidade.
Exemplos:
-
Bancos distribuídos como HBase, Google Bigtable
-
Serviços críticos de controle
✔ Sistemas AP (Disponibilidade + Partição)
Priorizam sempre responder, mesmo com dados possivelmente desatualizados.
Exemplos:
-
DynamoDB
-
Cassandra
-
Sistemas de cache distribuído
Esse equilíbrio afeta diretamente decisões arquiteturais modernas. Uma aplicação pode combinar CP e AP em diferentes partes do sistema, usando a estratégia conhecida como polyglot persistence.
2. Modelos de Consistência: Forte, Eventual e Variantes
Nem todo sistema distribuído precisa oferecer o mesmo tipo de consistência. Os modelos determinam como e quando os dados replicados se tornam visíveis nos diferentes nós.
✔ Consistência Forte
Garantia de que toda leitura retorna o dado mais recente.
É como se houvesse "um único banco".
Exemplo na prática:
-
Atualizar um registro no RDS Multi-AZ e toda leitura subsequente refletir imediatamente essa mudança.
-
Bancos CP, como o Zookeeper ou Etcd.
Adequado para:
-
Transações bancárias
-
Controle de estoque crítico
-
Sistemas financeiros
✔ Consistência Eventual
Os dados eventualmente se tornam consistentes, mas podem apresentar diferentes versões por um tempo.
Exemplo clássico: sistemas AP baseados em replicação assíncrona.
Exemplos práticos:
-
Amazon S3
-
DynamoDB (modo eventual)
-
Caches distribuídos como Redis Cluster
Adequado para:
-
Sistemas de alta disponibilidade
-
Requisições massivas
-
Leituras não críticas
✔ Consistência Monotônica, Read Your Writes, e outras variantes
Alguns sistemas implementam variações para equilibrar performance e previsibilidade:
-
Read-Your-Writes: você sempre lê a sua própria escrita mais recente.
-
Monotonic Reads: leituras não voltam no tempo.
-
Causal Consistency: respeita dependências lógicas entre operações.
Esses modelos aparecem principalmente em bancos modernos, como:
-
MongoDB,
-
CosmosDB,
-
Cassandra,
-
e mecanismos de replicação do PostgreSQL.
3. Algoritmos de Consenso: Paxos, Raft e o problema de concordar
Em um sistema distribuído, máquinas podem falhar, ficar lentas ou retornar dados diferentes. Como garantir que todos concordem sobre o mesmo estado?
É aqui que entram os algoritmos de consenso.
Esses algoritmos resolvem problemas como:
-
Qual é a versão correta dos dados?
-
Qual nó é o líder?
-
Como garantir que uma operação seja registrada mesmo após falhas?
✔ Paxos
Um dos algoritmos mais antigos e complexos, garante consenso mesmo em cenários com nós lentos e falhos.
Usado por sistemas como:
-
Google Spanner
-
Sistemas distribuídos internos da Meta e Amazon
Paxos é poderoso, porém difícil de implementar corretamente, por isso originou variantes e frameworks.
✔ Raft
Criado como alternativa mais compreensível ao Paxos.
Hoje é amplamente adotado por tecnologias modernas:
-
Etcd (fundamento do Kubernetes)
-
Consul
-
TiDB
-
CockroachDB
O Raft funciona elegendo um líder, que coordena a replicação dos dados e garante consistência entre os nós.
No Kubernetes, por exemplo:
-
O estado do cluster (pods, services, deployments) é mantido no Etcd, que usa Raft para garantir confiabilidade.
Isso significa que até o Kubernetes depende diretamente de um algoritmo de consenso para funcionar.
Exemplo com Raft:
4. Tolerância a falhas: o coração da computação distribuída
Nenhum sistema distribuído é perfeito:
-
máquinas falham,
-
nós perdem conexão,
-
pacotes se perdem,
-
latência varia,
-
regiões podem cair.
Por isso, arquiteturas modernas precisam planejar:
-
Replicação de dados
-
Failover automático
-
Detecção de líder
-
Retries e timeouts
-
Circuit Breakers
-
Backpressure e isolamento
-
Observabilidade e tracing distribuído
Exemplo real com AWS:
Um sistema resiliente pode usar:
5. Conclusão: o preço da distribuição é a complexidade — e entender os fundamentos é obrigatório
A computação distribuída é inevitável na era da nuvem, dos microsserviços, do Kubernetes e da escala global. Porém, com ela surgem desafios profundos: garantir que os nós concordem, que os dados sejam replicados com segurança, que o sistema permaneça disponível e que usuários nunca percebam falhas internas.
O Teorema CAP nos obriga a fazer escolhas.
Os modelos de consistência nos mostram diferentes garantias.
Os algoritmos de consenso nos permitem manter ordem no caos.
Entender esses fundamentos é essencial para projetar sistemas robustos, escaláveis e confiáveis em ambientes reais — especialmente em nuvem.
:wq!













