Entre serviços você geralmente troca consistência forte por eventual, e se apoia em CQRS e event sourcing para tornar isso prático e correto.
Após uma mudança, réplicas convergem "em breve" em vez de instantaneamente. Aceitável para a maioria dos fluxos de negócio (uma contagem de inventário pode atrasar um segundo), inaceitável para alguns (uma verificação de saldo bancário).
Separe o modelo de escrita de um ou mais modelos de leitura.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Leituras escalam e se reformulam independentemente das escritas; o modelo de leitura é atualizado a partir de eventos, portanto é eventualmente consistente.
Armazene a sequência de eventos como fonte da verdade, não apenas o estado atual. O estado atual é um fold sobre eventos.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Técnica | Ganhos | Custos |
|---|---|---|
| Eventual consistency | Disponibilidade, escala | Leituras obsoletas, conflitos |
| CQRS | Escala leitura/escrita | Dois modelos para manter sincronizados |
| Event sourcing | Auditoria, replay, histórico | Evolução de schema/eventos, complexidade |
Não adote event sourcing em todo lugar — é poderoso mas pesado. Use-o onde auditoria/histórico realmente importa.
Sistemas distribuídos não podem ter consistência forte, disponibilidade e tolerância a partição tudo de uma vez, então o design senior é sobre escolher onde eventual consistency é aceitável.
CQRS e event sourcing dão a você as ferramentas para tornar eventual consistency confiável e auditável — mas cada um adiciona complexidade real, então aplique-os cirurgicamente, não por padrão.