Event Sourcing

• Storing the event that trigger the state change in an immutable log.
• Provides a complete audit log of every state change ever made to an object.
• Rather than store the current state of an entity, the application stores a sequence of state‑changing events
• The application reconstructs an entity’s current state by replaying the events.
• Event become a version control of the data.

Benefits

• Auditability
• Use log for debugging application
• Undo operation
• Analysis and forecast log

Downside

• Data is stored as log. It is difficult to get the current state of data. Replay all event to get current state. This is where CQRS come in.

CQRS

• Command Query Responsibility Segregation
• Splitting an application into two parts
  • Command (Write) : Event sourcing publish command to event store
  • Query (Read) : Subscribe to event store to update view
• Decouples the load from writes and reads allowing each to be scaled independently.
• Often combine with Event Sourcing. Application will write command to Event Store and then Projection data will be created for query operation.

Reference

• https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/
• https://eventuate.io/whyeventsourcing.html
• https://courses.cognitiveclass.ai/courses/course-v1:Lightbend+LB0111EN+2018
• https://www.slideshare.net/gschmutz/kafka-as-an-event-store-is-it-good-enough
• https://www.nginx.com/blog/event-driven-data-management-microservices/
• https://www.upsolver.com/blog/cqrs-event-sourcing-build-database-architecture