What they don’t tell you about event sourcing
1–10 of 81 posts
Re: What they don’t tell you about event sourcing
#2They didn't even tell me what event sourcing is.
Re: What they don’t tell you about event sourcing
#3Hopefully bi-temporal tables get added to Postgres soon.
I think it would cover a few of the use cases that people are turning to event sourcing for(excluding scale).
Re: What they don’t tell you about event sourcing
#4They didn't even tell me what event sourcing is.
It's in the second paragraph. But I agree that it's a terrible name.
Re: What they don’t tell you about event sourcing
#5They didn't even tell me what event sourcing is.
As I understant it:
Consider you have a database where you store the account balance.
If you want to update the account balance you might update the row for that customer, e.g.
tblAccounts ------------ | AccountHolderId | AccountBalance |
update tblAccounts set AccountBalance = @NewAccountBalance;
In an EventSource database instead you wouldn't update the AccountBalance column. You would store something like:
AccountEvents | AccountHolderId | AccountBalance + 100.00 | AccountHolderId | AccountBalance + 150.00 | AccountHolderId | AccountBalance - 80.00
Then ifyou wnat o get the current balance you can just take the opening balance and add 100, add 150 and subtract 80.
Periodically you need to collapse these as querying for the balance could end up requiring going through a large log of events. So you snapshot at some point in time. So assuming an opening balance of zero, we could snapshot the above to 170.00.
It feels like you get auditing / logging of all changes out of the box, also if you are working in functional programming or a system where you constrain side / mutability as much as possible you sort of eliminate your db as a giant mutable object. But you also get the downsides this article talked about.
Re: What they don’t tell you about event sourcing
#6They didn't even tell me what event sourcing is.
Just think of it as double-entry bookkeeping. It's been around for a while. :) The events that we record become our source of truth.
Re: What they don’t tell you about event sourcing
#7Re: What they don’t tell you about event sourcing
#8Regarding eventual consistency, a CQRS\ES system can also be synchronous, or partially. You could have listeners for events that need to supply a strongly consistent model and others events that feed parts of the system that don't need strong consistency.
"However the events in a event store are immutable and can’t be deleted, to undo an action means sending the command with the opposite action"
Well they don't have to be immutable. I don't see why you can't update/migrate events.
Re: What they don’t tell you about event sourcing
#9They didn't even tell me what event sourcing is.
In a nutshell, instead of storing a current state of the data in a database, you store the "event", i.e. the information about the data being changed. You can also additionally save the current state, either at the time the event is saved or independently, but that simply acts like a cache when reading data; otherwise you would have to replay the whole events history to get to the latest state.
Re: What they don’t tell you about event sourcing
#10Good article. I've spent the last year migrating to an event sourced system, so thought I'd share some thoughts.
On the eventual consistency point, I've found you can get quite far with having the read model managing the race condition. This probably doesn't work everywhere, but in our system, multiple users can accept an invitation, so we have something like `InvitationAccepted{invitation_id, user_id}`. It's possible that multiple users might accept the invitation at roughly the same time, but the command-side doesn't really have to be concerned with this - it can happily allow multiple users to accept an invitation. It's up to the read model to ask, 'has this invitation already been accepted?' - 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'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).
Coming up with the event schema and versioning/granularity are hard. We have version numbers on all our events to make this a bit more manageable/explicit (`InvitationAccepted1`, for example). Storing events in a relational database does make it a bit easier to go back and edit/upgrade/delete them (sort-of cheating, but also relevant for GDPR). Also, I think we're going to end up suffering a bit from the 'whole system fallacy', but at the moment namespacing all the events (keeping in mind their expected volume) makes it a lot easier to manage.