[FeepingCreature]

> b) You're asking for occasional "eventual consistency" trouble when A's state lags or has moved on ahead of the event

To be noted that this is the default if B is recovering after an outage.

Personally, I consider events to be insane. "We create an immutable database so that the state of the system is always recoverable." Okay, cool, very functional programming of you. "But then to actually work with the event from the immutable database, you have to query a stateful service." ??? What? And even fat events only go so far to get you out of that. So with a stream of n events, you don't have n states that the application can be in, but n times the product of all possible states of every other service that you query. How does this help?!

[PaulRobinson]

The bit you seem to be missing is the events are the source of truth, not the databases.

Lose your database? Roll up all the events. Got a lot of them? Take snapshots and then roll up from the last trusted snapshot.

In true event sourced systems, the databases and stateful systems are artefacts that can be thrown away and rebuilt. The event log is the actual “true” database.

Once you design around that, your objections melt away.

And if you think this is some faddish trend, this is how finance has worked since the invention of book keeping and how your databases under your stateful services are working under the hood.

[FeepingCreature]

This only works if your events are in a single globally ordered stream or all your code is eventually consistent over every stream it consumes. Specifically, you cannot do the "query a service for the aggregate state" thing this article espouses for thin events, ever.

[insanitybit]

You can achieve strong eventual consistency with this system.