Read Replicas: o truque que salva bancos de dados de entrar em colapso

O que são read replicas e como funcionam

Cópias do banco dedicadas exclusivamente a leituras

Read replicas são instâncias do banco de dados que recebem um stream contínuo de mudancas do banco primário (via WAL streaming no PostgreSQL, binlog no MySQL ou oplog no MongoDB) e mantêm uma cópia sincronizada dos dados, disponível exclusivamente para queries de leitura. A separação entre primário (escritas) e réplicas (leituras) é o padrao fundamental para escalar bancos de dados relacionais horizontalmente: enquanto o primário foca em processar INSERT, UPDATE e DELETE com máxima consistência, as réplicas absorvem o volume de SELECT que frequentemente domina o tráfego de uma aplicação web (tipicamente 80-95% das queries são leituras). Adicionar read replicas é uma das estratégias de escalabilidade mais custo-efetivas disponíveis: o custo é proporcional ao número de réplicas, e o ganho de capacidade de leitura é praticamente linear.

Replication lag - lendo dados potencialmente desatualizados

A consistência eventual das read replicas

Read replicas seguem o modelo de consistência eventual: ha um atraso (lag) entre uma escrita no primário e sua propagacao para a réplica, que normalmente varia de milissegundos a segundos em clusters saudáveis. Em situacoes de alta carga no primário ou de réplica ocupada com queries pesadas, o lag pode crescer para dezenas de segundos. Isso significa que um usuário que acabou de criar um recurso pode não ver o novo item se sua query de leitura for roteada para uma réplica com lag. Estratégias para mitigar: leia do primário imediatamente após escritas críticas para aquele usuário, use um lag threshold (não rotear para réplicas com lag maior que X segundos) ou aceite consistência eventual explicitamente no design da experiência do usuário para operações não críticas.

Casos de uso ideais para read replicas

Quando adicionar réplicas de leitura resolve o problema

Read replicas são a solução certa para gargalos específicos: relatórios e dashboards analíticos que executam queries pesadas por longos períodos e que se executadas no primário causariam lentidao para todos os usuarios. APIs de busca e listagem com alto throughput de consultas que não exigem os dados mais recentes (catálogos de produtos, feeds, rankings). Jobs de processamento batch que iteram sobre grandes volumes de dados (exportacoes, sincronizacoes, cálculos periódicos). Leitura em múltiplas regioes geográficas: réplicas posicionadas em diferentes regioes servem usuarios locais com menor latência sem precisar de escrita geo-distribuída, que é muito mais complexa. Read replicas não resolvem gargalos de escrita: para isso, considere sharding, particionamento ou mudanca de modelo de dados.

Roteamento de queries - application-level vs proxy

Como direcionar reads às réplicas automaticamente

Roteamento em nível de aplicação é a abordagem mais explícita: o código define qual connection pool usar em cada operação (connectionPrimary.execute("INSERT..."), connectionReplica.execute("SELECT...")). É mais verboso mas oferece controle total sobre quais queries vao para qual destino. Proxies de banco de dados como ProxySQL (MySQL), PgBouncer com módulo de routing, ou AWS RDS Proxy automatizam o roteamento: queries começando com SELECT são automaticamente direcionadas a réplicas, enquanto escritas vao ao primário. Essa transparência simplifica o código da aplicação, mas o proxy pode ser um ponto único de falha se não configurado com alta disponibilidade. ORMs como Hibernate (Java) e Entity Framework (.NET) têm suporte nativo a múltiplas connection strings com routing automático baseado no tipo de operação.

Read replicas em AWS RDS e Aurora

Gerenciamento simplificado na nuvem

AWS RDS permite criar read replicas de qualquer instância com poucos cliques ou via API, sem downtime no primário. O lag de replicação é monitorado automaticamente via CloudWatch (métrica ReplicaLag). RDS Aurora é um passo além: suas réplicas compartilham o mesmo storage distribuído do primário, eliminando replication lag para reads (dados escritos no primário estao imediatamente disponíveis nas réplicas Aurora). Aurora suporta até 15 réplicas de leitura por cluster com failover automático: se o primário falhar, a réplica com menor lag é promovida em menos de 30 segundos. Aurora Global Database permite réplicas em até 5 regioes AWS com lag de menos de 1 segundo entre regioes, habilitando aplicações globais com reads locais e escrita centralizada.

Read replicas em MongoDB com secondary reads

Configurando read preference no MongoDB

No MongoDB, read preference controla de quais membros do replica set as leituras são feitas. Primary (padrao) garante leitura sempre do primary com dados mais atuais. PrimaryPreferred usa o primary quando disponível e um secondary em caso de falha do primary. Secondary direciona todas as leituras a secondaries, distribuindo a carga. SecondaryPreferred usa secondaries quando disponíveis. Nearest seleciona o membro com menor latência de rede, independente se primary ou secondary. Para read replicas efetivas, configure secondary ou secondaryPreferred em operações de leitura tolerantes a lag (dashboards, relatórios, exports). Leituras com read preference secondary em MongoDB usam consistência eventual; para garantir leitura dos dados mais recentes, use primary com read concern majority.

Connection pooling com read replicas

Gerenciando conexões eficientemente entre múltiplos servidores

Com read replicas, a aplicação precisa gerenciar múltiplos pools de conexão: um para o primário e um (ou mais) para as réplicas. Connection pools evitam o overhead de criar nova conexão TCP a cada query, mantendo conexões persistentes reutilizáveis. Em aplicações .NET, Npgsql (PostgreSQL) e MongoDB.Driver gerenciam connection pools automaticamente por connection string. Evite criar um pool único por réplica que rivaliza em tamanho com o pool do primário: replicas dedicadas a reads pesados precisam de pool menor pois cada conexão pode executar queries longas. Monitore o número de conexões abertas por servidor no CloudWatch ou nas métricas do banco, alertando quando se aproxima do max_connections para prevenir esgotamento de conexões.

Monitoramento de replication lag

Garantindo que as réplicas estao sincronizadas

Monitorar replication lag é obrigatório em sistemas que usam read replicas. No PostgreSQL, a view pg_stat_replication no primary mostra o lag de cada standby em bytes e tempo. No MySQL/RDS, a métrica ReplicaLag no CloudWatch indica o atraso em segundos. No MongoDB, rs.printReplicationInfo() mostra o lag de cada secondary. Configure alertas quando o lag excede um limite aceitável para o seu caso de uso (ex: alertar se lag maior que 30 segundos em réplicas usadas para reads de usuario). Lag crescente pode indicar réplica sobrecarregada com queries pesadas, rede saturada entre primário e réplica, ou primário gerando mudancas mais rápido do que a réplica consegue aplicar, exigindo ajuste de capacidade ou otimização das queries executadas nas réplicas.

Read replicas vs caching - quando usar cada um

Complementares, não concorrentes

Read replicas e caching são estratégias complementares para reduzir carga no banco primário, cada uma ideal para cenários diferentes. Caching (Redis, Memcached) é mais rápido (microsegundos vs milissegundos), não consome conexões do banco, e elimina queries repetitivas para dados não voláteis. Mas caches tem custo de invalidacao: dados desatualizados no cache causam bugs se não invalidados corretamente após mudancas. Read replicas não têm problema de invalidacao (sempre refletem os dados persistidos, com lag eventual), suportam queries complexas e ad-hoc impossíveis de cachear, e são mais simples operacionalmente para dados de alta cardinalidade onde o cache hit rate seria baixo. Use cache para dados frequentemente lidos com baixa variacao (configurações, catálogos) e read replicas para queries analíticas complexas e dados com alta variacao de access patterns.

Conclusao - read replicas como alavanca de escala

Escalando leitura sem redesenhar a aplicação

Read replicas são uma das formas mais pragmáticas de ganhar capacidade de leitura: não exigem mudanca de schema, não requerem refatoracao da lógica de negocio e escalam de forma linear. O investimento está em configurar o roteamento correto, monitorar o lag e entender os casos onde leitura do primário é obrigatória. Continue em: Fundamentos obrigatórios antes de produção.

Read Replicas - Vídeos Essenciais

Read Replicas - conceitos e implementação

AWS Aurora vs RDS - diferenças de replicação

Connection pooling com múltiplos servidores

Monitorando replication lag em produção

Read replicas vs caching - quando usar cada um

Escalando leitura sem redesenhar o sistema