Public Solution
Notification System - Multi-Channel Delivery
Notification System - Multi-Channel Delivery solution gives a production-minded baseline for this prompt. You get a concise requirements recap, a component-by-component architecture breakdown, explicit tradeoffs for latency, availability, cost, and complexity, plus failure mitigations and scoring rationale so you can benchmark your own design quickly.
Requirements Recap
| Requirement | Target |
|---|---|
| Daily notifications | ~100,000,000 |
| Channels | 4 (push, email, SMS, in-app) |
| Critical delivery latency | < 5 seconds |
| Normal delivery latency | < 5 minutes |
| Digest window | 15 minutes |
| Delivery tracking | Per-message status |
| Template count | ~500 |
| Availability target | 99.95% |
Architecture Breakdown (Component-by-Component)
1. Web Clients
Generates user traffic and receives responses.
Acts as an entry layer that routes traffic into the rest of the system.
2. Load Balancer
Distributes requests across healthy backend instances.
Bridges 1 incoming flow to 1 downstream dependency.
3. API Gateway
Handles api gateway responsibilities in this design.
Bridges 1 incoming flow to 1 downstream dependency.
4. API Service
Runs core business logic and orchestrates downstream calls.
Bridges 1 incoming flow to 4 downstream dependencies.
5. Message Queue
Buffers asynchronous work to smooth traffic spikes.
Bridges 1 incoming flow to 2 downstream dependencies.
6. Monitoring
Collects service health and operational telemetry.
Acts as a sink or system-of-record endpoint in the architecture flow.
7. Primary NoSQL DB
Stores high-scale data with flexible schema and throughput.
Acts as a sink or system-of-record endpoint in the architecture flow.
8. Background Workers
Processes asynchronous jobs outside the request path.
Acts as a sink or system-of-record endpoint in the architecture flow.
9. Log Aggregator
Centralizes logs for debugging and incident response.
Bridges 1 incoming flow to 1 downstream dependency.
10. Notification Fanout
Handles pub sub responsibilities in this design.
Acts as a sink or system-of-record endpoint in the architecture flow.
Tradeoffs (Latency / Availability / Cost / Complexity)
| Decision | Latency | Availability | Cost | Complexity |
|---|---|---|---|---|
| Keep the request path focused on core business operations | Shorter synchronous path keeps average response time stable | Fewer inline dependencies reduce immediate failure blast radius | Avoids unnecessary infrastructure in the first rollout | Lower coordination overhead for small teams |
| Move bursty and slow work to asynchronous consumers | Smoother request path with deferred background processing | Queue buffering reduces synchronous overload failures | Queue + worker infra adds baseline spend | Idempotency, retries, and DLQ handling are required |
| Keep a clear system of record for transactional writes | Predictable read/write behavior with indexed access | Strong correctness with managed backup and recovery | Storage and IOPS spend grows with write volume | Schema evolution and query tuning required |
Failure Modes and Mitigations
Failure mode: Consumer lag grows until queued work breaches SLO windows
Mitigation: Scale consumers, monitor lag aggressively, and route poison messages to a DLQ.
Failure mode: Primary datastore saturation increases latency and write timeouts
Mitigation: Tune indexes, add read offload where valid, and cap expensive query classes.
Failure mode: Blind spots delay incident detection and increase mean time to recovery
Mitigation: Track golden signals, error budgets, and service-specific runbooks with alerts.
Why This Scores Well
- Availability (35%): A compact request path limits synchronous dependencies that can fail in-line.
- Latency (20%): The design keeps hot reads close to users and reduces expensive origin round-trips.
- Resilience (25%): Asynchronous buffering, observability, and service boundaries isolate faults and improve recovery.
- Cost Efficiency (10%) + Simplicity (10%): Higher complexity is scoped to requirements that actually demand scale or stronger fault tolerance.
Next Step CTA
Validate this architecture by solving the prompt yourself, then practice the highest-leverage component in a guided lab and topic hub.
FAQ
What should I change first if traffic doubles?
Profile the bottleneck first, then scale the hot path component (usually compute, cache, or read path) before adding new system layers.
Why is Message Queues emphasized in this solution?
It is the highest-leverage topic for this challenge constraints and directly improves score-impacting metrics like latency, availability, or resilience.
How do I validate this architecture quickly?
Run the same challenge in the simulator, compare score breakdown metrics, and then test one tradeoff change at a time.
Related Reading
Message Queue Architecture for System Design Interviews
Understand when and how to use message queues in system design: decoupling, backpressure, delivery guarantees, and the operational patterns that matter.
Queue-First API Design for Burst Traffic
Use synchronous API boundaries for intent capture and asynchronous queues for expensive work, retries, and operator visibility.