Whenever a new event is added, a push notification is sent to the user. If ten events are added in row, ten push notifications will be sent to the user, a behavior that will be annoying.
I'd like to have it like this: if ten events are added in row, or added very near to each other regarding time, only one push notification will be sent to each user, saying: "#{event.name} and 19 others events added that match your interests.".
Here's what I've done so far:
Added a field last_sent_notification in users table. Each time a new event is added, it is checked that the created event isn't in the 2 minutes radius of last_sent_notification, and a notification is fired.
If a new created event is in the 2 minutes radius of last_sent_notification, a background job is created, that will wait for 2 minutes for any other upcoming event, and will fire after 2 minutes. If a new event is created while the 2-minute-wait, the notification will take into account all the events created during that 2-minute-wait.
The only disadvantage to this problem is: as an event is added, the notification won't be sent right away. There will be a delay of 2 minutes.
Is there any design pattern or optimum solution that could better do this job?
It would be a lot simpler for you to use Collapsible messages, which is designed just for this sort of scenario.
A collapsible message is a message that may be replaced by a new message containing the same collapse key if it has yet to be delivered to the device.
All you need to do is to set the collapse_key parameter.
If this is not what you really want, what you are looking for is a queue and send mechanism. This sort of thing can be done with redis quite easily. Your current server side app merely pushes GCM notifications on the redis queue. If there is already a message for the given user it is replaced.
Then you need to have another thread that constantly monitors the redis queue and sends messages that are older than n minutes.