The ability to replay events to any point in time is also an excellent debugging tool that enables us to easily explain why a member’s account is in a particular state and allows us to easily test system variations. These events are then played in order, building up an aggregate view of the complete data domain. Instead of persisting the data model itself, you persist the events that lead to a change in the data. In short, Event Sourcing is an architectural pattern that maintains a complete transaction history for a data model. Pattern: Event Sourcing, by Chris Richardson.There are many excellent overviews of the Event Sourcing pattern. Martin Fowler describes the basic pattern as follows: “The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.” Enter Event SourcingĮvent Sourcing is an architectural pattern that is resurfacing lately as a valuable component of a modern distributed microservices ecosystem. Given the longevity of the data, we wanted the ability to look back in time to debug a change in state. The document model provides us with the flexibility we need for the data model, but doesn’t provide us with the traceability to determine what caused the data mutation. In addition, once the data is mutated you lose valuable context to the cause of the change and what the previous state was.ĭocument oriented NoSQL databases are known for providing such flexibility to change, and we quickly moved in that direction as a means to provide a flexible and scalable solution. There are ways to change the schema, but they are not easily accessible, require a deep knowledge of SQL, and direct interaction with the database. Right?Īnyone who’s familiar with relational databases knows that the phrases ‘flexible’ and ‘easy to change’ are not overly true with regards to the underlying table schema. So, how do you start to design and implement a service when the requirements are yet to be decided? What if that service is going live in a matter of months to millions of members on a single day with a 6am global press release? You make the system flexible to change. All we knew was that they were coming, and we needed to be able to adapt to them.
When we first started to design the downloads licensing service, the content licensing restrictions had yet to be defined. In this post, we provide an overview of the general event sourcing pattern and how we applied it to some of these key use cases.
#NETFLIX DOWNLOAD RULES SERIES#
In the first episode of this series of posts, we introduced the Netflix downloads project and the use cases that led us to consider a solution based on the event sourcing pattern. Scaling Event Sourcing for Netflix Downloads, Episode 2īy Karen Casella, Phillipa Avery, Robert Reta, Joseph Breuer
0 kommentar(er)
