Most social platforms treat notifications as engagement drivers. The more you return, the better it is for the system. Notifications become a lever to pull people back in, often regardless of whether they have shown recent activity.
Questioning that assumption while building a small social platform. If a user has not interacted with the app in days or weeks, does it really make sense to keep sending notifications? At some point, reminders stop being helpful and start feeling like spam.
The idea I settled on was simple: notifications should respond to user activity, not just system events.
Instead of sending a notification for every qualifying action, the system allows only one notification per user activity window. If the user has already received a notification but has not returned to the platform, additional notifications are suppressed. In other words, inactivity acts as a natural brake.
Technically, this is implemented using Redis as a persistent cache layer. When a notification is sent, a suppression key is written with a configurable expiration time. As long as that key exists, further notifications of that type are not delivered. If the user returns and interacts with the platform, the key can be cleared or reset. If they remain inactive, the suppression window eventually expires on its own.
The expiration time is configurable per notification type. Some events are more time-sensitive than others, and the system allows different reset periods. In my current setup, the default window is seven days, but this can be adjusted without changing the core logic.
This approach does introduce tradeoffs. A user who cares but checks the platform infrequently might miss intermediate updates. However, the design assumption is that meaningful engagement should restart when the user actively returns. Notifications are not meant to accumulate in the background; they are meant to signal something new once the user has shown interest again.
The broader goal is to make notifications feel respectful. Instead of optimizing for frequency or return rate, the system optimizes for restraint. If someone is inactive, the platform should not keep tapping them on the shoulder.
Designing notifications this way shifts the focus slightly. It moves away from maximizing engagement and toward minimizing unnecessary interruption. It is a small change technically, but it significantly changes the tone of the product.
I am still refining the definition of “inactive” and exploring edge cases where suppression might hide something important. But the core principle remains the same: activity should trigger notifications, not the absence of it.
Top comments (0)