Read Replicas: escalando leitura sem sobrecarregar o banco principal

O que sao read replicas e como funcionam

Cópias do banco dedicadas exclusivamente a leituras

Read replicas sao instancias 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 separacao 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 aplicacao web (tipicamente 80-95% das queries sao 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 nao 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 (nao 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 operacoes nao críticas.

Casos de uso ideais para read replicas

Quando adicionar réplicas de leitura resolve o problema

Read replicas sao a solucao 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 nao exigem os dados mais recentes (catálogos de produtos, feeds, rankings). Jobs de processamento batch que iteram sobre grandes volumes de dados (exportacoes, sincronizacoes, calculos 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 nao 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 aplicacao é a abordagem mais explícita: o código define qual connection pool usar em cada operacao (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 sao automaticamente direcionadas a réplicas, enquanto escritas vao ao primário. Essa transparência simplifica o código da aplicacao, mas o proxy pode ser um ponto único de falha se nao 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 operacao.

Read replicas em AWS RDS e Aurora

Gerenciamento simplificado na nuvem

AWS RDS permite criar read replicas de qualquer instancia com poucos cliques ou via API, sem downtime no primário. O lag de replicacao é 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 aplicacoes 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 sao 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 operacoes 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 conexoes eficientemente entre múltiplos servidores

Com read replicas, a aplicacao precisa gerenciar múltiplos pools de conexao: um para o primário e um (ou mais) para as réplicas. Connection pools evitam o overhead de criar nova conexao TCP a cada query, mantendo conexoes persistentes reutilizáveis. Em aplicacoes .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 conexao pode executar queries longas. Monitore o número de conexoes abertas por servidor no CloudWatch ou nas métricas do banco, alertando quando se aproxima do max_connections para prevenir esgotamento de conexoes.

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 otimizacao das queries executadas nas réplicas.

Read replicas vs caching — quando usar cada um

Complementares, nao concorrentes

Read replicas e caching sao 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), nao consome conexoes do banco, e elimina queries repetitivas para dados nao voláteis. Mas caches tem custo de invalidacao: dados desatualizados no cache causam bugs se nao invalidados corretamente após mudancas. Read replicas nao têm problema de invalidacao (sempre refletem os dados persistidos, com lag eventual), suportam queries complexas e ad-hoc impossíveis de cachear, e sao mais simples operacionalmente para dados de alta cardinalidade onde o cache hit rate seria baixo. Use cache para dados frequentemente lidos com baixa variacao (configuracoes, 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 aplicacao

Read replicas sao uma das formas mais pragmáticas de ganhar capacidade de leitura: nao exigem mudanca de schema, nao 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.