schedule maintained across multiple servers

[avimess23]

Hello all,
I would like to use the gocron scheduler for my project. I need to send out an email every monday at 8:00 am.
My aplication is running on multiple servers and so I am using Redis key distribution in order to make sure I am sending this email only once. However there is something that I am worried about.

Say that its 7:59 and the erver is about to execute the email sending function but crashes and another server is going to take its place.
The new server starts up but now it is already 8:01, does that mean that the email will not be sent until next week?
I was wondering how the scheduler works in that sense. is the schedule already sent with next weeks executaion? or is it something else?
If the jobs are already scheduled is there a way for me to see if this weeks email is still in que, so that I can have it executed even after 8:00 am?
I was thinking what if I could save the schedule on Redis so that if a crash happens my new server could just get the schedule and resume from where the previous server stopped...

I am hoping that my questions are valid and that my poblem is understood. I am new to multi server applications and Im not sure if I undertstand the proccess completly. (I am thinking of it as threads but not sure if that is athe right way to look at it)

Thank you in advance,
Avi

[JohnRoesler]

hey @avimess23

I've built a few systems lately using gocron, but what I try and do is keep the scheduling bit extremely light, as in just the trigger, and then design the rest of the process in a fault tolerant way as gocron isn't designed to be distributed right now and that's a big effort to take on.

As you point out, if the gocron app misses the 8 am schedule, you're out of luck. You could add additional backup checks at 8:01, 8:02 etc. and have another app handle making sure it went out.

So, what I have done is, have my app that runs gocron simply spit out a message to kafka or save it to redis or a database saying, "hey it's time to do a thing". And then another component that either consumes kafka, or regularly checks the DB and takes action and updates back it's status. That way you can handle failures in other ways.