Some kinds of applications may create a lot of push notifications in a small amount of time.
Sometimes you just want to notify every single message, but other times might be better to reduce the number of notifications or avoid to send the same notification too many times in a short period of time.
For example, think to a crowded chat where each push notification plays a sound: maybe when a user is not connected you can just notify "You have unread messages" once, without the need to notify every single message. Moreover when the user is active on the chat you can just drop push notifications. Throttle the number of notifications may improve the UX and reduce the server cost.
Throttling can be implemented in many ways. For example you can add a seen_at and last_notification_sent_at to users. Then you send a push notification only if the user is not connected and seen_at > last_notification_sent_at. In this way a user will only receive one notification like "You have unread messages" and won't receive other messages until it opens to the application again. Hybrid solutions can also be considered: for example you may want to notify new messages again after 10 minutes if the user doesn't open the application.
You can also use Redis to create in-memory locks that limit the notification rate: when the lock is present new notifications are dropped; when the lock is not present you acquire the lock and you send the notification. Finally the lock expires when its TTL is passed or when something happens. Here's an example with Redis (it's Ruby code, but you can easily adapt it to any language):
# this Redis lock prevents the notification from being sent again
# if it was already sent in the last 10 minutes
if redis.set 'notification', 'sent', nx: true, ex: 10.minutes.to_i
# send the notification...
end