Event Sourcing vs. Event Streaming

A monolithic application benefits from events, but they really become significant when data has to move. When there are different parts of an application that need to coordinate with each other and share data with one another across data centers, clouds or across continents. This represents a conceptual shift from data at rest to data in motion. A nice example to explore this is a flight booking system, which is very read heavy. Typical applications of this type have 10,000 times more reads than rights. And the users are distributed all over the world. One approach to solving this sort of problem is to set up the system with a globally distributed database, but that's not the most efficient way, because reads themselves will always be eventually consistent. Regardless of whether data is served from a globally consistent database or something asynchronous, because of browser caching and other factors, the data the user reads will never be totally consistent with what is being written and nor does it need to be. What really matters is that when you book a flight, you definitely get your reservation. So it makes sense to split up reads and writes and have writes go to a consistent place, but have reads go to a place that is eventually consistent. In this solution, writes go to a single place, the flight booking service, which gets disseminated via event streams to many views that serve reads. The events form the source of truth and the views perform the chronological reduce that summarizes the event stream down into tables. The same pattern generalizes to microservices. There is one event source of shopping cart data, which is consumed by many other services. The source of truth, again, is event level data. Each microservice has an event interface to trigger actions to happen, as well as a view that represents the shopping cart data. What form they want that view in, event level, table level, some custom transformation, is entirely up to each microservice to decide. What's more? So is where they store it. Relational, graph, document? Whatever database they prefer. In summary, storing data in Kafka is not obligatory, but understanding the value of retaining events, whether it's as a source of truth or part of the analytics backend, is critical. Today's businesses typically need event level data. And once it's lost, it's often impossible to get back. Event sourcing and CQRS are useful approaches for understanding the trade-offs of event storage. But event sourcing is really a specialization of event streaming. The difference being that event sourcing is really about a single app or microservice, a single storage model, a single database and data that stays at rest. Event streaming adds connectivity. So event data is used by many microservices, using many types of databases to persist that data, as well as building applications that drive their processing directly from the events source. In this course, we have looked at event storage from simple monolithic event sourcing applications through to complex multi-region applications that rely heavily on data in motion. But the most important piece we covered is the value of the events themselves, a high fidelity event level recording of the world that we can always go back to knowing that information will never be lost.