System Design/02 - Componentes/Databases2 min
Replication
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Manter cópias do dado em mais de um nó. Resolve dois problemas: escalar leitura e sobreviver à perda de um nó.
Topologias
| Topologia | Escritas | Nota |
|---|---|---|
| Single-leader | Só no líder | O modelo dominante; simples e suficiente |
| Multi-leader | Em vários nós | Multi-região; exige resolver conflito |
| Leaderless | Em qualquer nó | Quórum (Dynamo, Cassandra) |
Síncrona vs assíncrona
| Síncrona | Assíncrona | |
|---|---|---|
| O líder espera a réplica | Sim | Não |
| RPO | Zero | > 0 — perde o que não replicou |
| Latência de escrita | Alta | Baixa |
| Se a réplica cair | A escrita trava | Segue normalmente |
Semi-síncrona é o meio-termo usual: espera uma réplica confirmar, não todas.
Quórum
Com N réplicas, escrever em W e ler de R: se W + R > N, a leitura enxerga a escrita mais recente. N=3, W=2, R=2 é a configuração clássica.
Trade-offs
Replicação escala leitura, não escrita — toda escrita continua passando pelo líder (ou por todos, no leaderless). Confundir isso é o erro mais comum: adicionar réplicas para resolver gargalo de escrita não funciona, e ainda aumenta a carga de replicação no líder.
Lag de replicação produz anomalias que a aplicação sente:
| Anomalia | Sintoma |
|---|---|
| Read-your-writes | Você escreve e não vê o próprio dado |
| Monotonic reads | O tempo "anda para trás" entre duas leituras |
| Consistent prefix | Você vê a resposta antes da pergunta |
As correções são pontuais: ler do líder por alguns segundos após uma escrita, ou fixar o usuário numa réplica.
O trade-off de durabilidade é o mais consequente. Com replicação assíncrona, um Fail-Over promove uma réplica que não tem as últimas transações — e elas se perdem, mesmo tendo sido confirmadas ao cliente. Essa decisão é tomada na configuração, muito antes do incidente.
Exemplo prático
Uma aplicação com razão leitura:escrita de 90:10 coloca três réplicas de leitura. As leituras se distribuem, as escritas continuam no líder — e o sistema aguenta quase 4x mais tráfego.
Aí aparece o bug: o usuário edita o perfil, a página recarrega e mostra o dado antigo. A escrita foi ao líder, a leitura foi a uma réplica atrasada em 200 ms.
A correção não é abandonar réplicas. É read-your-own-writes: por alguns segundos após uma escrita, as leituras daquele usuário vão ao líder. O resto do tráfego continua distribuído — o custo é pago só por quem acabou de escrever.
Relacionado
Parte de Databases · roadmap.sh/system-design