sydepsystem design atlas

Push Notification Service

Fan out events to mobile/web push, batched and rate-aware.

IntermediateSocialPlatform
App EventsMessagingNotification DispatcherComputeUser PreferencesStorageDelivery QueueMessagingPush ProviderMessagingDelivery LogObservability

Application events land on a queue; a dispatcher batches them per user preference and rate limit, then delivers through the appropriate platform push provider, tracking delivery/read status for retries and analytics.

When to use it

  • Many services need to notify users without each one integrating platform push APIs directly
  • Notification volume needs central rate limiting and user-preference enforcement

Trade-offs

  • Adds a dependency all notification-worthy events must funnel through
  • Delivery is best-effort; platform push providers can silently drop or delay messages

Components used

Event BusManaged App ServiceKey-Value StoreMessage QueueNotification ServiceAudit Log

How it works

  • Device tokens are registered per user per device and must be kept current, since tokens rotate and expire.
  • Sending is fanned out through a queue to platform gateways, because delivery to external providers is slow and failure-prone relative to the triggering action.
  • Failed sends return token feedback, and invalid tokens must be pruned or the failure rate compounds.

Used in the wild

  • Mobile app engagement and transactional alerts.
  • Web push for browser notifications.
  • Multi-channel notification systems combining push, email and SMS.

Good to know

  • Notifications are the fastest route to an uninstall. Per-category preferences and quiet hours are retention features, not settings-page filler.
  • Delivery is best-effort — the platform gateways make no strong guarantees — so push must never be the only way a user learns something important.