Design a service that accepts notification requests and delivers them across channels to external providers, decoupling acceptance from delivery and respecting per-provider rate limits.
Design a notification dispatch service. Other systems submit "send this notification to this user" requests; the dispatcher delivers them via external channels (push, SMS, email) by calling third-party provider APIs. The core tension is that acceptance and delivery must be decoupled: the submitting system needs a fast acknowledgment, but actual delivery is slow, failure-prone, and rate-limited by the downstream providers, who will reject or throttle traffic that exceeds their limits.
Requests are therefore accepted quickly and enqueued; worker consumers drain the queue and call providers asynchronously, retrying failures and : critically : throttling their outbound call rate to stay within each provider's limits. A burst of submissions must not translate into a burst of provider calls that get the account throttled or banned. The read/query path (checking a notification's status) is secondary.
Design the architecture emphasizing accept-then-enqueue decoupling and outbound rate limiting toward providers. Then document the API, the trade-offs (delivery guarantees, retry/dedup, ordering), and how the system is monitored for delivery health.