Reliable systems · 3 / 4
Design notification delivery
Your challenge
Send email and in-app notifications when an order ships. The order must commit even if an email provider is unavailable.
Try it first. Write down your assumptions and explain your reasoning.
1.Persist intent with the business change
Write an order update and an outbox event in the same transaction. A worker publishes or processes pending outbox entries. Publishing to a queue before committing the order can create a notification for an order that never committed; publishing only after commit can lose the event if the process crashes.
2.Use stable delivery identities
Create a delivery record keyed by event and channel. Respect user preferences and distinguish transactional notifications from optional marketing. The worker should retry transient failures with backoff and preserve the delivery identity on replay. External email can still be delivered twice unless the provider offers a suitable idempotency mechanism.
3.Design operations and privacy
Track backlog age, failure rate and provider response class. Keep sensitive content out of general logs. Provide a dead-letter review and controlled replay. In-app notification reads need account scope and pagination. Bound retention and avoid making a provider outage block the order API.
Take it one step further
- 1.How do you support two independent channels?
- 2.How would you replay failures after a provider outage?
Self-review
Can you explain each point without looking at the solution?
- Atomic outbox intent
- Account preferences and stable delivery keys
- Observable retries without blocking orders