Replicação síncrona versus assíncrona: qual escolher?.
Uma transação de pagamento aprovada e perdida após a queda de uma região não é uma falha de banco de dados isolada. É uma falha de arquitetura, governança e decisão de risco. Na discussão sobre replicação síncrona versus assíncrona, a pergunta relevante não é qual tecnologia é mais moderna. É quanto dado a empresa pode perder, quanto atraso o aplicativo suporta e o que acontece quando a infraestrutura falha no pior momento.
Para ambientes transacionais, escolher o modelo de replicação sem medir RPO, RTO, latência e comportamento de failover é aceitar um risco que só aparece em produção. E, quando aparece, costuma envolver indisponibilidade, divergência de dados, retrabalho financeiro e impacto reputacional.
Replicação síncrona versus assíncrona: a diferença operacional
Na replicação síncrona, a confirmação de uma escrita depende da confirmação de uma ou mais réplicas, conforme a implementação e a política configurada. O banco principal não considera a transação concluída apenas por ter gravado localmente. Ele aguarda a garantia adicional exigida pela arquitetura.
O efeito desejado é direto: reduzir drasticamente a janela de perda de dados em caso de falha do nó primário. Se o servidor principal cair logo após confirmar uma transação, a réplica participante já deve possuir aquela alteração ou estar em uma condição controlada para recuperá-la.
Na replicação assíncrona, o primário confirma a transação ao aplicativo antes de a réplica necessariamente receber e aplicar a alteração. A replicação ocorre depois, por meio de logs de transação, binlog, WAL ou mecanismos equivalentes. Isso reduz o tempo de resposta da escrita, mas cria uma distância entre o estado do primário e o estado da réplica.
Essa distância é o replication lag. Em condições normais, pode ser de milissegundos. Sob pico de carga, limitação de I/O, saturação de rede, consultas pesadas na réplica ou incidentes de infraestrutura, pode crescer para segundos ou minutos. Se ocorrer um failover durante esse intervalo, transações confirmadas ao usuário podem não existir no novo primário.
O que a replicação síncrona protege - e o que ela não protege
A replicação síncrona é indicada quando a perda de uma transação confirmada é inaceitável ou exige controles rigorosos. Sistemas de pagamento, ledger financeiro, pedidos com baixa tolerância a inconsistências, autenticação crítica e operações reguladas são exemplos frequentes.
Ela não elimina todos os riscos. Replicar uma alteração incorreta de forma síncrona apenas propaga o erro com mais rapidez. Um comando destrutivo, uma aplicação com bug, uma corrupção lógica ou credenciais comprometidas podem afetar todos os nós participantes. Replicação não substitui backup testado, retenção de logs, controles de acesso, auditoria nem plano de recuperação.
Também não significa que qualquer cluster será automaticamente consistente em todos os cenários. Cada tecnologia tem regras próprias para quorum, confirmação, eleição de líder, isolamento de nó e resolução de split-brain. Em alguns produtos, o nome comercial ou o modo de operação pode sugerir sincronia, mas a confirmação ocorre em uma etapa específica do transporte, não necessariamente após a aplicação completa da transação na réplica.
Esse detalhe muda a análise. A equipe responsável precisa saber exatamente o que foi confirmado, por qual nó, em qual etapa e sob quais condições a escrita deixa de ser aceita.
O preço da garantia é latência
Toda confirmação remota adiciona tempo ao caminho crítico da transação. Se a réplica síncrona está na mesma zona de disponibilidade, a penalidade pode ser aceitável. Se está em outra região, a latência de rede passa a fazer parte de cada commit.
Não existe ajuste mágico para contornar a física. Uma arquitetura que exige confirmação síncrona entre cidades ou continentes pode entregar excelente RPO, mas degradar a experiência do usuário e limitar o throughput de escrita. Para um e-commerce, alguns milissegundos adicionais podem ser toleráveis. Para um motor de negociação ou um fluxo de alta frequência, talvez não sejam.
Há ainda o impacto na disponibilidade. Se a política exigir confirmação de uma réplica indisponível, o primário pode bloquear ou recusar escritas. Isso protege a integridade do dado, mas transforma uma falha de comunicação em indisponibilidade parcial ou total do serviço de escrita. A decisão correta depende de qual risco é maior para o negócio: aceitar atraso, interromper transações ou admitir uma janela de perda de dados.
Quando a replicação assíncrona é a escolha mais eficiente
Replicação assíncrona não é uma solução inferior. Em muitas arquiteturas, ela é a decisão tecnicamente correta. É especialmente útil para réplicas de leitura, relatórios, BI, cargas analíticas, distribuição geográfica de consultas, ambientes de contingência e cópias destinadas a backup lógico ou recuperação operacional.
Ela permite que o primário mantenha baixa latência de commit e não fique dependente da resposta de uma instância remota. Isso é valioso em aplicações com alto volume de escrita, bancos distribuídos entre regiões ou cenários nos quais a continuidade do processamento tem prioridade sobre RPO zero.
O ponto é tratar a perda potencial como um requisito explícito, não como uma surpresa. Se o RPO aceitável é de até 30 segundos, a operação precisa demonstrar que o atraso de replicação permanece dentro desse limite sob carga real. Um painel que mostra lag médio baixo não basta. É necessário observar máximos, percentis, períodos de manutenção e comportamento durante incidentes.
Em uma réplica assíncrona destinada a leitura, também é preciso lidar com consistência eventual. Um usuário pode concluir uma compra no primário e, logo em seguida, consultar o histórico em uma réplica que ainda não recebeu a transação. Para evitar essa experiência, o aplicativo pode direcionar leituras críticas ao primário por uma janela definida ou usar mecanismos de leitura consistente oferecidos pela plataforma.
RPO e RTO definem a arquitetura, não o contrário
RPO, ou Recovery Point Objective, estabelece o volume máximo de dados que pode ser perdido após uma falha. RTO, ou Recovery Time Objective, define quanto tempo o serviço pode ficar indisponível. Os dois indicadores precisam ser definidos por processo de negócio, não por preferência da equipe de infraestrutura.
Uma fintech pode exigir RPO próximo de zero para registros financeiros, mas aceitar alguns minutos de indisponibilidade controlada para manutenção. Um catálogo de produtos pode aceitar RPO maior, desde que a navegação continue disponível. Uma operação de logística pode exigir leitura regional rápida, mas centralizar a escrita em um único local para preservar consistência.
A matriz de decisão deve considerar pelo menos quatro fatores: criticidade do dado, latência máxima de escrita, distância entre os sites e capacidade operacional para executar failover com segurança. Não adianta configurar réplicas em múltiplas regiões se a empresa não consegue promover o nó correto, redirecionar conexões, validar integridade e impedir que o antigo primário volte a aceitar escrita.
O erro recorrente: confundir réplica com contingência
Uma réplica atrasada não é, por si só, um plano de desastre. Contingência exige procedimentos documentados, credenciais de emergência, automação validada, monitoramento de saúde, critérios claros para failover e failback, além de testes periódicos.
O teste deve reproduzir falhas plausíveis: queda do primário, perda de conectividade entre zonas, disco cheio, aumento abrupto do lag, corrupção lógica e indisponibilidade do serviço de descoberta. Também deve medir o impacto no aplicativo. Um banco promovido com sucesso não resolve o incidente se os pools de conexão continuarem apontando para o endereço antigo ou se as filas reaplicarem eventos duplicados.
Modelos híbridos são comuns e eficazes. Uma empresa pode manter replicação síncrona entre nós próximos para proteger as transações críticas e usar replicação assíncrona para uma região secundária, analytics ou recuperação de desastre. Assim, evita colocar uma confirmação inter-regional no caminho de cada escrita, sem abrir mão de uma estratégia de recuperação geograficamente distribuída.
Como decidir sem criar um novo ponto de falha
A escolha começa com perguntas objetivas. Qual é o RPO por domínio de dados? O que ocorre se uma transação confirmada desaparecer? Qual é a latência medida entre os locais em horário de pico? O aplicativo suporta leituras eventualmente consistentes? Quem executa o failover às 3 horas da manhã e como essa decisão é auditada?
Depois, valide a arquitetura em carga. Testes sintéticos ajudam, mas não substituem medições com volume, concorrência, tamanho de transação e padrões de acesso próximos da produção. Acompanhe tempo de commit, throughput, fila de replicação, atraso de aplicação, erros de transporte, saturação de CPU, I/O e comportamento dos clientes durante a troca de primário.
Também evite configurações genéricas copiadas de documentação. Parâmetros de timeout, quorum, retenção de logs, atraso intencional, prioridade de promoção e limites de fluxo precisam refletir o banco, a versão, a topologia e o risco real da operação. Em ambientes críticos, essa definição requer senioridade de DBA e acompanhamento contínuo, não um projeto abandonado após a implantação.
A HTI atua justamente nesse ponto: transformar requisitos de continuidade em uma operação de banco de dados monitorada 24/7, com critérios de failover, documentação e validação técnica em produção.
A melhor escolha não é síncrona ou assíncrona por princípio. É a arquitetura que deixa claro o que será preservado, o que pode atrasar e quem responde quando o cenário de falha deixa de ser hipotético.