🏗️ System Design Blueprint: Design a Distributed Notification System (06. Design-Notification-System)

• Focus Area: Pub/Sub Message Queue (Kafka), Worker Fleet
• Primary Blueprint: 06.Design-Notification-System.md
• Practice Scratchpad: practice_scratchpad.md

1. 🎯 Requirements & System Scope

Functional Requirements

1. System should support core operation for Design a Distributed Notification System.
2. High reliability and accurate state updates.

Non-Functional Requirements

• Availability: $99.99%$uptime($4$ nines).
• Latency: Low latency SLA ($<50\text{ ms}$ read response).
• Scalability: Horizontal scalability to support millions of daily active users (DAU).
• Durability: Zero data loss for persistent state.

2. 📊 Capacity Estimation & Back-of-the-Envelope Calculations

QPS & Storage Estimations

• DAU: $10,\text{000},\text{000}$Users($10\text{ Million DAU}$).
• Average QPS: $\text{Average QPS}=\frac{10,\text{000},\text{000}\times 10\text{ req/day}}{86,\text{400}\text{ seconds}}\approx 1,\text{157}\text{ QPS}$
• Peak QPS: $2 \times \text{Average QPS} \approx 2,\text{300} \text{ QPS}$.
• 5-Year Storage Capacity: $\text{Storage/Day}=10,\text{000},\text{000}\times 500\text{ Bytes}=5\text{ GB/day}$ $\text{5-Year Storage}=5\text{ GB}\times 365\times 5\approx 9.125\text{ TB}$

3. 🔌 API Interface Specifications (RESTful API)

Endpoint: Main Action

POST /api/v1/system-endpoint
Content-Type: application/json
 
{
  "request_id": "req-1001",
  "user_id": "usr-8842",
  "data_payload": { ... }
}

Response (200 OK):

{
  "status": "success",
  "system_id": "sys-9921",
  "created_at": 1700000000
}

4. 🗄️ Data Model & DB Schema

Table: Core Entity (CoreEntity)

5. 🌐 High-Level Architecture

flowchart TD
    Client["📱 Client (Mobile / Web)"] --> CDN["⚡ CDN Edge"]
    Client --> LB["⚖️ Load Balancer (Nginx / ALB)"]
    LB --> Gateway["🚪 API Gateway / Auth Server"]
    Gateway --> AppServer["⚙️ Application Server Fleet"]
    AppServer --> Cache["🔥 Distributed Cache (Redis Cluster)"]
    AppServer --> Queue["📩 Message Queue (Kafka)"]
    Queue --> Worker["👷 Async Worker Fleet"]
    Worker --> DB[("🗄️ Database Shards (PostgreSQL / DynamoDB)")]
    AppServer --> DB

6. 🔍 Component Deep Dives

Core Architectural Mechanics

Detailed breakdown of Pub/Sub Message Queue (Kafka), Worker Fleet:

1. Handling Concurrency: Lock-free atomic increments or optimistic concurrency control (OCC).
2. Caching Strategy: Cache-Aside pattern with Redis Cluster to serve hot read queries.

7. 🛡️ Resilience, Scaling & Bottleneck Mitigations