دليل مقابلة تصميم النظام 2026: الأطر والأنماط ودراسات الحالة

Example: Design Twitter-like feed

Users: 500M total, 100M daily active (DAU)
Tweets: 100M DAU × 5 tweets/day = 500M tweets/day
Reads: 100M DAU × 100 timeline views/day = 10B reads/day

QPS (writes): 500M / 86400 ≈ 5,800 tweets/sec (peak 3x = 17,000)
QPS (reads): 10B / 86400 ≈ 115,000 reads/sec (peak 3x = 345,000)

Storage (tweets):
- 500M tweets/day × 280 bytes = 140 GB/day
- 5 years = 140 × 365 × 5 ≈ 255 TB of tweet data

Media storage: 10% of tweets have images (100MB avg)
50M tweets/day × 100KB thumbnail = 5 TB/day thumbnail storage

Cache-Aside (Lazy Loading):
  App → cache miss → DB → write to cache → return

Write-Through:
  App → write to cache AND DB simultaneously

Write-Back (Write-Behind):
  App → write to cache → async write to DB (faster, risk data loss)

Read-Through:
  Cache handles DB fetching automatically (used by Redis+Memcached)

Cache Eviction Policies:
  LRU  — Least Recently Used (most common)
  LFU  — Least Frequently Used
  TTL  — Time-To-Live expiry

Vertical Scaling: Bigger machine (CPU, RAM, SSD)
  Pros: Simple, no code changes
  Cons: Limits, single point of failure, expensive

Read Replicas: Primary handles writes, replicas handle reads
  Pros: Read scalability, disaster recovery
  Cons: Replication lag (eventual consistency)

Sharding (Horizontal Partitioning):
  Split data across multiple DBs by key

  Hash-based: shard = hash(user_id) % num_shards
    Pros: Even distribution
    Cons: Hard to add shards (resharding)

  Range-based: shard by date range or ID range
    Pros: Range queries efficient, easy to add new shards
    Cons: Hot spots (most recent shard gets all writes)

  Directory-based: lookup table maps keys to shards
    Pros: Flexible
    Cons: Lookup overhead, single point of failure

Client → Load Balancer → Web Servers → Cache (Redis)
                                          ↓ cache miss
                                       Database (PostgreSQL + replicas)

URL Shortening API:
  POST /api/shorten
  { "url": "https://very-long-url.com/path", "alias": "mylink", "expires_at": "2027-01-01" }
  → { "short_url": "https://bit.ly/abc123" }

Redirect API:
  GET /{short_code}
  → 301/302 redirect to original URL

Key Generation:
  Option 1: Base62 hash of MD5(url) — take first 7 chars
  Option 2: Counter + Base62 encode (guaranteed unique)
  Option 3: Pre-generate keys in KGS (Key Generation Service)

CREATE TABLE urls (
  id           BIGSERIAL PRIMARY KEY,
  short_code   VARCHAR(10) UNIQUE NOT NULL,
  original_url TEXT NOT NULL,
  user_id      BIGINT,
  created_at   TIMESTAMP DEFAULT NOW(),
  expires_at   TIMESTAMP,
  click_count  BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON urls(short_code);
CREATE INDEX idx_user_id ON urls(user_id);

Architecture:

Client ←→ WebSocket Gateway (stateful) ←→ Message Service
                                              ↓
                                    Message Queue (Kafka)
                                              ↓
                                    Message Store (Cassandra)
                                    - Partitioned by conversation_id
                                    - Ordered by timestamp within partition

Message Flow:
1. User A sends message → WebSocket Gateway (Server A)
2. Gateway publishes to Kafka topic
3. Message Service writes to Cassandra
4. User B's WebSocket Gateway subscribes and delivers
5. If User B offline → push notification via FCM/APNs

Schema (Cassandra - wide column):
  messages_by_conversation
    conversation_id (partition key)
    message_id (clustering key, time-ordered)
    sender_id, content, message_type, created_at