Replicação de dados: guia prático de System Design

Replicação de dados é a prática de manter cópias do mesmo banco em várias instâncias, com um leader concentrando as escritas e followers atendendo as leituras. Ela aumenta throughput e disponibilidade, mas introduz replication lag e riscos de failover. Antes de implementar, valide índices, connection pooling e cache — nem sempre você precisa de réplicas.

O que é replicação de dados e como funciona o modelo leader-based

Replicação de dados é manter o mesmo conjunto de dados em mais de uma instância do banco, para que leituras e falhas não dependam de um único servidor. No modelo mais comum, o leader-based replication, toda escrita passa pelo leader e é propagada aos followers, que atendem as leituras.

Imagine uma instância do PostgreSQL servindo uma aplicação. Quando você adiciona réplicas, o fluxo muda: creates, updates e deletes acontecem só no leader, enquanto reads vão para os followers. Cada mudança no leader é replicada para eles — sem essa propagação, as cópias ficariam obsoletas e a estrutura não serviria para nada.

Copiar um banco é fácil: um dump resolve. O desafio real é lidar com as mudanças contínuas, porque os dados nunca param de ser alterados em produção. Followers também aparecem na literatura como nodes ou read replicas — são termos equivalentes para a mesma coisa.

Existem outros dois modelos além do leader-based: multi-leader replication e leaderless replication. Eles têm usos reais, mas o leader-based é de longe o mais adotado no mercado e o ponto de partida para entender o tema.

Quando usar replicação de dados — e quando ela é exagero

Você deve considerar replicação de dados em quatro situações: aumentar o throughput de leitura, aproximar os dados do usuário, aumentar a disponibilidade e separar cargas transacionais de cargas analíticas. Fora disso, réplicas são custo, complexidade e curva de aprendizado sem retorno.

Aumento de throughput de leitura

Throughput é a quantidade de operações que o sistema suporta em um período. Se a aplicação precisa saltar de 50 mil para 150 mil requisições por segundo de leitura, réplicas ajudam a distribuir a carga. Mas atenção: segundo a experiência relatada pelo criador do conteúdo, Felipe Rocha do Full Stack Club, uma aplicação com 50 a 100 mil requisições por segundo frequentemente se comporta bem apenas com bons índices e connection pooling. Só depois de esgotar essas opções faz sentido falar em réplicas.

Latência geográfica

Se você tem usuários no Brasil e no Japão e um único banco na América do Sul, o usuário asiático sempre vai sofrer com a latência. Replicar followers para cada região resolve: cada usuário lê da réplica mais próxima. Antes, porém, avalie cache — para dados cacheáveis, uma CDN ou um cache regional costuma ser mais simples e barato. Se o dado não é cacheável, aí sim as réplicas entram.

Disponibilidade e separação de cargas

Com vários followers, a falha de um deles não derruba as leituras: o usuário lê de outra réplica. Já a separação entre dados transacionais e analíticos protege o banco de queries pesadas de relatório, que podem gargalar o sistema quando rodam junto com as operações dos usuários. Você pode dedicar um follower exclusivamente a queries analíticas.

Uma dúvida comum na comunidade — que aparece tanto no Bootcamp do Dev Doido quanto nas aulas do Gustavo Dev Doido sobre Crazystack Typescript — é exatamente essa: réplicas ou otimizações mais simples primeiro? A resposta dos dois lados converge: meça, indexe, faça pooling, considere cache, e só então replique.

Replicação assíncrona x síncrona: o trade-off central

A diferença entre replicação assíncrona e síncrona está em quando o leader confirma a escrita para o cliente. Na assíncrona, ele responde sucesso primeiro e replica depois; na síncrona, replica para os followers antes de confirmar. Esse detalhe define lag, latência e risco de perda de dados.

Replicação assíncrona

O leader processa a escrita, devolve sucesso ao cliente e, só então, propaga a mudança. A replicação normalmente leva menos de um segundo, mas pode chegar a minutos se os followers estiverem perto da capacidade máxima ou houver instabilidade de rede. É o modelo mais usado no mercado, porque as empresas preferem aceitar consistência eventual em troca de latência menor e mais disponibilidade.

Replicação síncrona

Aqui o leader replica a mudança para todos os followers antes de retornar sucesso. O ganho é consistência forte: o dado está em todas as réplicas quando o cliente recebe a confirmação. O custo é duplo. Primeiro, a latência soma o tempo de cada replicação — quatro réplicas a um segundo cada significam quatro segundos de espera. Segundo, e pior: se qualquer follower estiver fora, a escrita inteira falha e retorna erro ao usuário. Um sistema com várias réplicas e replicação síncrona pura para de funcionar quando uma única réplica cai.

O meio-termo: semisíncrona

Na semisíncrona, um follower é síncrono e os demais são assíncronos. Se a replicação para o follower síncrono falhar, o leader promove outro follower a síncrono e segue operando. Para quem precisa de consistência forte — um saldo bancário, por exemplo — essa abordagem reduz drasticamente o risco da síncrona pura.

Replication lag e consistência eventual: quando o dado some temporariamente

Replication lag é o intervalo entre a escrita no leader e a chegada do dado ao follower. Durante esse intervalo, o sistema opera com consistência eventual: o follower vai convergir, mas por um tempo pode retornar dados desatualizados.

O cenário clássico: o cliente cria um comentário e, um segundo depois, tenta lê-lo de um follower. Se a replicação levar três segundos, o comentário simplesmente não aparece. Para o usuário, parece que o sistema perdeu a escrita.

Se esse comportamento é tolerável pelos requisitos, não há nada a fazer — seguimos com a arquitetura assíncrona. Se não é, existem três mitigações conhecidas:

• Read after writes: quando o usuário lê dados que ele mesmo acabou de editar (o próprio perfil, por exemplo), o cliente direciona a leitura ao leader. Funciona bem quando a parcela editável de dados é pequena; se 90% do que está armazenado é editável, os followers deixam de ser usados.
• Leitura do leader por um intervalo: após uma escrita, todas as queries dos próximos 500 a 700 milissegundos vão ao leader, usando o tempo médio de replicação como referência.
• Monotonic reads: o usuário passa a ler sempre da mesma réplica, evitando o caso em que um comentário aparece em uma réplica e outro não.

Nenhuma dessas soluções é universal. Em entrevista, demonstrar que você conhece o problema e uma ou duas mitigações já te coloca à frente da maioria dos candidatos.

Failover: o que acontece quando follower ou leader caem

Failover é o processo de recuperação quando um node falha. Com follower, o problema é pequeno; com leader, o sistema precisa eleger um novo líder, e é aí que moram os riscos maiores — inclusive perda de dados.

Falha de follower: catchup recovery

Quando um follower volta de uma falha, ele compara seu próprio replication log com o do leader e aplica as diferenças que ficaram para trás. Esse processo é chamado de catchup recovery e não afeta os clientes, que continuam lendo das réplicas saudáveis.

Falha de leader: promoção e seus riscos

Os nodes trocam heartbeats periodicamente. Se o follower chama o leader e não recebe resposta dentro de um timeout configurável — 30 segundos, por exemplo — ele assume que o líder caiu e inicia a promoção: um follower é promovido a leader e as escritas passam a ser redirecionadas para ele.

Com replicação assíncrona, o leader antigo pode ter recebido uma escrita que nunca foi replicada. Exemplo concreto do vídeo: um usuário criado com ID 5 morre junto com o leader; o novo líder gera o ID 5 para outro usuário. Se um cache externo como o Redis já tinha o primeiro ID 5, o novo usuário pode receber os dados do antigo ao consultar o próprio perfil.

Se esse cenário for inaceitável para o seu contexto, desabilite o failover automático e faça a recuperação manualmente: alguém revisa os conflitos, resolve e promove o novo líder com downtime controlado. Já na replicação síncrona esse problema não existe, porque nenhuma escrita é confirmada sem estar em todas as réplicas.

Replication log: a fonte da verdade por trás de tudo

Todo banco de dados com replicação mantém um replication log, um log de apenas append que registra todas as operações de escrita. No PostgreSQL, esse log é o WAL. Ele é a fonte da verdade: a operação passa primeiro pelo log, depois pelo banco em si.

Tanto leader quanto followers possuem seu próprio log, e é comparando-os que o catchup recovery identifica o que ficou para trás. Os detalhes de implementação variam entre PostgreSQL, MySQL, SQL Server e outros, mas o conceito é o mesmo em todos. Se você quer ir a fundo, o livro Designing Data-Intensive Applications, de Martin Kleppmann, é a referência mais citada sobre o tema.

Decisão final: um roteiro para a entrevista e para o projeto

Em uma entrevista de System Design, a ordem certa é: requisitos primeiro, arquitetura depois. Pergunte onde a aplicação roda, qual disponibilidade ela exige, quantas requisições por segundo e quantos usuários diários ela tem. Só então discuta replicação — se é necessária, qual tipo, e se o sistema tolera consistência eventual.

O roteiro de decisão em resumo:

1. Meça o volume: até 50-100 mil leituras por segundo, índices e connection pooling costumam bastar.
2. Se precisar de latência geográfica, teste cache antes de réplicas para dados cacheáveis.
3. Precisa mesmo de réplicas? Assíncrona é o padrão do mercado; aceite o lag e valide se ele é tolerável.
4. Se o lag não for tolerável, aplique read after writes, janela de leitura no leader ou monotonic reads.
5. Consistência forte é requisito? Considere semisíncrona, nunca síncrona pura com várias réplicas.
6. Defina a política de failover: automático (aceitando possível perda de dados) ou manual (aceitando downtime).

Cada resposta dessas depende dos requisitos do sistema — não existe bala de prata. O que separa um arquiteto de um dev comum é justamente saber explicar esses trade-offs com clareza.

CTA: transforme vídeos como este em artigos que ficam

Todo o conteúdo acima nasceu de um vídeo de 41 minutos sobre replicação de dados. Esse tipo de conhecimento aprofundado merece existir também em texto, pesquisável e revisável.

Se você produz vídeos com explicações técnicas, o Skala Blog transforma essa gravação em um artigo estruturado: você cola a URL do YouTube, a plataforma transcreve e gera o texto pronto para revisar e publicar. Mesmo fluxo deste artigo, direto da sua própria biblioteca de vídeos.

FAQ sobre replicação de dados

• O que é replicação de dados? É a prática de manter cópias do mesmo banco de dados em múltiplas instâncias. No modelo leader-based, o leader concentra as escritas e propaga cada mudança aos followers, que atendem as leituras.

• Quando não usar replicação de dados? Quando o problema é throughput moderado ou latência em dados cacheáveis. Índices, connection pooling e cache resolvem a maioria dos casos até 50-100 mil requisições por segundo, sem o custo operacional das réplicas.

• O que é replication lag? É o atraso entre uma escrita no leader e a chegada do dado ao follower. Normalmente fica abaixo de um segundo, mas pode chegar a minutos sob carga alta ou instabilidade de rede, causando leituras desatualizadas.

• Qual a diferença entre replicação síncrona e assíncrona? Na assíncrona, o leader confirma a escrita antes de replicar, ganhando latência menor mas abrindo espaço para lag e perda de dados no failover. Na síncrona, ele replica antes de confirmar, garantindo consistência ao custo de mais latência e de escritas que falham se qualquer réplica cair.

• O que acontece quando o leader falha? Os followers detectam a falha por timeout nos heartbeats, promovem um deles a novo leader e redirecionam as escritas. Com replicação assíncrona, escritas ainda não replicadas podem ser perdidas; por isso algumas equipes preferem failover manual.

Source video