Notification Service
A notification service separates subscription policy, delivery selection, and provider translation. A successful local dispatch is not proof that a real human read a message.
What you’ll understand
- A notification service separates subscription policy, delivery selection, and provider translation. A successful local dispatch is not proof that a real human read a message.
- The service selects a channel strategy per active subscription and normalizes the legacy SMS provider response through an adapter.
- Evaluate the tradeoff: This synchronous model has no retry queue or delivery guarantee. A production service needs deduplication keys, bounded retries, durable subscription state, and a documented definition of delivery.
Useful first: Classes and Objects
The idea and when to recognize it
A notification service separates subscription policy, delivery selection, and provider translation. A successful local dispatch is not proof that a real human read a message.
- Requirement: A publisher sends one event to subscribers using email or SMS. Some users opt out and some providers fail.
- Change to anticipate: Honor current opt-outs, report unsupported channels, and keep one failed delivery from suppressing independent subscribers.
- Design goal: The service selects a channel strategy per active subscription and normalizes the legacy SMS provider response through an adapter.
Start with the concrete problem
A publisher sends one event to subscribers using email or SMS. Some users opt out and some providers fail.
Honor current opt-outs, report unsupported channels, and keep one failed delivery from suppressing independent subscribers.
| Direct implementation | Revised design |
|---|---|
| Treating every subscriber as active and every provider response as success creates misleading delivery results. | The service selects a channel strategy per active subscription and normalizes the legacy SMS provider response through an adapter. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | This synchronous model has no retry queue or delivery guarantee. A production service needs deduplication keys, bounded retries, durable subscription state, and a documented definition of delivery. |
Scope and extension questions
This is a deterministic single-process model. Persistence, authentication, real network calls, and distributed coordination are outside this exercise.
- Which public operation must be atomic if two callers act at once?
- What data must be saved to recover after a restart?
- How would you change one policy without rewriting the core state transitions?
Responsibilities and contracts
The service selects a channel strategy per active subscription and normalizes the legacy SMS provider response through an adapter.
- NotificationService: Applies subscription and dispatch policy. Public operations: publish(subscribers)
- EmailChannel: Implements direct delivery. Public operations: send(message)
- SmsAdapter: Normalizes the vendor response. Public operations: send(message)
- LegacySms: Returns vendor-specific status. Public operations: transmit(message)
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A monitoring system can share the same subscription and channel boundaries while adding incident grouping and escalation rules.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
This synchronous model has no retry queue or delivery guarantee. A production service needs deduplication keys, bounded retries, durable subscription state, and a documented definition of delivery.
Common mistake: Treating every subscriber as active and every provider response as success creates misleading delivery results.
- Explain the choice: The service selects a channel strategy per active subscription and normalizes the legacy SMS provider response through an adapter.
- Challenge your choice: This synchronous model has no retry queue or delivery guarantee. A production service needs deduplication keys, bounded retries, durable subscription state, and a documented definition of delivery.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…