I've started hacking, and now I have a rough storage bit and some of the format. Next is the first rev on the API, and a rough front end to generate reminders. Then a piece to do a simple delivery of the reminder, and a wrapper that does the persistent and type parts -- signal once or until we get a response, and posdibly our escalation -- email, text and maybe phone by voice. Another thing to consider is how granular we want to go -- should we be checking per minute, quarter hour, hourly or even daily? I don't think we could do sub one minute signals, based on our likely channels.
I've thought a bit more, and realize that I need two services to implement this arch. One of them is the "notification" service, which actually delivers the messages/reminders, and another is the "set up reminder" service, which is just a queue that takes reminders and persists them somewhere. Now, there are LOTS of details to work out and things to consider, but dividing responsibility like this makes the thing a bit simpler and also allows me to try out a bit of microservice orientation.
I've built a small proof of concept on the Notification side. Lots of hard coding and assumptions, and I'm sure it'll get crotchity as things go forward. Right now there is a bit of code that speaks http which takes a bit to notify, and turns it into an e-mail message. Still early days -- it needs an actual API and some authentication, and some logging, and a way to run that doesn't depend on me being logged in. Also, the client needs to deal with errors, as opposed to the current client that just echos them. I like this approach though, and I'll try to get the API and micro services set up soon. I'm also wondering if I might want to collect the queue info from the e-mail application, or if it should come direct from the notifier.