Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Reactors can keep their own state including their current position in the event stream. When a replay is initiated it ignores events older than it's current "head."


What happens when the server that holds the thing that holds that state is restarted?


That's an important question to ask!

Can you assume the reactor has durable, local storage with atomic transactions?

The answer is to model your design and use a sufficient level of rigour in validating that your system meets your requirements.

Maybe you could use a database server that has the right properties to ensure your reactor could survive a restart.

What if you want to add multiple reactors so that you can process an event stream with a high volume of events, faster?


What happens when the write of the current position fails?

It's the same problem as presuming that ACK messages in message brokers/queues are guaranteed to not fail.

Since the message transport and other durable resources are rarely able to be enlisted in the same atomic transaction, and since distributed transactions would largely be an antipattern, it would seem that a reactor that records its current position can't be presumed to be an infallible way of ensuring that messages aren't processed more than once.

In the end, it always comes back to ensuring that handlers are idempotent, having something that can be used as a stable and consistent idempotence key, and accepting that the idempotence logic is the responsibility of the handler coders rather than something we can count on generalized infrastructure for.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: