Large-Scale Architecture

Preview — 3 of 10 questions

You are designing a URL shortener (like bit.ly). What is the biggest scalability challenge and how do you address it?

javascript

[Client] → GET /abc123 → [API servers]
                               │
                        ┌──────▼──────┐
                        │  Redis Cache │  ← 99% of requests served here
                        │  TTL: 1hr   │     (< 1ms)
                        └──────┬──────┘
                               │ MISS only
                        ┌──────▼──────┐
                        │  PostgreSQL  │  ← ~1% of requests
                        └─────────────┘

AStoring long URLs is the challenge — use GZIP compression on the database.

BThe challenge is authentication — require OAuth for every redirect.

CGenerating unique short codes is the challenge — use a UUID for every URL.

DThe redirect endpoint is read-heavy (billions of reads vs thousands of writes) — optimize with an in-memory cache in front of the database.

You need to design a system that sends notifications (email, push, SMS) to 100M users. What architecture best handles this at scale?

javascript

[Event: "new challenge posted"]
         ↓
  [Notification Service]
         ↓ fan-out
  ┌──────┬───────┬──────┐
  ▼      ▼       ▼      ▼
Email  Push    SMS    In-App
Queue  Queue   Queue  Queue
  ↓      ↓       ↓      ↓
Email  Push    SMS    DB
Worker Worker Worker Insert
(Resend)(FCM) (Twilio)

AA fan-out architecture with a message queue, per-channel workers, and retry logic for failed deliveries.

BA synchronous API that calls Resend, Firebase, and Twilio in sequence for each user.

CA cron job that runs every minute and sends all pending notifications.

DStoring notifications in a SQL table and having clients poll every 5 seconds.

When and why would you shard a database? What are the trade-offs?

javascript

Without sharding (one DB, 1TB users table, 100K writes/s):
  → Single node becomes a bottleneck

With sharding (4 shards):
  Shard 0: users where id % 4 = 0  (250GB, 25K writes/s)
  Shard 1: users where id % 4 = 1  (250GB, 25K writes/s)
  Shard 2: users where id % 4 = 2  (250GB, 25K writes/s)
  Shard 3: users where id % 4 = 3  (250GB, 25K writes/s)

ASharding is used to encrypt data across multiple servers for security compliance.

BSharding is only needed when you have more than 10 tables in a database.

CSharding horizontally partitions data across multiple database instances to handle data volumes or write throughput that exceeds a single server's capacity.

DSharding automatically replicates data to multiple nodes for read scaling.

Answer all 10 questions (7 more), see explanations for every answer, and track your score.