14/09/2026
Garantir consistência não significa necessariamente manter toda a operação presa a uma única transação longa. Em cenários de alta concorrência ou operações distribuídas, essa estratégia pode aumentar contenção, ampliar o tempo de locks e limitar a escalabilidade.
Uma alternativa é registrar as etapas da operação separadamente e utilizar um marcador de conclusão para indicar quando todo o processo foi finalizado com sucesso. A leitura passa então a considerar apenas registros pertencentes a operações concluídas. Em arquiteturas distribuídas, ideias semelhantes aparecem em padrões como Saga, Outbox e mecanismos de consistência eventual.
Mas existe um trade-off importante: retirar uma transação ACID não elimina o problema de consistência. A responsabilidade apenas muda de lugar. Falhas parciais, idempotência, retries, concorrência, compensações e limpeza de operações incompletas precisam fazer parte do desenho.
Consistência não desaparece quando você remove a transação. Ela vira uma responsabilidade da arquitetura.
Como sua arquitetura trata consistência quando uma única transação deixa de ser suficiente?
