System Design Interview
Multi-channel notifications platform that ingests events and delivers messages via email, SMS, push, and in-app with retries, preferences, and observability.
Single service handles ingest, templating, and provider calls backed by one database.
What was missing: Edge protection, async buffering, isolation, and observability.
Why that's risky: SPOF and blocked sends under spikes.
What gets added: Nothing yet (MVP).
Trade-offs: Fast to ship but not production-ready.
Add ingress protection and throttling before compute.
What was missing: Ingress governance and fairness.
Why that's risky: Overload cascades to downstream services.
What gets added: Edge gateway and rate limiter.
Trade-offs: More moving parts.
Distribute ingest across replicas and cache hot templates/preferences.
What was missing: Redundancy and hot-path caching.
Why that's risky: Bottlenecks and slow reads.
What gets added: LB and cache.
Trade-offs: Cache invalidation complexity.
Introduce orchestrator, templates, preferences, and queue-driven workers for providers.
What was missing: Domain separation and async delivery.
Why that's risky: Synchronous provider calls increase tail latency and blast radius.
What gets added: Ingest/orchestrator, template and preference services, queue + workers.
Trade-offs: More services and operational overhead.
Harden correctness with idempotency keys, add scheduled sends, and introduce bulk-segmentation plus DLQ handling.
What was missing: Idempotency, scheduled sends, bulk recipient segmentation, and safe failure handling.
Why that's risky: Duplicate sends, slow bulk targeting, and lost jobs under failure would make campaigns unreliable and hard to operate.
What gets added: Idempotent ingest, scheduler, bulk notification UI, segmentation/query engine, search-backed cohort lookup, and DLQ replay flow.
Trade-offs: More moving parts for replay tooling, campaign safety, and index freshness during large audience updates.
Add a central notification handler, recipient enrichment, delivery tracking, monitoring, and multi-provider routing.
What was missing: Deep visibility, central preference-aware routing, recipient enrichment, and a dedicated tracking path for delivery outcomes.
Why that's risky: Silent failures, weak tracking, and vendor lock-in would degrade reliability and make operational diagnosis much harder.
What gets added: Notification handler, user profile enrichment, delivery tracker store, monitoring/tracing, and multi-provider email/SMS/push/IVRS failover strategy.
Trade-offs: More components, more state synchronization, and more operational overhead managing provider adapters and tracking stores.
Require a client- or server-generated dedupe key. Store keys with outcome in the DB. On retries, return the recorded result. Workers use idempotency keys when calling providers to avoid duplicates.
Store preferences in a relational DB keyed by user and topic. Cache hot rows. At ingest, check preferences and quiet hours to select channels or schedule for later.
Use exponential backoff with jitter and a capped retry policy per channel. Route permanent failures to DLQ for inspection/replay with safeguards that re-check idempotency before sending again.
Abstract providers behind adapters. Track per-provider health and success rates; route using primary/secondary with circuit breakers. Fall back when SLA or error thresholds breach; restore automatically as health improves.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
