Send messages to users via FCM once per day based on their shifting time-of-day preferences without dupes, using Redis

Context

I have a bunch of posts, each with upvote and downvote counts stored in my Postgres database. I am running a Gin Golang server, Flutter mobile app, and am using FCM (Firebase Cloud Messaging) to deliver notifications to users.

Architecture problem

First, the problem is solvable quite easily. I'm just unaware of how to solve it efficiently.

I want to send every user the highest voted post roughly once a day. However, I want to send the notification to users based upon when they are most active in the app (not all at once, i.e., not just 12AM daily).

So, let's say I keep track in a table called active_times an entry for each user that has a field I update based on when they interact with the mobile app like time in Postgres. I keep this updated based on user activity.

My intuition says I should have a cron job running in my server every ~2 hours which queries for all users who have their time field within that ~2 hours window. Then, I send the top post notification to these users. Then, I save in my Redis cache a hashset mapping user_ids to time_notification_recieveds, with auto-expiry set to about 12 hours. Where for every subsequent query, I first check if user_id in Redis, don't send to this user, else, do send and add the id to Redis.

This would allow me to have a window where if the user suddenly logs in or interacts a bunch on the app directly after a notification is sent to them (shifting their activity time), they'll at worst receive a notification 12 hours later, but usually since their active-window will not change much, it'll send roughly every 24 hours (daily). For example, this is opposed to their time window being 2pm and then right after I send them a notification it updates to 4pm and they get hit again in 2 hours.

Remarks

Is this an efficient way of doing it? I originally thought of using my Postgres database to store all these IDs, but figured that could really quickly overwhelm the database.

Moreover, is Redis meant for this sort of thing? Is there a completely different approach I could take to doing this?

Thanks!

Until you have many millions of users then just about anything you only do every few hours will be plenty efficient.

I'd have a separate column in the users table (for example) with "next notification time" for scheduling the notifications. I imagine you don't want a scenario where a user is using the system and then immediately after gets a notification, right?

For figuring out when to send the notifications you could have a table with a mini-histogram of activity; something like

• user_id
• hour-of-day
• counter

and then whenever the user does "activity" then increment the counter. Then when calculating "next time to send a notification" you look in this table to find the best hour for this particular user. Over time you could improve the algorithm to be more sophisticated than just a count of activity. (Maybe you want the notification an hour before the user is usually active? Or maybe a time when they sometimes use the app, but not as habitually, etc).