The Event Sourcing pattern involves sending a continuous stream of messages to an authoritative storage target. Each message describes an event in the system. Examples include: A write to the database, request to a web server, or logging activity from within an application. Services and applications then query the event store for interesting events in a way that is particular to the purpose of the given service or application.
Pros
- Great for fail-safety. If the downstream source fails, its data can be reconstituted from the event store.
- Extremely flexible. Any type of message can be stored. Any consumer can access the event store as long as appropriate access rights are granted.
- Excellent for real-time data reporting, especially when used with an event-driven message broker such as Kafka.
Cons
- Requires an extremely efficient network infrastructure given the inherent time sensitivity of the pattern and the susceptibility to potential latency issues.
- Requires a reliable way to control message formats, for example, using a schema registry.
- Different events will contain different payloads. There needs to be a single source of truth for defining and determining message formats for a particular event.
Conclusion
Event Sourcing is gaining popularity as more applications need real-time data delivered in an asynchronous yet ordered manner, for example, ride-share applications. Also, Event Sourcing is gaining wide acceptance as a way to consume and manage applications’ log data at web-scale. As mentioned above, an event source can serve as a common point of truth for applications regardless of how the given application intends to process the data