CQRS (Command Query Responsibility Segregation) × Event Sourcing
Dois padrões que costumam ser trocados um pelo outro, e o que de fato os separa.
Em uma frase
CQRS separa modelo de escrita e de leitura. Event Sourcing guarda a escrita como sequência de eventos. Dá para ter um sem o outro — e a confusão nasce porque o combo é popular.
Critério a critério
O que é obrigatório guardar?
- CQRS (Command Query Responsibility Segregation)
- O estado atual (ou projeções) — o histórico de eventos é opcional.
- Event Sourcing
- Os eventos; o estado é uma redução que se pode jogar fora e refazer.
Serve só para escalar leitura?
- CQRS (Command Query Responsibility Segregation)
- É o caso de uso clássico: write model enxuto, read models sob medida.
- Event Sourcing
- Não — o ganho principal é auditoria, temporalidade e replay, não QPS de SELECT.
Dá para usar sozinho?
- CQRS (Command Query Responsibility Segregation)
- Sim: dois modelos, mesmo banco ou não, sem log de eventos.
- Event Sourcing
- Sim: um aggregate event-sourced com uma única projeção 'atual'.
O que fica difícil?
- CQRS (Command Query Responsibility Segregation)
- Manter projeções sincronizadas e aceitar consistência eventual na leitura.
- Event Sourcing
- Versionar eventos, upcasters e a disciplina de nunca 'editar o passado'.
Quando escolher cada um
CQRS (Command Query Responsibility Segregation)
Leituras e escritas têm formatos diferentes e você quer escalá-las ou modelá-las à parte — sem precisar de histórico como fonte da verdade.
Ver o conceito completoEvent Sourcing
Você precisa reconstruir o porquê de cada mudança, viajar no tempo ou projetar várias leituras a partir do mesmo log.
Ver o conceito completoPor que confundem
Tratar CQRS e Event Sourcing como sinônimos. CQRS é a separação; Event Sourcing é uma forma de persistir o lado de escrita. O combo é poderoso, mas cada um resolve uma pergunta diferente.