Event Sourcing vs. Event Streaming

Event Sourcing vs. Event Streaming

A monolithic application benefits from events, but events really become significant when data has to move—when there are different parts of an application that need to coordinate with one another and share data across data centers, clouds, or continents. This represents a conceptual shift, from data at rest to data in motion.

CQRS with Data in Motion

Consider a flight booking system, which is very read heavy: a typical application of this kind may have 10,000 more reads than writes, with users distributed all over the globe. You could use a globally distributed database, but that's not the most efficient solution, because reads themselves will always be eventually consistent because of browser caching and other factors. What really matters is that when you book a flight, you absolutely get your reservation. Thus it makes sense to split up reads and writes, and have writes go to a consistent place, but have reads go somewhere that is eventually consistent.

In the image above, writes go to a single place—the flight booking service—and they get disseminated, via event streams, to many views that serve reads. The events serve as the source of truth, and the views perform a chronological reduce that summarizes the event streams down into tables.

CQRS Applied to Microservices

This pattern can also be applied to microservices. For example, in the image below there is one event source—shopping cart data—which is consumed by many other services. (The source of truth is, again, the event-level data.) Each microservice has an event interface to trigger actions, as well as a view that represents the shopping cart data. Each microservice individually decides the form for the view: event level, table level, a custom transformation, etc. The microservice also determines how the data is stored: in a relational database, a graph database, a document database, etc.

Progressing to Event Streaming

Event sourcing and CQRS are useful approaches for understanding the tradeoffs of event storage. But event sourcing is actually a subset of event streaming, since it only concerns a single app or microservice with a single storage model, along with a single database featuring data at rest. Event streaming adds connectivity to event sourcing, enabling event data to be used by many microservices utilizing many types of databases. And these services often drive their processes directly from the event source.

In this course you learned about event storage, from simple monolithic event sourcing applications through to complex, multiregion applications that rely heavily on data in motion.

But the most important takeaway is the value of retaining events, whether as a source of truth or as part of an analytics backend. All businesses can benefit from analytical data, but once that data goes lost, it's often impossible to get back. Fortunately, a high-fidelity, event-level recording of the world can always be revisited.