[0-5 min]   Gather requirements and define scope
[5-10 min]  Capacity estimation (Back-of-envelope calculation)
[10-20 min] High-level design (architecture diagram)
[20-35 min] Detailed design of key components
[35-43 min] Discuss trade-offs and improvements
[43-45 min] Handle interviewer questions

Vertical:   [Server 4GB RAM] → [Server 32GB RAM]
Horizontal: [Server] + [Server] + [Server] → placed behind Load Balancer

User → [Nearest CDN Edge] → (Cache Hit) → Return content
                          → (Cache Miss) → [Origin Server] → Cache in CDN → Return content

1. App queries cache for data
2. Cache miss → query DB
3. Store DB result in cache
4. Subsequent requests hit cache

1. App writes to cache
2. Cache synchronously writes to DB
→ Guarantees data consistency, incurs write latency

1. App writes only to cache
2. Cache asynchronously writes to DB
→ Excellent write performance, risk of data loss on cache failure

In practice, network Partition (P) is unavoidable, so:
  CP systems: Banking, stock trading (consistency first)
  AP systems: Social feeds, shopping carts (availability first)

Ring structure (0 to 2^32 - 1):

        0
       /|\
      / | \
Server A  Server B
    \   |   /
     Server C

Keys are assigned to the nearest server clockwise
When a server is removed, only its keys move to the next server

Producer → [Message Queue] → Consumer

Benefits:
- Asynchronous processing reduces response time
- Traffic buffering (absorbs traffic spikes)
- Reduced coupling between services

Write QPS:
  - New URLs per day: 100M / 100 = 1M per day
  - Write QPS: 1,000,000 / 86,400 ≈ 12 QPS

Read QPS:
  - Read = Write × 100 = 1,200 QPS
  - Peak: 1,200 × 5 = 6,000 QPS

Storage:
  - 1 URL record ≈ 500 bytes
  - 10-year data: 1M × 365 × 10 × 500 bytes ≈ 1.8 TB

Cache:
  - 80/20 rule: top 20% URLs generate 80% of traffic
  - Cache size: 1,200 QPS × 86,400 × 0.2 × 500 bytes ≈ 10 GB/day

POST /api/v1/urls
  Request:  { "long_url": "https://example.com/...", "expire_date": "2027-01-01" }
  Response: { "short_url": "https://tinyurl.com/abc123" }

GET /{short_code}
  Response: 301 Redirect (permanent) or 302 Redirect (temporary)
  → 301: Browser caches redirect, reduces server load (no analytics)
  → 302: Always goes through server (enables click analytics)

Character set: [0-9, a-z, A-Z] = 62 characters
6-char Base62 = 62^6 = 56.8 billion combinations

long_url → MD5/SHA-256 → extract first 7 bytes → Base62 encode → short code

Example:
  "https://www.example.com/long-path"
  → MD5: "1a2b3c4d..."
  → integer of first 7 bytes → Base62 → "aB3xY9z"

CREATE TABLE url_mappings (
  id          BIGINT PRIMARY KEY,        -- Snowflake ID
  short_code  VARCHAR(8) UNIQUE NOT NULL,
  long_url    TEXT NOT NULL,
  user_id     BIGINT,
  created_at  TIMESTAMP DEFAULT NOW(),
  expire_at   TIMESTAMP,
  click_count BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON url_mappings(short_code);

[Client]
    |
    v
[DNS] → [CDN] (static assets)
    |
    v
[Load Balancer]
    |
    +-----------+-----------+
    v           v           v
[API Server] [API Server] [API Server]
    |               |
    v               v
[Redis Cache]  [URL DB (Master)]
(short URL cache)   |
                [URL DB (Replica)]
                (read-only)

Write flow:
  Client → LB → API Server → Save to DB → Update Redis cache → Return short URL

Read flow:
  Client → LB → API Server → Check Redis cache
    → Cache hit: immediate redirect
    → Cache miss: query DB → store in Redis → redirect

On tweet creation:
  1. Save tweet to DB
  2. Retrieve all follower IDs
  3. Insert tweet ID into each follower's timeline cache (Redis)

Pros: Reads are very fast (direct lookup from Redis)
Cons: 100M followers = 100M writes → high write latency

On timeline fetch:
  1. Retrieve list of followed accounts
  2. Fetch latest tweets from each account
  3. Merge and sort by time

Pros: Simple writes
Cons: Read queries scale with follow count → high read latency

Regular users (followers < 10,000):  Fan-out on write
Celebrity users (followers >= 10,000): Fan-out on read

Timeline generation:
  1. Retrieve tweet IDs from Redis for followed regular users (fan-out on write results)
  2. Fetch latest tweets from followed celebrities (fan-out on read)
  3. Merge and sort both result sets

Key:   timeline:{user_id}
Value: Sorted Set (score = tweet timestamp, member = tweet_id)

Example:
  ZADD timeline:123 1700000001 tweet:456
  ZADD timeline:123 1700000002 tweet:789
  ZREVRANGE timeline:123 0 19  # Get latest 20 tweets

Keep a max of 1,000 tweet IDs per user (memory management)

64-bit layout:
  [1 bit: sign] [41 bits: timestamp] [10 bits: machine ID] [12 bits: sequence]

Benefits:
  - Time-sortable (timestamp embedded)
  - No collisions in distributed environments
  - Generates 4,096 IDs/sec × number of machines

[Mobile/Web Clients]
         |
    [API Gateway]
         |
   +-----------+
   |           |
[Tweet Service] [Timeline Service]
   |                |
[Tweet DB]   [Redis Timeline Cache]
(Cassandra)          |
                [Fan-out Service]
                (Consumes Kafka,
                 updates follower timelines)
                     |
              [Follower Graph DB]
              (stores follow relationships)

Media handling:
[Image/Video Upload] → [Object Storage (S3)] → [CDN]

[User]
   |
   v
[Upload Service] → Store raw in S3
   |
   v
[Message Queue (Kafka)]
   |
   v
[Transcoding Workers] (parallel processing)
   ├── 360p encode
   ├── 720p encode
   ├── 1080p encode
   └── 4K encode
   |
   v
[Distribute to CDN]
   |
   v
[Update Metadata DB] → Notify user of completion

Automatically switches quality based on user network conditions:

[Good network]    → Request 1080p/4K segments
[Moderate network] → Request 720p segments
[Poor network]    → Request 360p segments

HLS (HTTP Live Streaming):
  - Video split into 2-10 second segments (.ts files)
  - M3U8 playlist file manages segment list
  - Client monitors buffer state and selects quality for next segment

[Origin Server] → [Regional CDN] → [Edge CDN] → [User]

Popular videos: Pre-cached on multiple edge nodes (Push CDN)
Less popular:   Fetched from Origin on first request (Pull CDN)

Netflix approach: Partners with ISPs to place cache servers inside ISP networks
                  (OCA: Open Connect Appliance)

Upload path:
[Creator] → [Upload API] → [S3] → [Kafka] → [Transcoding Cluster]
                                                  |
                                             [CDN Distribution]

Viewing path:
[User] → [API Gateway] → [Video Service]
                               |
                 +-------------+-------------+
                 |             |             |
            [Metadata]    [CDN Stream]  [Recommendation]
            (MySQL)       (HLS/DASH)   (ML Model)

Client ←→ WebSocket connection ←→ Chat Server
  (persistent bidirectional communication)

Cassandra schema:
  Partition Key: channel_id
  Clustering Key: message_id (Snowflake, time-ordered)

  CREATE TABLE messages (
    channel_id  UUID,
    message_id  BIGINT,      -- Snowflake ID (time-embedded)
    sender_id   UUID,
    content     TEXT,
    created_at  TIMESTAMP,
    PRIMARY KEY (channel_id, message_id)
  ) WITH CLUSTERING ORDER BY (message_id DESC);

→ Very efficient for fetching latest messages per channel
→ Easy horizontal scaling

Message states: SENT → DELIVERED → READ

1. Message sent → save to DB with state SENT
2. Reaches recipient device → update to DELIVERED → notify sender
3. Recipient views message → update to READ → notify sender

Method 1: Heartbeat (ping server every 30 seconds)
  - Store user:{id}:last_seen = timestamp in Redis
  - TTL of 60 seconds → offline if no ping for 60+ seconds

Method 2: WebSocket connection tracking
  - Connect = online event, disconnect = offline event
  - Propagate status changes to friends via Pub/Sub

Small groups (N < 100):
  [Sender] → [Chat Server] → [Direct WebSocket delivery to each member]

Large groups (N >= 100):
  [Sender] → [Chat Server] → [Kafka Topic: group:{id}]
                                    |
                              [Consumer Cluster]
                                    |
                         [Push notification to each member device]

WhatsApp's Signal Protocol-based approach:
  1. Each device generates a public/private key pair
  2. Only the public key is registered with the server
  3. Sender encrypts message with recipient's public key
  4. Server relays encrypted message (cannot decrypt content)
  5. Recipient decrypts with their private key

Read scaling:    Master-Slave replication + read-only Replicas
Write scaling:   Sharding (Consistent Hashing)
Caching:         Redis (in-memory) → reduces DB load
Search:          Elasticsearch → full-text search
Time-series:     InfluxDB / TimescaleDB
Graph data:      Neo4j / Amazon Neptune

Task queue:       Async processing of heavy tasks (transcoding, email)
Event streaming:  Kafka → propagate events between services
CQRS:             Separate read/write models for performance
Saga pattern:     Handle distributed transactions