Event Sourcing   You are doing it wrong by David Schmitz

Event Sourcing You are doing it wrong by David Schmitz



nice let's get started welcome thank you for coming show of hands who's here to just save a seat for the keynote be honest I know you are okay winces you're doing it wrong actually I wanted to submit this title you're doing it wrong because I know obviously best I've been working those systems for a couple of years now and then I realized that I know nothing because this is really complicated topic nothing works really out of the box so there's a third title event sourcing you're doing it wrong maybe in some parts because we made mistakes and so will you and there are no easy right wrong answers and everything is difficult nothing is really black and white but if you try to submit this title to a conference you get rejected so let's settle on the final title maybe probably you're doing part of it wrong so that's that Who am I I'm David I'm from Dusseldorf I'm big fan of Fortuna düsseldorf best footwork look nice thank you and if you want to link up with me you can find me by hakuna shot sir it's a long story why that acronym you find on Twitter on github Playstations which were whatever you want I work for German consultancies in a coop we are really small just 500 people and we build large systems for large companies like financial Institute's insurance companies logistics so no Greenfield hello world project actually and feedback you have to use those hashtags I was told quick show of hands before we get started who's building Marco services in production so deaths had s hat if Anthony this has changed keep the hands open up who's doing micro services and domain-driven design okay nice nearly you I think 40 people are you doing event sourcing with well I would like to talk to you afterwards to people I get about four so what are we going to talk about we are talking about typical misconceptions when people are doing event sourcing there are some some terms that get confused and and we try to clear it up here okay and I will talk about some patterns that we found useful in our projects and real-world projects I will show you some traps that you will fall into and you should avoid probably because things get costly this is not a calf current if you know me I tend to run to my talks I do not do this here I love Kafka Kafka is an amazing product just maybe not as an event store but that's my opinion and keep in mind that that is for all the talks at a conference what works for us might not work for you and the other way around I will not try to sell you snake or easy solutions so keep that in mind okay and as I have only got 47 minutes left I can see on the screen down there we can only cover the tip of the iceberg if you want to know more on each topic feel free to come to me after conference this evening whenever and ask about it I saw that a couple of you already are doing event sourcing nevertheless I want to cover some basics namely I'm a principle architect so let's talk about event sourcing from an architect's perspective why did I'll be doing event sourcing well everybody's building micro-services obviously and then you have to answer the question how do these micro servers actually communicate how get data exchanged and the easy solution is of course by a giant database that scales vertically put it in the middle and let everybody integrate via data works awesome if you have licenses and you earn with those licenses then there's other different approach where I like you have different micro services they have each their own database maybe Postgres something like that and to communicate via messages or via HTTP might work and there's a different solution namely enter Kafka or another events or anything just something that can store events as the golden source of truth dumain and then the microservices exchange events and lalala and then there's a REIT model super easy everything and let's put in a data lake because everybody needs a data like who has a data Lake oh I wonder why and that's what the discussion stops never mind the details just a couple of events read models what could go wrong and that little guy just the magician he will help us in my talk so event sourcing the basic terms events those things actually founded in domain driven design so I would expect when you are doing event sourcing you're doing event domain driven design I can't imagine a different way then we always use event-driven architecture when we are building events or systems not the other way around event sourcing is not an architecture event-driven is the architecture and last but not least I've never seen a monolith build in an event sourced way maybe there's one outside if you're building one tell me usually we use it in distributed systems so again we start with our domain we find the bounded context that will later be our micro services right then we find the important names that's basic object-oriented analysis nothing new then we try to find the dynamics in our system in our business like user on-boarded transaction booked those will be the events in our event store on a technical level we have events something we store those events in streams so streams are a collection of events those things are stored and in event stores don't do not confuse event store with the product events the events of the general term you can use a MongoDB as the event store you can use whatever you want as an event store you'll be maybe not successful and then you can use projections projections are some kind of code that takes the events of the stream and computes the aggregate we will look into that deeper later and that aggregate can be stored in a read model that's the general understanding there at least from my perspective concrete example we have as an event to use on-boarded user on border to stored in a stream specifically for me you David we use as a product event store it's an open source project and if I want to know the current David we can build with some logic to David at the 19th of November at 8 o'clock in the morning and there are eight models we store them for stress easy so once again we have our stream events are ordered in the direction of time use a registered user on-boarded use a relocated stream event payload that's just terminology once again an example for projection we have our stream and the projection is basically a collection of handlers that's able to eat up the events in the stream and build a user aggregate as a certain point of time so in conclusion events sourcing is just the answer for how we can handle data and distributed systems in a scalable way one giant monster database will not get you far I can promise you that and which is far more important using events everything I can't speak when he's taking pictures everything you're doing in your in your domain your business is a first-class citizen so basically it's decoupling on a business level so read models reading is important but read models are highly overrated you might not need them read models are that's an awesome description actually our local hydrates of the events start in specific streams what does that mean as I said before we take all the events in the stream and we basically left fold with a collection of handlers nothing difficult there but we saw that current user David at a certain time what can we do with that thing and just the magician has the answer for us every micro service gets its own database right so we have a user microservice that takes care of users and that's insert a what's a cool secret store or Postgres of course so we insert a secret store and here's a representation of what what i mean you can see that you use a table and we have to use ready la la la and remember the last event ID and there are only three events so the last event ID that we read is number three number three and we have David with a certain email address easy and if another event event arrives we just update that secret store right easy event number four and the new email address and the cool part is let's say we don't need a secret store we want to graph database we throw the database away and look you up there you have your new for J so end of talk maybe not there are challenges namely eventual consistency it's an awesome concept everything is eventually consistent actually but it's a pain in the neck when you try to debug those systems Friday evening 11 o'clock so just imagine an event arrives and there has to be some logic that actually updates the simple store so there's a time delay between that and if you try to read that things you have to build complicated systems then what about I just mentioned we throw the sequel store away and build a new 4j instantaneously I don't think so so you have to come up with some solution now to deal with replays and rebuilds what about redeliver is our if you have to see a system that actually works with exactly once deliveries if you have one tell me I would be grateful and your Ops guys and colleagues will be super excited if every Microsoft gets its own database in Germany where we are rather cautious with our data so you get not two complete freedom there so but the good news is you do not need a weak model read models are totally overrated and that depends on the strategy for storing events what is the general advice when we look at storing events you know typically it's like this we have all the events for users and user stream super easy so we can find everything if I want to know something about user a I just run through that stream and read all the events of user maybe not maybe as a better approach maybe we could just introduce one stream per aggregate I get my own stream you get your own stream he here on stream everything is with its own stream and the good part is if you look at it each stream is super small there are four events six events ten events and that's what we find in practice usually if you if you construct your aggregates in a nice way in the same way your streams would be small of course there will be there will be streams that are rather large we'll come back to that later but in general streams will be small and then when we try to get the current user like user B we actually read the stream each time we declare our handless yes JavaScript or F no no on our left and we actually read that stream each time there's no framework that's actually just what we write we read the a grid from stream stream user B and we start at the head of the stream and we apply the handlers and schwoop see whoops we have our aggregate no magic involved no concurrency it's consistent we don't have any extra databases and the programming logic is super simple I love simple logic but what about speed it sounds slow actually it isn't it's super fast he is a entity with 100 100 events in it and we take 66 milli seconds without optimizing and let's say that the user stream what did that user do change his name age each day I don't know so your stream should be smaller and your your speed will be faster and do not forget we are talking about data that is immutable so you can use heavy caching in that sense if you have to need what about queries we can't query a stream right I think Kafka is no ok SQL what is called kql but even so doesn't so let's say we want to have all adult users then we can build a projection and the event store which I'm talking about has an option to actually aggregate all the events from all users that that's a category projection never mind the details the idea is we have our projection and we let that projection collect all the events that we need and then we can use the adult users projection like we did any other stream and read just that so it's basically in manifested query just remember your event handlers are neither CPU nor i/o intensive usually most of your handlers will just be get us and setters and getters and setters nothing else keep your aggregate small and you will be happy and please by all means before you introduce some database because some papers that you have to measure and then optimize not the other way around so now we know how to read from a form of sequel form from an event store we know how to get our data but how do we write data and especially how do we guarantee correctness in that sense let's talk about an example that's a typical banking example and we are only allowed to withdraw money from our account if our account holds enough money and actually of course banks do not operate that way banks love if you over draw one day that's their business model I should know the first thing we need to do to realize is that the correctness of whatever we are doing depends on the order of the events here's an example we deposit money we have one on euros we withdraw ten euros then we try to withdraw 97 euros obviously illegal gets rejected and then we once again deposit 50 euros and we end up with 140 euros if we shuffle the last two events it's a different picture then we can actually deposit 50 euros we get 140 and then we can withdraw as we wanted can we use the read model in those cases for fast validation like let's say we want to make sure that we update only where if the account holds enough money well that wouldn't work also so but that would work if your systems were a single-threaded who's building a single threaded system with only one instance you are really okay not bad so it should be obvious now we have two instances of the same micro service one get two requests checks if the account holds enough money it does and at the same time basically the other micro service checks also and it's also okay and then both withdrew a money at the same time and your account goes up in flames so validation against the REIT model is always prone to inconsistencies and what's the general advice there of course a magician has an advice just put a simple database in front of the event store works like a charm and that's awesome and here's a link to one of those people and I'm not hitting on one confident that papers actually pretty pretty nice and describing how to put Couchbase in front of Kafka so that you end up with a real single source of truth so just a database in front of your event source a store and off you go yeah and if we have operations here's a tip if you want to make good friends there go to them and ask them to install a production rate Kafka and Couchbase on AWS within let's say four weeks they will hate you instantly it's another way yeah just realize that the aggregate is responsible for enforcing business and variance that's just domain driven design the a grid in our case is the account with the current balance of 30 euros you know and if there is an event that says I want to withdraw 50 euros and I want to get into that stream our police officer actually enforces that that event will not be accepted so basically the aggregate is a transaction boundary who is using hibernate is that still a thing in Java land um 30 percent I guess so you should be familiar with that and you can go to sleep optimistic concurrency control who has never heard of that there's some people so good that I explained it optimistic concurrency control is nothing new it's just a basic concept that we think that we can do multiple things in parallel and in most cases they won't conflict and each transaction is running very fast at the state it's going to update is actually the same it's right before super easy what's the happy path in event sourcing we have our stream you a couple of events money deposited is the final event with event number five and I want to exceed some business logic so I built you a good as always and I have to remember the event number that's the important part that's used for optimistic concurrency control like the version field in JPA so we remember that thing we execute our business logic and we want to omit money withdrawn before we do that we compare both version numbers they are equal and but now we can enter this free no problem there the not sloppy path is trivial basically the same thing here you can see the last event number was number four so we build our aggregate we try to do our business logic we being good citizens we remember that ID then some sneaky person inserts another event into that stream but the number five so then when we try to compare both version numbers we see that they don't match up and when we want to admit money withdrawn we can't so that thing gets rejected that's optimistic concurrency control in streams so when we want to update that thing an account with the number one two three four it's the same thing as before super easy programming model we read the aggregate we remember the last version number we execute our business logic and then we omit the events passing in the last version number that we read super easy no magic involved no frameworks and what about Kafka can we do that there also I guess maybe there's some some some extension I've checked there JIRA and there's this nice theoretical two to six oh where a person requests the ability to specify an offset like a target version before producing an event which the proposal actually says would be very handy if you're building events or systems but obviously people think differently and it's a minor priority and still open so I wouldn't bet on it so what else you see you get scalability without locks you get consistency for it's a design choice you can use it where it makes sense maybe you have streamed where it doesn't matter if you just depend upon depend and you don't have to check it and no frameworks you will get this often in the store I hate frameworks so we know we know how to read how to write what about versions you Java developers we love versions but how can we deal with versions without going crazy what's the general answer in Java and what do we use of course semantic versioning right and types so the producer emits events in an account stream whatever those screen events and being good developers we like reuse we share them we put everything in one jar for reuse and our consumer on the other hand that wants to read that stream can easily reuse that eventual super easy then we change sometimes also super easy so the producer produces money deposited version two puts them in a new jar for reuse but a consumer doesn't use that what will happen a good friend the invalid classic section will happen a magician has a author solution they're just double right it's a technique you will always find in events also made easy papers just write both versions money deposited and money deposited to why not the problems for the consumer when reading that stream at a certain time the consumers know should I process this version or should I wait for another version which might or might not arrive so can actually decide and on the coding side when we have all this different version of an event with all those different handlers that have to be written that sounds like fun yeah right because in that case we can use something like knob caster I think somebody here for a familiar with accent with the accent framework so you have to I think accent has something like knob caster for you and the idea is basically that that up caster sits between you and the stream and is able to convert events a certain version to a different version so that consumers only need to basically consume a certain version so the complexity goes into the up coaster but five months later you will typically find that up caster gets really complex and I don't like debugging complex monsters the fact is that we at least dropped versioning our events we don't do that anymore because it's just a fact of life that a new version of an eve of an event of a new event must be constructible from the old version so let's say you introduce a new field like shoe size when you want to open your bank account then there must be some kind of a default shoe size otherwise we declare it's a new event and then you have to handle it differently it's an easy way for scaling actually but when we not store classes or objects in our streams what can we store well we've done some research and came up with a solution simple text-based human readable events which is fancy speak for Jason yes Jason not yam it looks like this is not the actual structure of our events is similar to that and you see it's basically human readable I can give it to you even understand what's going on and that's not a real eben I know and you see the event type you see the accurate ID and everybody knows what's going on but Jason no types terrible what about correctness yeah actually stringy typed events work really well I know I will get burned for that later but that works actually and if you need there's something called week schema which we actually use it's JSON schema looks awful but works you can oh oh my god I see the title of that event it's terrible you can declare the title off of your event you give some description you can declare all the different attributes contained in the payroll of that event like in this case the new users ID and you can even declare a format and so and so on and then our systems only the producer asserts the correctness so when you actually want to send a new event or emit a new event you assert that's a GV that's a node.js library you assert that the event actually conforms to that schema and then everything is fine the client does not have to recheck it just accepts so basically you could say that we use that schema as a description not as a contract contract would be on both sides but we trust the sender now that we know how to send and send and send and send and emit large streams what could we do if we have large streams I told you in the beginning that mostly your streams would be small and that's the case but there will be cases like a transaction ledger which will grow how can you handle event data over a long period of time actually you don't actually the magician is right on track he suggests creating snapshots of those people who are doing event sourcing who is building snapshots anybody here I would really like to talk to you afterwards I would like to how you do it actually we do it the different a little bit differently there's something that's called the years and procedures from accounting and if you want to know anything about event sourcing always go to your account the Department they will know everything it's basically a procedure that they apply to your bank accounts if you look at your bank account you don't get all the transactions from ever you just get them of a certain period of time like 90 days 100 days depending on your bank I guess so what they do is at the end of a certain period they compress your account into a new starting point like okay and the first off of of January David has 15 euros on his account and off you go and the same can be done in event store system and that's called copy transform I like to call it event sourcing refactoring power tool copy transforms basically a giant Hilty how does it work it's actually pretty simple let's say we have our transaction ledger for 2017 with all the different events and imagine many events and now there is a new time period namely 2018 what we do is once again we compress the state into initialization state that's like building the aggregate of a certain time period that basically my account at the end of the year 2017 then we omit in the activation event to the original stream we link both streams we do not delete the other the other stream that's really important because you might want to generate reports across multiple time frames and once you have done that you can start actually emitting events through a new stream and off you go for microsoft's is also possible like at one time you have in the old stream and you start your your clean-up period your your years and procedure you have the deactivation event and the initialization event and since that the activation event contains the link to the new stream the transaction logic can just switch over easy right well maybe not so easy because that little switch which are indicated with those arrows there's some magic involved if you can shut down your systems when you do that for a couple of seconds it's easy if you have to do that at runtime things get messy and you will get gray hair like I have it's basically the same idea if you want to remodel your domain let's say you have something like this and I find that all the way if you don't remember anything of this of this torque doesn't matter remember just this tiny fact if your event contains something like blah blah blah and blah blah blah then it should be two events not one so let's say we have that transferred and booked and we want to fix that that's the same idea once again we introduce a new stream we initialize it we copy the complete data over to the new stream and then we basically copy transform the original event into two different works like a charm and we can deactivate the old stream works like a charm with all the framework works out of the box basically just the question is at runtime or not at runtime the devil is in the details actually to be honest they're dealing with arrows the probability when sauce is always better to I get told is that we can't fix errors in this in the events right like in this case that's actually from a from a concrete project of mine where the business sides decide not to actually isocodes but they wrote euro and British pounds and whatever yeah it didn't find that soon enough so let's say we have that amount and it's not nice according we only support isocodes we could just update the event store right let's say we've built on Postgres yeah sure we can look at here here it's just update transactions and set currency super easy early early break well maybe not don't do that even if it's easy even if even it is supported let's say we have a consumer and that consumer consumes all these events and then you update the third event and the consumers like me I already read that I won't read that again and maybe the consumer has executed some side effects because of the old event so whoo and then we would just use compensation actions if in anybody here back in the day when we modelled with with graphical interfaces we modelled with XML or web services that's still a thing and there was always this compensation action which is super easy and nobody ever did that correctly well you can do it correctly and that's once again from phone accountants it's the cancer the corrected event and there are two different flavors there's a partial compensation which works like this let's say we have our buggy event we emit a new event money transfer amount corrected and we refer to the original event and we just submit the amount is correct I do not recommend partial compensations they are not easy to understand if you look at your stream and in two years you don't know what's going on you have to understand the complete history so let's do as consultants 2's accountants to full compensations nothing else the same with your bank let's say I transfer one odd euros to you and I used two wrong account number they won't correct their account number and I hope not they will cancel transaction and create a new one maybe so once again our buggy event we emit a cancellation event which makes totally explicit and there we can reinitiate our business transaction why is this better I told you it's obvious the reason for compensation is explicit there's no hidden agenda is no magic there's no I have to dig through through locks it's clearly stated cancel the transfer of money bless you so the last and the most fun part actually GDP are compliance and event sourcing who has never heard of GDP are there's actually a couple of hands raised where do you live Julia if you work like myself for the financial Institute's and insurance companies GDP are is really fun and there was a colleague of mine who was super happy that he reduced the number of policies from four thousand something to two thousand something so good for him I am NOT a security expert but actually as a German citizen I like GDP our GDP was good good from for myself I don't mind signing at my doctor that he can keep my email address but I would like that certain other companies would be more or we'll put it careful not my data so GDP are what is it it's actually a regulation of the european parliament and of the council of 27th of April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data and repealing director I'll stick to GDP are okay that's the title the actual title so I'm not making this up I've read that whole document it's awful but the only thing that's relevant is actually article 17 that's what we are going to talk about that's actually the right to be forgotten you can go to any company at least in the European Union and ask them to delete everything basically that your data will come to that point but your data is later you can ask them to delay anything without any undue delay and this on you delay as yeah it's nice there's one thing that one solution that sometimes proposed just encrypt the stream and throw the key way and it's super easy the idea is every stream has its specific key we use that key and nobody can read it so we have three different streams lilac yellow and green lilac key Lila yellow key and green key so you need that key to unlock that stream so you can read all the data and when a user demands to delete all this data you just have to throw the key away super easy so we kill that key all those events are away and we can't read that anymore right and I think they're once again accent has some support for that I believe right super yeah maybe maybe not the free lunch maybe there are challenges I have yet to see a key administration tool that's fun to use you know they're they're always a pain and I came as a pain in the neck although it works and working for for financial Institute's in Germany they don't use kms they use something built internally which when you have to wait for a key for six months so maybe not the best thing and then there's the point you have to find what you want to delete actually you have to look through all the streams and depending on your stream and event strategy finding what needs to be deleted is actually difficult there are large implications okay in the cloud edge storages actually maybe not our biggest problem but nevertheless there is you go gathering garbage data coding complexity depending on what you are doing whether or not you are working in a polyglot environment like we are we're not only using Java so we are doing JavaScript and Python and everything you don't want to rebuild a framework for encryption and decryption every time and most important it's really difficult for operations if you want to debug what's going on handling out keys is really really an issue turns out being able to delete it's kind of cool databases are doing some things right yeah concrete example let's say we have three different Microsoft's that somehow relate to each other and we want to delete all data what we can do is we actually can use tombstones since super easy concept it works actually like this let's say we want to delete the user 456 when that happens the bank account service gets notified that that user was deleted then we can clean up our bank account data and we can omit that to the outer world events the once again has a solution for that that's a special stream that you can can subscribe to and that will contain all the the events that relate to the deletion of a stream whenever a stream is deleted you will get a stream deleted event in that stream so those Microsoft's can listen to them he is once again an example we have our user micro service had asked the event sir to delete that user so we can delete that user and then the event store omits that tombstone event the bank account micro service intern listens on those events and listens for deletions of users the bank of micro service knows which bank account belongs to the user and it can ask events total eat that stream in turn which it does obviously and then emit a new tombstone super easy events forcing GP are solved with the right tool but what about if I delete my conference account let's say we are all using conference as a wiki let's suppose we do and my account gets deleted should my editing history vanish should my team's my pages that I've created should they vanish too or it's just no separation that is basically the question what is if you have events that are related if I transfer money and my bank from my account to your account and after that I cancel my account at that Bank that transfer is not vanished that data is still there so one technique you can apply is the public private data it's a simple technique actually you just split public data and private data of the same of the same aggregate so in the upper part you have a technical ID which is generated and some my favor calab do know yellow and then there's a private stream where my name and my license plate and that's not my license plate and when you want to delete something you keep the public data and you delete just the private data so you can link up all the events and you get your complete tree you may be able to keep that data may I can't tell you for sure that advice that just anonymize doesn't work not but gdpr because there's a recital 26 which often gets overlooked and the basically states that when you anonymize in a way so that you can trace back to original user then it's not anonymized and it's personal identifiable data and has to be deleted so surprisingly no easy answers but I can tell you ask your lawyer or your security officer they will know and they will be afraid and not help you so that is already I have to insert a cat picture otherwise it won't work actually we need a couple of minutes more longer so don't go away event sorting the window design belong together I have no idea if we separate those two how you would who is not working in an age I process everybody is working in and scrum or something else be honest you are among friends we won't laugh at you but honestly if you are doing like like two-week Sprint's or one-week sprints or three weeks parents I sometimes have the impression that we have not enough time to really think through complex architectures and evaluate where we are going hard to find time if you are running at a high velocity so event sourcing might need more time you might need more time to see how you want to cut up your streams how to want to build your aggregates the good news is you can refactor if you have made some bad decisions in the past you can refactor your streams you can refactor your events it's possible copy transform that's your solution I find that there are not enough in-depth books in general events or things either discussed on a hello world we are in crazy academic papers which are taught to read at least for me I don't want to make enemies here but I avoid frameworks like like hell at least and most systems that I built now I like simple to simple libraries and especially if you are building polyglot system for many languages I would rather recommend to stay away from frameworks and prefer libraries and last but not least never trust somebody who tells you bla bla bla made easy or just do following it's never just just as just the first page and then hell it's always that yeah I've been burned in the past so anyways forget everything I said rather go to the book store read some papers there are a couple of good ones actually each one is highly recommended top left you will find the dark side of events sourcing that's actually about schema migrations in large events or systems and that that discusses in depth what you can do at run time if you shut your system storm what's the implication lalala really really great paper below who doesn't know won't burn anyone here everybody knows one Verne okay cool he's one of those those those poster people of domain driven design and that's a series of paper off of papers PDFs openly available for modeling aggregates that thing will change how you design your objects promise the thing in the middle is a new book from Greg Young Greg Young is also one of those masters of event sourcing and it's published on leap up so it's not really finished but it's already a great read and most of the proceeds go to charity so instant buy I guess and that's about versioning and events of system everything I know I know fun basically and last but not least there are some people foreign from Microsoft here and I was wondering if they still know that that paper which is actually awesome it's basically kind of a diary of a project or projects that try to adopt sakura-san event sourcing and how they approach the topic it's kind of data still a good read I've mentioned a couple of times choosing the right tool is essential which shows event store it's an open-source tool not a framework it's an open-source tool that it's written in c-sharp gets compiled with mono and runs on Ubuntu which is kind of scary if you ask but what what do you say it works like a charm and the documentation is awful it's good I have no idea why they write nothing but the community is awesome the developers answer all the time and select your answer on Google so you don't have to be afraid to ask stupid questions so yeah great tool and that's basically all thank you for listening and please vote give ratings and not only at devoxx voting is important questions [Applause]

18 thoughts on “Event Sourcing You are doing it wrong by David Schmitz

  1. Suggestion- Next time avoid drinking water style showcase please , I was using headphone and yours water sound through your throat was annoying. BTW very good presentation

  2. If eventstore documentation is awful but the community is great, how would you choose this library vs every other one out there?

  3. How does GDPR deal with the requirement of storing data for fraud detection as a bank? I cannot image a customer can have his bank history forgotten to be hard deleted? Doesn't the government require an audit trail in case you are charged in court?

  4. Optimistic Concurrency Control is nice in a lot of places, but in this case, isn't it easier to keep the state of the whole system (or at least the subsystem that needs to be consistent) in a single thread that you submit commands to that get validated and turned into events in a fixed order that is guaranteed to be valid? As he said, it's usually neither I/O nor CPU intensive, so that single thread is going to be fast enough to deal with an awful lot of traffic.

  5. First part is about Partial Ordering of events which guarantees Causal Consistency model in distributed systems. Don't think that it comes for free though.

    The ability to specify an offset on emitting events to Kafka (aka "Lamport Clocks") creates a "lock" per partition what impacts performance as you have many concurrent producers. Besides, you need to emit events for the same Aggregate into the same partition – that reduces the Availability.

    Those are the right things to do though if you want to trade the Performance and Availability in favor of Consistency. And most likely you want to do so instead of putting that complexity into the application layer. Just be aware that the approach has its price.

  6. One stream per aggregate is, of course, the way to go! Also – both logically and physically distinct.

  7. The slides from the presentation can be found here: https://www.slideshare.net/koenighotze/event-sourcing-you-are-doing-it-wrong-devoxx

Leave a Reply

Your email address will not be published. Required fields are marked *