Time based Sagas with Event Sourcing

Question

Let's say I wanted to have a saga that get's created by some event, then sits and wait for a few hours, and if nothing happens, sends off some command.

Now, if this Saga was all in-memory and I had to restart the app/server, the saga would be unloaded and never seen again, right?

Would I use Event Sourcing to bring this Saga up to speed once the system is back online?

If so, I would need pretty much a separate Event Store with "active sagas" that can be replayed at system startup, to get my Sagas up to speed. So far it seems good to me, but how would I implement the timeout?

I would need some way of "faking" the timeouts at replay, taking into account there may be several, subsequent timeouts depending on the events going into the saga.

Curst

Answer 1

The best way to achieve this capability is with another endpoint that is capable of returning a message back to you at a certain point in time. For example, your saga may dispatch a message to this "timeout manager" and say wake me in 1 hour or 1 day or even 1 year. The message would then be returned to you at that time. Ideally this message would have business meaning that would cause an action to occur.

Perhaps the best example of this is something like customer signup where, if the customer hasn't confirmed their account within 7 days from signup, you'd notify them via email. The "timeout message" would effectively be: RemindUserToConfirmAccountMessage. When this message is received back by the saga after 7 days, the saga would determine based upon its current state, if that message needs to be handled and a customer email needs to be sent. But if the user has already confirm his/her account, the message can be discarded with no action taken.

Echopraxia

How can I make a Saga that live for 7 days? I'm sure it must be persisted in case of service restart, right? – Dermatology

@MauroDestro You don't really have to keep your sagas in memory when using Event Sourcing. Think of a saga as an entity that you can replay before it should handle an Event. Compare to how you would replay an aggregate before it should handle a command. Using Jonathan's approach to handle timeouts (making them events in and of themselves) makes it possible to replay "time" as well. – Curst