Overview
A aula aborda a principal pergunta de entrevistas de System Design sobre a transição de monolito para microserviços, com foco em consistência de dados e transações distribuídas.
Pergunta Central em Entrevistas
- Perguntam como garantir consistência ao migrar de monolito para microserviços.
- Outras variações comuns: "Qual a principal mudança em transações ao migrar?" e "Como controlar transações em microserviços?".
Processo no Monolito
- Monolito: aplicação única onde etapas do processo são chamadas por métodos internos.
- Exemplo: checkout inclui checagem de estoque, pagamento, criação de pedido, tudo numa mesma transação.
- Transações ACID (atômicas, consistentes, isoladas e duráveis) garantem rollback automático em falhas.
- O framework (ex: Spring) controla toda a transação do começo ao fim.
Processo em Microserviços
- Cada microserviço tem sua própria base de dados e responsabilidade.
- Não há mais controle transacional único nem rollback automático via banco.
- Surge o conceito de transação distribuída, exigindo novos mecanismos de consistência.
Padrão Saga para Consistência
- Em microserviços, usa-se o padrão Saga para controlar transações distribuídas.
- Existem dois tipos principais: orquestração e coreografia.
Saga Orquestrada
- Um orquestrador central executa e controla todas as etapas dos microserviços.
- Em caso de falha, o orquestrador dispara operações de compensação (rollback lógico) nos serviços anteriores.
- Pode usar commit em duas fases (two-phase commit) para preparar e depois efetivar ou reverter etapas.
- Deve persistir o estado das etapas (state machine) para garantir recuperação em caso de falhas.
- O orquestrador é um single point of failure (SPOF).
Saga Coreografada
- Não há orquestrador central; os serviços se comunicam via message broker (ex: Kafka).
- Cada serviço age após receber eventos de sucesso do serviço anterior.
- Em caso de falha, um evento de erro é enviado e todos os serviços que já atuaram executam suas compensações.
- Elimina o SPOF, mas pode ter problemas como dual write (escrita dupla).
Consistência Eventual
- Nos dois padrões de Saga, a consistência é eventual: os serviços podem ficar dessincronizados por um curto tempo.
- A compensação é feita por mensagens e pode demorar alguns segundos para sincronizar os estados.
Principais Riscos e Problemas
- Orquestração: SPOF e necessidade de persistir estado.
- Coreografia: risco de dual write (escrever no banco e na fila separadamente) que pode gerar inconsistência.
Key Terms & Definitions
- Monolito — Arquitetura de sistema como uma aplicação única e centralizada.
- Microserviço — Arquitetura onde cada serviço é independente e tem sua própria base de dados.
- Transação ACID — Propriedades que garantem atomicidade, consistência, isolamento e durabilidade.
- Transação Distribuída — Transação que envolve múltiplos serviços e bancos distintos.
- Saga — Padrão de controle de transação distribuída via etapas compensatórias.
- Orquestração — Controle centralizado das etapas pelo orquestrador.
- Coreografia — Serviços independentes coordenados por mensagens.
- Consistência Eventual — Estado temporário de ausência de sincronização total dos dados.
- Single Point of Failure (SPOF) — Único componente cuja falha compromete todo o sistema.
- Dual Write Problem — Risco de inconsistência ao escrever em banco e fila separadamente.
Action Items / Next Steps
- Estudar o problema de dual write e estratégias de mitigação.
- Praticar explicações sobre padrões Saga em entrevistas.
- Revisar propriedades de transações ACID e consistência eventual.