What they don’t tell you about event sourcing
Good article. I&#x27;ve spent the last year migrating to an event sourced system, so thought I&#x27;d share some thoughts.<p>On the eventual consistency point, I&#x27;ve found you can get quite far with having the read model managing the race condition. This probably doesn&#x27;t work everywhere, but in our system, multiple users can accept an invitation, so we have something like `InvitationAccepted{invitation_id, user_id}`. It&#x27;s possible that multiple users might accept the invitation at roughly the same time, but the command-side doesn&#x27;t really have to be concerned with this - it can happily allow multiple users to accept an invitation. It&#x27;s up to the read model to ask, &#x27;has this invitation already been accepted?&#x27; - if not, the acceptance is successful and will be indicated when queried, otherwise the acceptance is unsuccessful (and as a bonus, we can separately record who unsuccessfully tried to accept it). From the user&#x27;s point of view, when they accept the invitation, they see a spinner until we confirm with the read model one way or the other (this could be done by polling the read model, but in our case we have an event sent back to the client).<p>Coming up with the event schema and versioning&#x2F;granularity are hard. We have version numbers on all our events to make this a bit more manageable&#x2F;explicit (`InvitationAccepted1`, for example). Storing events in a relational database does make it a bit easier to go back and edit&#x2F;upgrade&#x2F;delete them (sort-of cheating, but also relevant for GDPR). Also, I think we&#x27;re going to end up suffering a bit from the &#x27;whole system fallacy&#x27;, but at the moment namespacing all the events (keeping in mind their expected volume) makes it a lot easier to manage.