Design a global notification service

Quick Overview

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

Design a global notification service

Company: TikTok

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a globally distributed notification service that sends real-time and scheduled messages (email, SMS, push) to tens of millions of users under regional compliance constraints. Define APIs and data models; describe deduplication, idempotency, and rate limiting; choose storage and queueing layers; outline worker orchestration, retry/backoff, and ordering guarantees; design multi-region failover and disaster recovery; and provide capacity planning with rough estimates and monitoring/alerting.

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

|Home/System Design/TikTok
TikTok logo
TikTok
Jul 17, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
10
0

Design a global notification service

System Design: Globally Distributed Notification Service

Context

You are designing a multi-tenant notification platform that delivers real-time and scheduled messages (email, SMS, push) to tens of millions of users worldwide. The system must comply with regional data residency and privacy regulations, support high availability across multiple regions, and provide strong operational controls (idempotency, deduplication, rate limiting, retries, monitoring).

Assume:

  • Users and data are partitioned by region (e.g., US, EU, APAC) with strict residency for PII.
  • The platform offers APIs to trigger individual and bulk notifications and manage templates and user preferences.
  • Peak traffic can spike rapidly (e.g., incident alerts, promotions).

Requirements

Design a system that addresses the following:

  1. APIs and Data Models
  • Define REST APIs for:
    • Sending real-time and scheduled notifications (single and bulk)
    • Managing templates and variables
    • Managing user preferences and subscriptions
    • Retrieving message status and delivery receipts
  • Specify core data models (Message, DeliveryAttempt, Template, Campaign/Job, UserPreference, IdempotencyRecord, RateLimitBucket).
  1. Deduplication, Idempotency, and Rate Limiting
  • Describe how to prevent duplicate sends across retries and concurrent requests.
  • Provide idempotency strategy at API and worker levels.
  • Define rate limiting scopes (per-user, per-tenant, per-channel, per-provider) and algorithms.
  1. Storage and Queueing Layers
  • Choose storage for:
    • Control-plane metadata (tenants, templates, campaigns)
    • Regional data-plane (messages, attempts, user preferences)
    • Caching (idempotency keys, rate limiter state)
    • Object/blob storage (large templates, assets)
  • Choose queueing/streaming for fan-out, ordering, retries, scheduled delivery, and DLQs.
  1. Worker Orchestration, Retry/Backoff, Ordering
  • Describe worker topology and autoscaling.
  • Define retry/backoff policies and DLQ handling by failure type.
  • Specify ordering guarantees (e.g., per-user per-channel) and how partitions/keys enforce it.
  1. Multi-Region Architecture, Failover, and Disaster Recovery
  • Active-active by region with data residency.
  • Control-plane and data-plane split; inter-region replication where lawful.
  • Provider redundancy and failover strategy.
  • RTO/RPO targets and DR workflows.
  1. Capacity Planning (Rough Estimates)
  • QPS, throughput, partitions, worker counts, storage footprint, cache sizing.
  • Include formulas and a worked example for tens of millions of users.
  1. Monitoring and Alerting
  • SLOs/SLIs, key metrics, logs/traces, synthetic checks.
  • Alerting policies and on-call runbooks.

State key assumptions, call out trade-offs, and justify major design choices.

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...