I’ve done a lot of searching and haven’t found a good example or explanation that answers my question. I’m curious how people out there are handling the processing/dispatching of events that result in the sending simple notifications via email, SMS, etc. These notifications should be sent once and only once with no chance of event replay triggering a resending of the notification and should potentially retry on failure to send. I’ve thought about using a live subscription to accomplish. My concern is that if my live subscription goes down for a time, for whatever reason, I’d be losing out on any notification triggering events that occur during the downtime. This leads me to using a catch-up subscription. In this case, I’d be keeping track of my checkpoints and running through anything that was missed while the subscription was down. I’m already doing this with my read model projections in a single relational database, and, as we already know, the nice part about event sourcing is that I can completely blow away my read model store and feel confident that I can rebuild it all. If I were to keep track of my notification checkpoints in the same read model store, how could I still retain the benefit of being able to wipe out my read model store and yet guarantee only-once delivery of my email notifications? Is the read model store the wrong place to be keeping track of my already successfully sent notifications? Do I need to implement some sort of state machine (saga) to coordinate the sending of notifications? Perhaps I am completely over-thinking (wrongly-thinking) the whole concept. Any suggestions or comments will be greatly appreciated.