 Hello, everyone. My name is Brian Renero. I work as a software developer advocate at MongoDB. And another thing about me today is my birthday. So standing here means my wish came true. So let's talk about event sourcing. What event sourcing is, how can it be ubiquitous, and how can I assert that you've never heard of it before? More importantly, why might you want to use it? Well, let's dive into an example. Let's build a banking app. So if I'm building a banking app, I'm probably going to need to persist state in some form back on my data store in some way. Now, this seems like a pretty obvious problem to solve. I'm going to have two users, user A, and creatively named user B. And they both have balances. And the balance describes the current state of their accounts. So when I want to do a transaction between the two accounts, transfer of money, let's say user A buys something for $5 from user B, that's easy. I just credit the account of user B while atomically in an asset transaction, take away $5 from user A. But the problem is if I'm thinking along this way, I may already be doing it wrong. Why? Because by design, I'm throwing away useful information. The only thing I'm persisting right now is the current state of the users. I've lost the history of what I've done or how they got there. So if there's any corruption or data loss or I'm attacked where someone changes my state, I can't derive what happened. So instead, event sourcing was first proposed by two gentlemen, Greg Young and Udi Dahan. And it is often used in conjunction with command query responsibility segregation. You have to say that 10 times fast before you can invoke it in your code. So event sourcing and command query responsibility segregation, what are these things? Event sourcing says, forget about current state. Don't think about current state. We don't care about current state. Well, we do care about current state, but we're not going to persist current state. We're instead going to log events that change our state. We're saying that in this case, instead of updating a user's account, I'm updating the transactions that would change that account. And I can derive my state by replaying the event log. What is more is that if I lose this current state, I can always regenerate it by replaying the event log. Plus, I can come up to any state in the past. I can tell you what the world used to be like at any time, at different points in time. So I can do temporal queries. This is actually kind of useful if I've learned something new about the people and the way that users use my tool, my website. I can go back and see how many people I could have reached in the past as long as I've kept that information in the law. Now, is this more secure? Consider if someone tries to attack me. How might they attack me? What's the easiest way of attacking me? Start sending in erroneous data. No problem, because I have a log of the attack. I can play up to the point where I detect the attack. And since I have a log of the attack, I can analyze it and protect myself in the future. Now, for those of you who might think that this is a radical new idea, untested kinds of ways of thinking about data, not necessarily. This is the Rega, sorry, Augusti, which translates into the divine deeds of Augustus. This is Caesar's record of payments, pension payments, to his legionnaires that have retired. And he's not recording state. These are the payments, so he can get his accounts at any given time. And it's a pretty robust data store. That's durability. For those of you who like their technology explained in modern contexts, you might already guess that this kind of pattern is already used in, what's wrong, why? Code repository systems, right? Because what I'm logging in code repository systems, such as GitHub, is the changes that I've done to my code such that I can always rebuild what the current snapshot is, or I can go back to a previous code state in time. I can also do merges and blends and all sorts of fun stuff that confuses everybody, and that's why we want continuous integration to begin with. Also, databases make big use of event sourcing internally. In the case of MongoDB, we have replication. So what we're gonna be doing is the primary who takes the right is gonna be writing to what's called the op log, and it makes item potent inserts of write operations from the database. The secondary will follow off of that log and replay the op log to get itself in a consistent state with the primary. The neat thing about the op log is just like event sourcing, I can start at any point in time in the past and replay up to get into a current state. Anywhere I stop reading is a consistent state at that point in the op log. Okay, so you might detect that there's a little bit of a problem with event sourcing. If every time I want to derive my current state is, I have to go back against the log to the beginning of time. The beginning of time for me could be many years, many months, many years, and replaying that whole log is gonna be time consuming. It might even blow out my cache, which is painful. So instead, the solution is, of course, to make snapshots given intervals. When I want to go to a targeted state, I go back to the last snapshot before the target and simply replay the op log from that point, or the event log. Okay, so this kind of precedence also has its roots in ancient history. Well, if you think the 14th century is ancient, which I do. This gentleman is Luka Petroli. He is a Renaissance man, again, that you may not have ever heard of, but he is the father of modern accounting because he was the first in 1495 to put down a kind of accounting called dual entry accounting. And basically the idea is he's going to take his event log, the journal, which the etymology of journal is jour or day, and he's going to aggregate this, as we saw in the snapshot pattern, into a ledger. And the etymology of the ledger is to lay. The book lays in one spot. So we have our logs, which are being aggregated into a ledger. This is very similar to Eric Evans' pattern of aggregations and domain-driven design. His particular innovation was, he was doing this dual entry accounting where we have accounts payable and accounts receivable. This works so well, in fact, that this actually funded the age of exploration in the 1500s and the century that followed. But we can call this today as Command Query Responsibility Segregation, or CQRS. The notion behind CQRS is that the way that we command, we call commands write operations, commands are different than the way that we read or query the data off our data store. So since they are fundamentally different, and also scale at asymmetrical loads, meaning that I might read far more than I do write operations that mutate state on the data store, they should be separate objects. What's the consequence of that? Consider CQRS versus CRUD. This is the normal pattern that we've kind of been accustomed to with interacting with a backend data store. I have a single object that performs, create reads, updates, and deletes. And then I add getters and setters to change that state back on whatever's happening on the database. Now, if I use CQRS, I've separated these models, the write model and the read model away from one another. This works particularly well if my write load is significantly less than my read load because I can scale up my reader objects to a greater degree than I would my writer objects. Okay. Now, CQRS has, in addition to this being on the client side, has implementations on the server side that say that if I'm asymmetrically scaling my readers, I can use eventual consistency or eventually consistent data source such as MongoDB, which use replication to go out to secondaries and send that load distributed out to those secondary nodes, leveraging eventual consistency. So that's basically event sourcing and CQRS, kind of an obvious solution. I look forward to discussing this with you further on. Oh, and sorry, stop. One last thing. Ping me at Blimp Yacht. I love reaching out and discussing this kind of stuff. So hit me with your best shot. Thank you.