This has worked well for me before, on a small scale https://github.com/robfig/cron
this post was submitted on 23 Jun 2025
1 points (100.0% liked)
Golang
2674 readers
1 users here now
This is a community dedicated to the go programming language.
Useful Links:
Rules:
- Posts must be relevant to Go
- No NSFW content
- No hate speech, bigotry, etc
- Try to keep discussions on topic
- No spam of tools/companies/advertisements
- It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
founded 2 years ago
MODERATORS
correct me if I'm wrong, but it seems like this wouldn't scale well
In what way? You haven't provided any information about scaling requirements
I would have to store the users' cron jobs in a database, and then run some kind of loop on startup to start the cron jobs.
That is accurate, though it doesn't say anything about scaling requirements
Oops, missed that part. Ideally, this would be able to handle thousands of users
Note that while it is simple, you have to handle schedule persistence yourself, unlike the 2 you linked since they are backed by pg or redis
Are your users technical? If not, crontab syntax is definitely to be avoided. Instead, I'd offer some simple options like daily, weekly, monthly, etc. Then convert that syntax into crontab syntax.
I glanced at the repo, but there is no content in the README.md to get a sense of what your project is actually doing.
For processing cron, you should consider just using cron. You can setup a user specific to the process, use that user's crontab, and manage the entries. If the source of truth will be from the database, then you don't even need to read the crontab itself, only (over)write it on demand.
I was thinking I could offer the option to use cron, if not they can just select an option from a dropdown.
regarding my nonexistent readme, this is basically a digital dead man switch. The user sets an interval to send emails with a link to them , and if they don't click on the link for a few months, they get marked as dead and messages they specified beforehand get sent out to groups of users.
I'd carefully consider using email for this. If you're hosting the service, you might need to use one of the bigger email providers that already have reputation (unless you already have good IPs with good rep). Otherwise, you risk the emails sitting in spam and people's switches being flipped. If it is self-hosted, you'll probably need to explain the risks to users.
Given today's world of pocket computers, you might consider using push notifications of some kind. Or have a companion client that pokes an API and there is some kind of challenge/response.
Yeah, I'll use one of the major email providers, I am aware of the risks of self-hosting email. And yes, I will implement some kind of push notification system, either through the browser or via a mobile app.
Okay cool, just making sure you covered all your bases 🖖
Depending of how complicated you want it to be of course.
I would implement it by using the basic goroutines, a wait group to keep track of the goroutines and sleep for the recurring duration.
Maybe a more optimal solution would be to use a workerpool.
Also what amount of emails are we talking about and what kind of recurring duration(1/hour or 1/year)