Design notification and project architecture

Quick Overview

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design notification and project architecture states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design notification and project architecture

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

##### Question Design a scalable Notification System that supports real-time and scheduled messages across multiple channels (email, push, SMS). Detail components, data flow, storage, failure handling, and scaling strategy. Then, draw and explain the end-to-end architecture of one of your past projects, covering services, databases, communication patterns, and answer deep domain-specific follow-up questions.

Quick Answer: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design notification and project architecture states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/DoorDash
DoorDash logo
DoorDash
Aug 4, 2025, 10:55 AM
hardSoftware EngineerTechnical ScreenSystem Design
11
0

Design notification and project architecture

System Design: Multi-Channel Notification Platform

Design a scalable Notification System that supports real-time and scheduled messages across multiple channels (email, push, SMS). Assume this is for a high-traffic consumer platform with millions of users and mission-critical notifications.

Assumptions (you may adjust if you state them explicitly):

  • Traffic: up to 50k notifications/second at peak, 1B/day worst case during major events.
  • Channels: email, mobile push, SMS; multiple third-party providers per channel for redundancy.
  • Scheduling: immediate and future delivery (seconds to 30 days ahead), with cancel/reschedule.
  • Global audience with time zones, quiet hours, user preferences, and regulatory constraints.

Deliverables

  1. Components: Enumerate core services and infra.
  2. Data flow: Real-time and scheduled paths end-to-end.
  3. Storage: Schemas/data models for templates, preferences, schedules, logs, idempotency.
  4. Failure handling: Retries, deduplication, provider failover, DLQs, backpressure.
  5. Scaling strategy: Partitioning, autoscaling, rate limiting, multi-region.

Also provide:

  • APIs: send now, schedule, cancel, update preferences, provider callbacks.
  • Observability: metrics, tracing, alerting, and SLOs.
  • Capacity planning example.
  • Security and compliance considerations.

Project Architecture Walkthrough (Past Project)

Pick one substantial system you have built or owned. Draw and explain the end-to-end architecture:

  • Services and their responsibilities.
  • Databases/storage choices and schemas.
  • Communication patterns (sync vs async, queues, streams, webhooks), data consistency strategy (e.g., outbox/Saga).
  • Scaling, availability, and failure modes.
  • Tradeoffs and lessons learned.

Be prepared for deep, domain-specific follow-ups (e.g., exact-once semantics, time-zone correctness, multi-tenant throttling, provider outage strategy, replay/backfill, GDPR deletion).

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...