Right now, you might be saying that we could have implemented what we have so far using a database table for temporary users, and that all we'd need is a cleanup batch job to clear out the users that never follow through. However, to do so would be to miss the great flexibility that sagas offer.

At their core, sagas are entities that contain multiple message handlers with shared state, but they also offer the ability to set a timeout, which is like setting an alarm clock to wake you up at some point in the future. This ensures that the process does not have to stop just because no new messages come in.

But what is better than just an anonymous alarm clock is that we're also able to pass some state into the future, so our saga will not only wake up on command but also know why it woke up.

In our case, we want two timeouts. When the user first attempts to register, we want a wake-up call two days later so that we can remind the user to complete the registration, just in case...