Consistência eventual: quando o sistema não atualiza ao mesmo tempo
Alguém faz uma ação. Aí outro fala: "Mas aqui ainda não atualizou." Silêncio, olhares. É bug? Atraso? Falha? Muitas vezes não é erro; é arquitetura. Esse comportamento tem nome: consistência eventual.
Depois de uma alteração, pode levar um tempo até todo mundo refletir o mesmo estado. Não é inconsistência pra sempre; é atraso de sincronização. Os pontos convergem com o tempo — milissegundos, segundos ou minutos, depende da arquitetura. Você paga e o app do banco confirma na hora, mas o extrato detalhado demora uns segundos. Você manda e-mail: a caixa de saída mostra na hora, o destinatário recebe segundos depois. Consistência eventual em ação.
Em sistema distribuído o dado não fica num lugar só. Pode estar em vários bancos, réplicas, caches, serviços, filas. Uma alteração atualiza o sistema principal, dispara evento, é consumida por outros, atualiza bases secundárias. Tudo isso leva tempo. Forçar atualização simultânea absoluta pode ser complexo, caro e desnecessário. Alguém escreve: "Ao alterar o status do pedido, todos os relatórios têm que refletir na hora." O relatório é alimentado por warehouse? O warehouse atualiza em batch? Se atualiza a cada 5 minutos, exigir "na hora" significa mexer no pipeline inteiro.
Dashboard que junta receita, cancelamentos, vendas, ticket médio: esses dados podem vir de banco transacional, ERP externo, warehouse e batch. Se cada fonte tem timing diferente, o dashboard pode mostrar pequenas diferenças temporárias. Nem sempre é bug; às vezes é convergência gradual. Bug é quando o dado nunca atualiza. Consistência eventual é quando o dado atualiza depois de alguns segundos e os sistemas convergem. Sem essa diferença na cabeça você pode abrir incidente à toa ou prometer algo que a arquitetura não entrega.
Pra todo mundo estar 100% sincronizado no mesmo instante você precisa de comunicação síncrona, confirmação em cadeia, bloqueio. Quanto mais distribuído, mais difícil. Você vende o mesmo produto em vários canais: vende no canal A e o estoque precisa refletir no B. Se a atualização é por evento assíncrono, pode haver atraso de segundos. Exigir bloqueio até todos confirmarem sobe latência, trava transação. Arquitetura é escolha de trade-off.
Você não controla o modelo de consistência, mas controla a expectativa do negócio. Quando alguém diz "isso tem que atualizar em todo lugar na hora", dá pra perguntar: qual o impacto real se demorar 5 segundos? Nem tudo precisa de consistência forte; às vezes basta clareza. Muitas crises acontecem não por causa da inconsistência, mas porque ninguém explicou que existe janela de convergência. Se o negócio sabe que "o dashboard pode levar até 2 minutos pra refletir mudanças", vira expectativa controlada.
Você faz transferência: seu saldo cai na hora, o do destinatário pode demorar uns segundos. Sistemas bancários são muito distribuídos e precisam de reconciliação. Consistência forte absoluta em escala pode ser impraticável. Antes de exigir "na hora": qual é o modelo de consistência hoje? Tem processamento assíncrono? Warehouse? Cache? Se você não sabe, está prometendo no escuro.
Dá pra mitigar com mensagem clara, indicador de processamento, feedback visual. "Seu pedido foi recebido. Pode levar até 2 minutos pra aparecer no histórico." Isso não muda arquitetura — muda a percepção. Convergência lenta é uma coisa; sistemas que nunca convergem é outra. No segundo caso não é consistência eventual; é problema de integração.
Quem entende consistência eventual evita requisitos do tipo "atualizar todos os pontos ao mesmo tempo" ou "bloquear até confirmação global". Em vez disso: convergência dentro do SLA, mostrar status enquanto sincroniza. Arquitetura é sempre trade-off — consistência forte, escalabilidade, performance, custo. Não existe solução perfeita; existe contexto.
Consistência eventual não é erro; é modelo arquitetural. Sistemas distribuídos não são relógios suíços sincronizados ao milissegundo — convergem com o tempo.
No próximo post: resiliência. Porque falha não é exceção — é inevitável.
