Menu
Back to Discussions

Event sourcing vs CQRS: when do you actually need both?

we're building a new financial ledger service, and i'm considering event sourcing for its auditability and replay capabilities. it feels like a natural fit for capturing every state change as an immutable event. but then the question comes up about CQRS. do we really need CQRS on top of event sourcing, or is it overkill for most scenarios? i see how CQRS could help with separate read models for different access patterns, but it also adds a lot of complexity: maintaining multiple projections, dealing with eventual consistency from the read side. is it typically needed only when read models become significantly different from the aggregate state, or for specific performance reasons? also, schema evolution for events seems like a recurring headache. what are folks' experiences here?
7 comments

Comments

Sign in to join the conversation.

Loading comments...