An interesting conundrum. Here’s what I want to do:
I have a Pyramid (python 2.7.2) website running on Heroku which pushes notifications to my iPhone app users. Each day, every user needs a push notification sent to them at a randomly generated time between 10:00am and 10:00pm (it obviously needs to know the users timezone as well).
My current plan is the following: Use a persistent worker process to trigger a function every 1 minute on the minute. Each minute, it will call a function (on a different thread so as not to interrupt the timer) which will do 2 things:
-
Check if it’s 11:00pm for each timezone (which will happen 24 times a day, once for each timezone). If true, it will call a function which loops through every user in that respective timezone and generates their random time for the next day, then stores it in the Mongo database.
-
On each minute, the worker will also loop through the users and check if they have their notification due at that time. If it’s due, then send the notification.
My question is: Is there a better way of doing this that doesn’t require generating a huge list of random datetimes every day beforehand?
There are certainly other ways. Whether they’re better is a different matter. For instance: suppose there are n minutes left before the end of a given user’s day and they haven’t had their notification yet. Then send them a notification now with probability 1/n. This way, you don’t need the huge list of random datetimes, but every minute you still need to iterate over all your users, see whether they’ve been notified yet, and compute random numbers for them all. It’s a little more computation in total (though I doubt the difference is significant) and means that all your database updates are small.
Or: Each time you notify a user, then you generate their next update time. That way, the next-update times get computed incrementally but are still known in advance.
(If your number of users is relatively small, so that on most minutes there isn’t a notification, you can make the scheduling smarter — but I won’t say more about that, because if you have that few users then the amount of work your software needs to do is going to be negligible anyway and there’s no point optimizing for that case.)