Design Patterns: Why Event Sourcing?

we're gonna go through some of the basics of event sourcing but we're also going to go through some of the history of event sourcing and where it comes from and then at the end what I want to talk about is really where event sourcing is going to be going where are some of the interesting problems that are still out there and people are not really fully into yet now I've been using this slide for coming up on a decade because everything that you need to know about event sourcing you can learn by talking to an accountant accounting is naturally event sourced and literally every question that you have if you go talk to an accountant and you can convert it into accounting words they can tell you how to solve your problem whether we're talking about versioning issues whether we're talking about how to handle what happens when you make a mistake all of these things how to migrate an old system to a new system they already know how to do all of it because they do it every day they are in a naturally event sourced model what's interesting for me is that it's not only accountants every single mature industry that you look at is naturally event sourced every one finance law medical insurance when you go to the doctor does he take a picture of you and put it in the file and throw away the old picture of you or does he constantly keep appending things to the end of your file it's a natural even source model legal what happens if you sign a contract and then a year later you want to make a revision to the contract do you just go cross out a paragraph than you and somebody else initial it or do you add an addendum to the contract and over a period of five years we may end up with many addendums being put on the end of a contract in order to figure out what the contract currently says I take the original contract and then I apply the addendum zone top of it you'd be amazed how many of these systems are naturally event sourced there's a lot of reasons for why we may want to natural and why we may want to events or something but there's one really really important reason it doesn't lose information how many of you have an update or a delete statement in your system today okay now keep your hands up if you went and had a conversation with the CEO about the cost-benefit analysis of that information how much does it actually cost to store everything what does that data going to be worth in the future as a CTO I had one rule for my organization we won't lose data because I have no frickin clue how much it's worth can you predict what your company is going to ask you in two years about today if you can't predict that then you have no idea what the value of which data actually is because it can change over time which is more expensive to store 10 gigabytes of information or coke how much data can you fit in 10 gigabytes it's an awful lot of data that you deleted that you could have just kept but the thing is I have no idea how to value this information so we kept everything now keep in mind we're going back to like 2005-2006 there are points we're storing 100 gigabytes a day can you imagine back then storing 100 gigabytes a day we've used big external masses we'd store all this data on them and you know what it took a really long time to get it off why because when you have 100 gigabytes a day and a hundred megabit network to get data off like took a weekend but I have it what's interesting is you'll find that an event source system is the only system that will not lose data and I've had people show me their sequel database for an accounting system and then I went and looked and there was one table called transactions with a transaction type and depending on the type they would join off to another table to get the data out this is still an event source system it's just they're using a different serialization format but no matter what other system you pick your going to lose some amount of information and it's this losing of information that can cause a huge amount of problems let's take a look at this quintessential piece of state and I've used these four slides literally forever so here we have a cart with n line items and some shipping information associated with it what we're looking at here is the structure of this information we're looking at the shape of the information but this is not the only way of dealing with this another way of dealing with this is we could actually store some events so here we have a cart created three items adding and shipping infirmity on added but at any given point in time I can replay these five events and I could build you this correct I can take my five events play them back in memory and hand you back a piece of state but what we store are the events there's a lot of benefits to storing the events as opposed to storing the state how many of you have written a sequel migration script before it's fun right so one of the main benefits about having events analog as events are much easier to version than status and I refuse to actually do a Big Bang release ever again where I take the system down upgrade it and then bring it back up I will always do side by side releases why because I'm scared I am not scared that I'm going to take the system down try to release it and then everything's gonna break why cuz I'm gonna do a rollback what really scares the crap out of me is I'm going to take it down release it bring it back up and everything's gonna work for a week and then it breaks so you guys are all writing sequel migration scripts how many of you write sequel migration scripts from the new version back to the old version with data having been written to the new schema not nearly as many so I've always joked on teams that I've worked with in the past we can't with a good strategy for this you had your choice you could either wear the fireman hat or the cowboy hat the hats were basically a token to let people know that you were working in production without fail whenever you're working on a big problem in production somebody will come up to you and want to talk about the Christmas party the Hat is basically to tell them look I'm working in production right now unless you have something material to my issue go away but when we store events events are much easier to work with running side-by-side versions why because we're actually taking our state and deriving it off of our events could I have two nodes running side by side looking at the same events and having different states that they perceive them as this is one of the main benefits they can look at it in completely different ways even though they're sitting right next to each other don't have to worry about versioning that state because the state is transient in an event sir system all of your state is transient it may be persistent but it's still transient at any given point in time I can take any of my state in my entire system and delete it because it's a first level derivative off of my event log this piece of state is a derivative off of these events if I wanted to I can go delete this piece of state because I can replay it off of the events a second time now this may be an expensive operation depending on what your system does how many events you have but you can do it now it took me forever to find this particular slide that I've been using for all these years there's a big problem inside of this slide accountants don't erase stuff in the middle of their journals this does not happen okay maybe at Enron what if you took an accounting class in university you might have had a teacher who said something along the lines of accountants use pens not pencils you don't erase things in the middle of your journal and as I mentioned you can learn everything that you need to know about events sourcing by going off and talking with an accountant and if you said to an accountant what do you do if you make a mistake they'd say well I have one of two options so let's say I fat-finger and I send you 10000 euros instead of one thousand euros I could do what's known as a partial reversal and I could take nine thousand euros back from you and give it to me but accounts will tell you they normally try to avoid doing this why imagine you're an auditor reading the books okay so it's ten thousand and nine thousand you can do the calculation in your head really quick and go I he intended to send one thousand euros over but what if they weren't perfect numbers and what if there were five accounts involved well you're gonna end up with pen and paper trying to work out what what I originally intended to do so what they have a tendency of doing is they'll do what's known as a full reversal in a full reversal I'm going to take 10,000 back from you saying that was in mistake and then I'm gonna give you 1,000 we into the exact same thing an events or system an events or system we might say we have cart created three items added one item removed and shipping and from a Tiana did is this the same as cart created two items added shipping information at it well this is always a fun question because you have some people in the room going yes and some going no and the answer is it depends what perspective do you have on the data if I have this perspective of the data those two will come out and be the same at the end correct what about a different perspective what if I was instead counting how many times an item was removed then they would have very different answers there's also a fun game you can try playing in your own system can you come up with two sets of use cases that leave your database at the same state when they're done so here we had two sets of use cases that would return us the same state when we looked at it from this perspective if you can find that in your system you just proved something to yourself you're losing data I'm gonna come back to the question how did you decide the value of that data that you're losing by definition if you have two sets of use cases that come to the same end point you have lost something as not losing a data it becomes more valuable when we start looking at an example let's try this one let's imagine that we were a big online retailer so we've got all of our carts and the business guy comes to us and says I think that people that remove items from their cart within five minutes before they check out are more likely to buy that item in the future it makes sense correct why do you remove an item five minutes before you check out well you went and looked and you saw all those books from Amazon we're gonna be like 400 euros and you thought my wife's gonna kill me if I order that so you take two or three three things out of your cart and then you check out the rest so let's add the feature to this stateful model so we're gonna get a new one of these things coming off the bottom which is going to be called removed line items and when we remove a line item we add it to the removed line items and then we write a report that looks at removed line items and then doesn't nested sub-query to see if you ended up going and buying this in the future we release it to production the user runs it and they see nothing we have lost that information coming all the way up until today when we started tracking it let's try it in this model so what we're gonna write is known as a projection a projection is just a little piece of code that goes over an event stream and it produces a piece of state in this case what we're gonna do is when we see the item removed we're gonna take the ID of the item and put it into our state as well as the time that it was removed we're then going to look for the shipping information at it when we get the shipping information added we're going to basically look at the items that we found and see if any of them were within five minutes if they were we're gonna mark that we're searching for them in the future found equals false if we found the guy that bought this item in the future we mark it as being true now what I have not told you about projections is that a projection must start on event number zero and come all the way forward into the log until it reaches now this may take a weekend you may have a hundred million events that needs to go over gonna have a billion events that it needs to go over but it's an asynchronous operation so cuz all the way through and then we write a report on the state that put out business user goes and runs his report and he sees all of the information as if it's always been there but we can actually do one better I can tell the business user if we had this report on July 17 2014 at 1402 in the afternoon this is what that report would have said all I have to do is to only play it forward in the log to that point in time and I can do this with any report in our system when you give me a new report today I can tell you what it would have told you at any point in time during the entire lifetime of our system that's pretty cool and it's because everything has gone back to being deterministic and we're not losing information I don't want to spend too much time talking about the basics of event sourcing I want to get more into things off in the future and mistakes that people are making well there's one side case for event sourcing that's very very interesting how many of you have had to build a secure system before so if you're talking about secure systems there's one particular attack vector that should make you run away it's known as a super user attack what you're being asked to defend against is a rogue developer or system Minna straighter who is attacking your system it is presumed they have super user privileges how do you defend against root it's actually very common to run into this in highly secure systems the one that I dealt with we were doing gambling systems and oddly we were a high-value target we're the ones deciding who to pay and we actually ended up with a guy hacking our system here's a good helper he actually sat in the cubicle next to me I'm gonna go through the story and probably about two to three minutes but the guy's name is Chris Horne and if you if you put his name you'll you'll get to Wikipedia pages and eventually you'll actually get to a full hour-long HBO special about this it's I believe the show is called criminal masterminds I've always joked but I never understood about criminal masterminds as a show is that they all get caught of course the real criminal masterminds show wouldn't be very interesting either it'd be like and six million dollars went missing from this bank in Toledo and no one has any idea what happened we just know the money's gone so what we were doing was we we had a given pool type was called a pick six and because we were lots lots of tickets in this and for some other varying reasons we would keep them at the remote tracks until the end of the fourth race and then we would pick up the bets and we'd ship them over at the end of the fourth race but only the ones that were still winners and it was Breeders Cup day Breeders Cup is the second largest racing day in America only behind the Kentucky Derby so what Chris was doing was he would go in and he would put in a bet at a remote track one two three four all and then what he would do is he would edit the first four to be the first four winners at the end of the fourth race scan would happen to go this ticket as a possible winner let's ship it over and so it would get shipped over and that that's a possible winner right oh wait it has all all in the fifth and six legs and the ended up getting caught and he didn't get caught because he was stupid he got caught because he's unlucky which is what normally happens with superuser attacks so he does all of this bets get shipped everything's great until a 30721 longshot wins in the fifth and like a 14 to 1 longshot wins in the 6th he was the only winning ticket in the world it was like a three million dollar ticket so normally what's going to end up happening in this case there's gonna be 20 30 winners they're gonna be worth one hundred hundred and fifty grand each mutual manager is gonna see this sign off ship it but if you're the one winning ticket in the world and it's a three million dollar ticket you can be damn sure they're gonna look into that and this ticket was odd so of course you know let's get that remote track on the phone is there anything interesting going on over there oh there's a developer on the maintenance line that's interesting oh the audit tape was ejected that's interesting needless to say we didn't end up having Chris in the office on Monday morning but we had lots of new friends from the FBI but we could have gotten around this problem we could have gotten around this problem by using a worm drive and this is one nice thing about events or system since events or systems are append-only you can run them on top of a worm drive worm drive is write once read many so you can only physically write to the disk once now all of my current state is derived off of my log my log is on right once media becomes much much more difficult to attack me at this point and this is not a primary use case of event sourcing but it's a really nice one if you happen to run into the problem by the way if you're dealing with a highly secure system with auditors and you tell them that your current state is all dry off your audit log and your audit log is on a worm Drive they'll like you a lot it's basically the gold standard for building these kinds of systems there's some other really cool things that I can do how many of you have had a bug in your code before actually a friend of mine a hottie hottie Hariri when I went and looked he had a picture the other day apparently he had an aunt inside of his screen of his laptop and it's like I just need to make a joke about a bug but the worst kinds of bugs are the ones that are transient so the system gets into some state where it's not behaving correctly and then the system gets out of that state and starts behaving again why because they're very difficult to track down one of the nice things about an event search system is just like with projections that we can go back to any point in time my domain model is just another projection I can bring it back to any point in time by only replaying the events up to that point in time so I like to store my commands as a log and then I can see that this command was coming in at this point in time and was getting a weird behavior it was getting errors and I can basically bring it down to a little app that I run that instead of bringing up to the current version will bring it up to the version it was at the time that that command is being run and then I can step through the debugger and see what actually happened my entire model can be brought back to any point in time of the history of the system as well now conceptually we always think about our event log from the beginning to the end but sometimes you may run into a problem what happens if I've got a million events replaying a million events is going to be slow so what we can also do is we can actually go backwards so now we start with event number six we go to number five and then we get what's known as a snapshot this snapshot applies at event number four and basically we can go forward from there basically it's a memoization now it's interesting for me is that over time event sourcing has been picked up by a lot of object oriented developers what's funny about it for me is that event sourcing isn't object oriented at all events sourcing as a functional model how many of you have tried functional programming before Wow a good number so let me explain event sourcing in a different way for you current state is a left fold over previous behaviors snapshots are memoization of the fold okay that's it it's the entirety of event sourcing if you actually go into a functional language you'll have no need for a framework whatsoever you need such really deep concepts as left fold and pattern match and functions and that builds up your entire framework for you normally what ends up happening as well so we end up with an architecture that looks like this so basically we're storing off all of our events but our events aren't really useful for querying purposes I mean imagine I want to get a list of customers with the first name of Greg so I'm gonna replay over all of my events in a MapReduce to get back all the first names with Greg which is gonna be faster that or a b-tree so chances are I don't want to be doing all my queries off of that instead I prefer to have other models that I can query off of as an example we might have a graph database we might have an OLAP database we might even have multiple of them it's okay there's things outside of sequel now how many of you have heard of these before you know you're not cool if you're not using these well with the exception of one of them but I'm gonna tell you a little secret there is no best storage every database on the planet sucks even events dorvan store sucks too in fact when I see these what I am reminded of is these how many remember object databases if about 12 years ago I were to go to Q con London there'd be lots of talks about these these were going to take over the world no one will ever use sequel ever again in fact using an object database that has no impedance mismatch with your domain model so freaking cool about 10 times faster than using sequel and you don't have to write all that crap mapping stuff how many of you use an object database today should have has sound effect for crickets so what happened I thought they were gonna take over the world kind of like these are gonna take over the world what happened with object databases well everything that they were actually saying was true they weren't ten times faster they had no impedance mismatch it was actually really cool and then you put your system out in production and then it's not some cheesy business guy comes up to you and goes hey can I get a report of all of our sales rolled up by postal code in town and you go that means I need to load up like two hundred thousand objects in the memory and iterate over them you seem to remember there was this thing called like group by object databases suck no they don't object databases suck it OLAP and they suck really really hard it'll happen they're terrible for it in transaction processing scenarios they're they're they're reasonably good but for OLAP they're terrible this is part of my sequel is going to be popular forever sequel is not amazing at anything but it's not utter rubbish at anything either you can always get your with your thing to work whereas when we start talking about other forms of databases they tend to be very very good at one thing but then really really bad at some other things and one start learning is that in most systems like this you don't want to have a single model you want to have multiple read models so you can query off of why because using a single model will introduce massive amounts of accidental complexity to your problems how many of her this startup so I don't know how many people have actually read into the history of them and so Twitter at its core is a topic based pub/sub correct so if I were going to implement this you know what I would do I would nor decades of research in the financial industry on topic-based pub subs and I would go take Ruby on Rails and MySQL as my tool chain they got to the point they had hundreds and hundreds of my sequel nodes trying to keep up with their workload and the entire thing was nothing but accidental complexity they replaced it with less than ten nodes later by bringing in people that actually had a background building out topic-based pub subs the entire problem that they had if you guys remember the fail will it was all accidental complexity nothing more and you'd be amazed how many problems you can get into where everything around you is accidental complexity your 16-month project could have been done in a day with a different decision everything around you is accidental complexity the worst part about this is you normally can't see it and recognize it when you're inside of it because it feels like real complexity to you let's try another example with sequel so here we have an ID a parent ID and some data how many of you have built this before so now we we go when we released this to production and they come back and go well this reports been running for 14 minutes and of course you go well it works on my machine we should have use docker so we could ship my machine but what's the difference between your machine and production number of rows in the table you are running with like a hundred they've got a hundred thousand and you built a recursive query so you guys are all good developers maybe you came up with this idea so now you have ID parent ID zero parent ID one parent ID two up to the depth that you want to allow on the tree because now I can do a query where I can say where ID equals or parent ie we do you want equals or parent ID two equals or parent ID three equals and then I can recur some memory this is accidental complexity I worked with a company in America they had tables that looked like this and they had to like half-million-dollar servers trying to run queries across these so they had one table which was people and another table which was relationships what are they trying to do while they're trying to figure out if I can get a link to him through other people that I know based on certain relationship types half-million-dollar servers running these queries they have half a terabyte of memory in them a raise of SSDs they've been working on this project for over a year trying to get good performance out of this I don't even want to know what their sequel server licenses cost for this problem and so I'm getting in and looking at I'm like you know this looks familiar let's install neo4j and graph database because this is a graph my laptop outperformed their $500,000 servers we put it into production the next day and basically we pissed off for the rest of the week because we're supposed to spend the whole week working on this problem but this is common and when we talk about this kind of levels of accidental complexity it's not like I'm gonna reduce your budget by 5% it's like 10 developers working for a year on something versus half a day the wrong kinds of models can cause a ridiculous amount of accidental complexity and the really awful thing is you don't see the accidental complexity until somebody can come and point it out I have watch teams get in the weeds trying to use JSON inside of Postgres and then you show them that there's other databases that actually support Postgres JSON - and here's how they work and they go oh well that's so much easier or trying to use full-text indexing inside of their database as opposed to using something like leucine or solar huge amounts of accidental complexity come off of this and remember that in these kinds of systems we can have multiple models but this is one place where a lot of people get screwed up in events or systems and they like to do this you know it wouldn't be a PowerPoint presentation if there wasn't a big square that said busts on at some place so here what they're doing is they're still using hibernate and writing back to let's say a third normal form database and then they're gonna publish an event afterwards and this causes a huge number of problems the first problem has to do between this publish and the third normal form database because you're gonna need to do this atomically somehow so a lot of people go we'll bring in distributed transactions and now you have two problems but there's other issues that come up inside of this to be fair you can get around the distributed transaction problem by making your database into a queue and this is what a lot of people do they'll actually create a table named queue and insert their events and as part of the transaction into that table and read them out asynchronously to publish them onto the bus but there's a more sinister problem in all of this what happens when I put it in a new model how do I get all the old events to build out my model well I'm gonna need like a control channel or something there correct until I tell something on the other side to publish them all to my queue but when they publish them all to my queue I don't want to publish to all the queues just my queue and guess what we just did we just broke both the rules of pub/sub so the two major rules of pub/sub is one producers should not know who consumers are two consumers should not know who producers are so when I didn't have to when I have to send over a message to the other side going hey can you send me your history that means I know who my producer is and on the backend in order for my producer to send them to just me he needs to know I am his consumer and just think about the IT ticketing system with this it'll be fun but we run into a lot of problems here when we try to replay models also what happens with the old data coming over and now I'm publishing new events do we put them in with the old events do I do I hold them all and give them at the end once we're caught up again of course if we're using an event source system our event log we saw earlier it's basically conceptualized as just an appending file if you want to be a consumer to me all you would need to remember is what's the last event that you processed we could do this with a simple one method interface give me the next n after X and then you remember the last event that you processed so he says to me give me the next 5 after event number zero and I go here's event one event two of them three event four of at five he processes locally and when he's done he puts in his checkpoint I have processed event number five now if he goes down and comes back up he reads from his checkpoint what's the last thing I've processed event number five so he says give me the next five after event number five so I give it to him by the way how many of you could do that concurrently all of you right we wouldn't need to go set up cues and RabbitMQ or or deal with crazy things with a bus all of you would be able to have your own subscriptions now what happens if he wants to replay well he deletes his local data and then he goes I have no checkpoint anymore give me the next five after I've never seen an event before do I need to know that he's doing a replay do we have any coordination logic here if I had all of you of subscribers any of you can replay and do anything that you want on your own we don't have to coordinate no IT tickets and we don't need this concept of a control channel by the way this is also how blogs work a really common way of interchanging between us would be an RSS feed or an atom feed with events in it the atom protocol works in the exact same way can you imagine if blogs worked over RabbitMQ so like you want to come read my blog there's a link there and you say oh I'd like to get you I'd like to subscribe so what happens is that sends me an email that you'd like to subscribe to my blog so I go create you a cue and RabbitMQ and I respond back here's a URI to your cue and everything's good the posts are coming but then you get a new laptop and you say oh I need I want to do a replay I want to get your old blog post locally so just like what we were doing here you're going to have to send me an email to tell me to put all my old blog posts into your queue so you can get them out how many of you would use a blogging system like this there are times when we may prefer a consumer-driven subscription and what we can end up with is a really simple model where we're just following events using this really simple give me the next n after X and when we bring up a new model it's absolutely trivial it just starts out without having a check point you can replay at any point that you want there's another benefit did we get out of this architecture I can have multiple of the same model I can have fifteen instances of my OLAP model and we put a load balancer in front of them load balance two queries between the fifteen different databases it's a very common pattern now in terms of read models my personal favorite read model is going to be something like Ascot a star schema all that model why because I don't like writing reports I work mostly with people and things like finance and gambling and you know these people they tend to be really good with Excel so I give them a star schema database and I let them connect to it with Excel and they actually prefer this to me writing them reports now when you start getting a lot these people you might want to have multiple instances of this there's all kinds of other cool reed models we can have one question I like to ask people is what information on this screen changes depending which user it is nothing I know great read model then HTML on disk I'm pretty sure we know how to scale static HTML these days but the key here is we must be able to replay this information briefly I want to talk more about the future of where we're going because there's a lot of areas that are very very interesting but a lot of people haven't gone into them yet the first one is functional programming too many people are doing event sourcing and object oriented languages try the functional way of doing it it's so much cleaner and to be fair you'll actually understand event sourcing a lot better as well the move from a way a lot of people are dealing with data to event sourcing is conceptually very much the same move from object orientation to functional where in event sourcing everything is immutable and append-only a lot of thinking is functional in its nature next big thing multiple timelines and you've all probably dealt with an end temporal system before how many of you have a bank account have you ever noticed that you have two balances one is called a ledger balance and the other is called an available balance what they're representing is that when I put a transaction in I may not necessarily be putting a transaction in that is effective right now and the two different balances represent two different ways of looking at the same time lines one is on when it came in the other is on when it is effective there's a lot of work going on with this right now and trying to get into systems that effectively deal with n temporal data this is a huge problem for a lot of financial companies trying to maintain n versions of timelines and an events or systems this is actually relatively easy to do and I think we're going to see more and more and more people focusing on this problem because it exists in a lot of industries and it's being solved poorly in many of them the other place I think we're gonna start seeing a lot more of n sourcing is in clients how many of you have tried to build an occasionally connected client before a client that works when you unplug the network cable and start synchronizing things in an append-only model it's far simpler to deal with synchronization than it is inside of let's say a model where you're just mutating things in fact many of these kinds of mobile apps or now people are even doing it with browser-based apps many of them become trivial and I think we're gonna start seeing a lot more people doing client-side event sourcing now just to summarize in future I think we're gonna start seeing a lot more around multiple timelines out of everything that I've said today probably one of the most important is that a single data model is almost never gonna be appropriate for your system almost never you're gonna end up with two or three you may end up with let's say something like a MongoDB but then you also have a problem which is a graph so you hang up with a graph database for that problem now before you go back and say Greg told us we should have a different data model for every report that's not what I'm saying understand that for every one that you bring in there's also an operational cost if you bring MongoDB into your organization somebody needs to know what the hell it is how do I monitor what Chad look for in logs how do I do it back up what do I do when it randomly loses my data somebody needs to know all of this stuff and we need to understand there's a trade-off operational cost versus development cost and how simple our system is going to be it's not that you should just willy-nilly bring in all these different models but you should consider it understand that it's an option if you have events that have been stored it's relatively easy to bring in new models it's delayed there we go remember as well that picking the wrong model can cause you a massive amount of accidental complexity and again this is this is not a 5% savings we're talking about oftentimes it's like a ninety-nine percent savings off of project costs and if you don't believe me I want you to go try to hire a Java developer to build you a blog and you're gonna go to hire them and they're gonna dig blog okay we can do this so what we're gonna do is we're gonna bring in we're gonna bring in a spring and hibernate and you're gonna be sitting there going WordPress it's the same type of thing often times we're talking 99 percent cost reductions by choosing the right models and the last thing is that event sourcing is functional it's not object-oriented trying to implement event sourcing in in object-oriented languages tends to obscure what's really actually happening whereas if you try it in a functional language it becomes very very clear what is happening and it's explicit and there's no magic going on like using reflections or it's very very explicit what actually happens and with that I will thank you guys for coming out I hope everyone a good rest of the conference if people have questions I will be around during the rest of the conference and feel free to come up and ask me questions and again thanks [Applause]

Channel: Coding Tech

Views: 127,766

Keywords: event sourcing, events, databases, software development, technology, architecture, patterns

Id: rUDN40rdly8

Length: 48min 59sec (2939 seconds)

Published: Thu Dec 14 2017