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 completo

Event 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 completo

Por 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.