Designing respectful notifications in a social platform.

Source: Dev.to

Problem

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.

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.

Solution

The idea is 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.
• Inactivity therefore acts as a natural brake.

Implementation

Technically, this is implemented using Redis as a persistent cache layer.

# Pseudocode for suppression key
SET notification:suppression:{user_id}:{type} 1 EX 

• 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 the current setup, the default window is seven days, but this can be adjusted without changing the core logic.

Trade‑offs

• A user who cares but checks the platform infrequently might miss intermediate updates.
• The design assumes 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.

Conclusion

Designing notifications this way shifts the focus from maximizing engagement to minimizing unnecessary interruption. It is a small technical change, but it significantly changes the tone of the product.

The broader goal is to make notifications feel respectful: if someone is inactive, the platform should not keep tapping them on the shoulder.

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.