A consistência de dados agora é um SAGA.
Você está construindo microsserviços e precisa garantir que uma operação complexa, que toca vários serviços diferentes, seja "atômica"? Ou seja, ou tudo acontece com sucesso, ou nada acontece (e tudo volta ao estado original)?
Se sua resposta foi sim, você provavelmente já se deparou com o dilema da transação distribuída.
O modelo clássico de banco de dados, o Two-Phase Commit (2PC), que garante atomicidade com ACID, é um desastre em microsserviços. Ele acopla seus serviços, causa long-running locks e é extremamente frágil a falhas de rede. Na prática, é inviável e a antítese do que microsserviços pregam.
A solução moderna e resiliente para consistência de dados em sistemas distribuídos é o padrão SAGA.
O que é o Padrão SAGA?
Em vez de uma única transação gigante que trava tudo, o SAGA quebra a transação distribuída em uma sequência de transações locais, onde cada transação local é executada por um serviço diferente.
A grande sacada? Cada transação local, ao ser completada, publica um evento. Se alguma transação falhar no meio do caminho, o SAGA usa transações de compensação para desfazer os efeitos das transações locais que já foram concluídas.
Pense em um SAGA como uma série de "passos" com "desfazer" para cada um.
Como o SAGA Funciona (Modelos):
Existem duas formas principais de orquestrar um SAGA:
-
Coreografia (Event-Driven):
- Como funciona: Cada serviço sabe o que precisa fazer e qual evento ele deve publicar ao terminar sua parte. Os serviços reagem a eventos uns dos outros.
- Exemplo: Serviço A termina -> publica Evento X. Serviço B escuta Evento X -> faz sua parte -> publica Evento Y. Serviço C escuta Evento Y, e assim por diante.
- Vantagens: Mais desacoplado, simples para Sagas menores.
- Desvantagens: Pode ser difícil de monitorar e depurar em Sagas complexas, pois a lógica está espalhada.
-
Orquestração (Centralizada):
- Como funciona: Um serviço Orquestrador SAGA central gerencia toda a sequência. Ele sabe qual é a ordem das transações locais e quais transações de compensação chamar em caso de falha.
- Exemplo: Orquestrador chama Serviço A. Serviço A responde sucesso. Orquestrador chama Serviço B. Serviço B falha. Orquestrador chama Serviço B de Compensação, depois Serviço A de Compensação.
- Vantagens: Visibilidade clara do fluxo, fácil de monitorar e depurar.
- Desvantagens: O Orquestrador pode se tornar um single point of failure (SPOF) ou um gargalo se não for bem projetado.
O Coração do SAGA: Transações de Compensação
Este é o componente mais crítico. Para cada transação local bem-sucedida, você precisa ter uma transação de compensação que desfaça seus efeitos.
- Se o Serviço de Pagamento debita um valor, a compensação é estornar o valor.
- Se o Serviço de Estoque reserva um item, a compensação é liberar o item.
Sem transações de compensação bem definidas, seu SAGA pode deixar o sistema em um estado inconsistente.
Conclusão
Não tente forçar o modelo de transação ACID de um monolito em seus microsserviços. Ele não foi feito para isso.
O padrão SAGA, seja por coreografia ou orquestração, é a ferramenta essencial para construir consistência de dados em um mundo distribuído. Entenda-o, planeje suas transações de compensação e use-o para construir sistemas resilientes e escaláveis.