News for hackers. Stuff that matters.
Re:Event Sourcing Is Hard (2019) by EdwardDiego on Tuesday November 30, 2021 @07:04AM (#29391238)
Most common issue I've ever encountered with event sourcing is that devs submit events that when replayed, lead to invalid states.

And if you're using an immutable log (Kafka/Pulsar/Liftbridge etc.) fixing those mistakes is hard.

And given you're basically recording interim states of a state machine, how do you verify that event Z being submitted after event Y is a valid state transition?

Validating a record against a schema is trivial. But validating three consecutive events against the state machine? I'm not aware of a good way to do that cheaply.

I've done it before using apps that sat in the data pipeline, and maintained state to reject invalid transitions, but that can end up being GiB of state, then you have to persist that across restarts or horizontal scaling.

It's all doable, but it costs. Is the event streaming paradigm actually worth the cost? I haven't been convinced yet.

But, I'm a big fan of streaming DB change events for auditing purposes - but those are coming from software that already enforces valid state changes.

So maybe the answer is - every event has to be submitted via Postgres.

Re:Event Sourcing Is Hard (2019) by randolorian on Tuesday November 30, 2021 @07:39AM (#29391480)
Seems like a fundamental misunderstanding to me. Commands get validated via your aggregate, not events. Events are not allowed to be rejected. Ever. Because they already happened.
Re:Event Sourcing Is Hard (2019) by EdwardDiego on Tuesday November 30, 2021 @07:46AM (#29391525)
Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also.

Anyway, pedantry aside, my point remains thus - it's hard to prevent invalid state transitions being submitted to an event sourcing datastore, and when devs can submit events directly, then these invalid transitions will occur.

Re:Event Sourcing Is Hard (2019) by randolorian on Tuesday November 30, 2021 @08:06AM (#29391670)
> Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also.

Indeed. These are two separate patterns. They can have great synergy when used together but it's not a requirement.

> it's hard to prevent invalid state transitions being submitted to an event sourcing datastore

Apply DDD, use code review, and use stream level ACLs.