undefined | Better HN

0 pointsmarcosdumay1y ago0 comments

Your event data must not be mutable.

That's kind of the first rule of any event-based system. It doesn't really matter the architecture, if you decide to name the things "event", everybody's head will break if you make them mutable.

If you decide to add mutation there in some way, you will need to rewrite the event stream, replacing entire events.

0 comments

gunnarmorling1y ago

It's not about mutability of events, but about mutating the underlying data itself. If the event only says "customer 123 has been updated", and a consumer of that event goes back to the source of the event to query the full state of that customer 123, it may have been updated again (or even deleted) since the event was emitted. Depending on the use case, this may or may not be a problem. If the consumer is only interested in the current state of the data, this typically is acceptable, but if it is needed in the complete history of changes, it is not.

marcosdumayOP1y ago

Making a wacky 2-steps announcement protocol doesn't change the nature of your events.

If the consumer goes to your database and asks "what's the data for customer 123 at event F52A?" it better always get back the same data or "that event doesn't exist, everything you know is wrong".

gunnarmorling1y ago

> ... at event F52A

Sure, if the database supports this sort of temporal query, then you're good with such id-only events. But that's not exactly the default for most databases / data models.

1 more reply

chipdart1y ago

> (...) and a consumer of that event goes back to the source of the event to query the full state of that customer 123, it may have been updated again (or even deleted) since the event was emitted.

So the entity was updated. What's the problem?

phi-go1y ago

I understand gp to say that the database data is changed not the data in the event.

Surely, some data needs to change if a password is updated?

j / k navigate · click thread line to collapse

0 pointsmarcosdumay1y ago0 comments

Your event data must not be mutable.

That's kind of the first rule of any event-based system. It doesn't really matter the architecture, if you decide to name the things "event", everybody's head will break if you make them mutable.

If you decide to add mutation there in some way, you will need to rewrite the event stream, replacing entire events.

0 comments

gunnarmorling1y ago

marcosdumayOP1y ago

Making a wacky 2-steps announcement protocol doesn't change the nature of your events.

If the consumer goes to your database and asks "what's the data for customer 123 at event F52A?" it better always get back the same data or "that event doesn't exist, everything you know is wrong".

gunnarmorling1y ago

> ... at event F52A

Sure, if the database supports this sort of temporal query, then you're good with such id-only events. But that's not exactly the default for most databases / data models.

1 more reply

chipdart1y ago

> (...) and a consumer of that event goes back to the source of the event to query the full state of that customer 123, it may have been updated again (or even deleted) since the event was emitted.

So the entity was updated. What's the problem?

phi-go1y ago

I understand gp to say that the database data is changed not the data in the event.

Surely, some data needs to change if a password is updated?

j / k navigate · click thread line to collapse