Fundamentos e Arquitetura de TI: O Paradigma da Computação Distribuída

                           

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:

1. o Teorema CAP,
2. os modelos de consistência,
3. 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

Exemplo com SQS (Python):

✔ 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:

Quando um nó falha, o sistema continua funcionando, porque o estado é replicado e mantido consistente pelo algoritmo de consenso.

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.

Abs e até a próxima.
:wq!