System Design Basics

// Key principles:
// 1. Identify bottleneck: CPU-bound? I/O-bound? Memory-bound?
// 2. Scale reads: caching, read replicas, CDN
// 3. Scale writes: sharding, message queues, async processing
// 4. Scale storage: partitioning, object storage, tiered storage

// Quick estimation:
// 1 million users × 10 requests/day = ~100 requests/second
// 1 KB per request = ~100 KB/s = ~8.6 GB/day
// Plan for 10x peak: ~1000 requests/second

// Architecture:
// Client → Load Balancer → Server 1
//                        → Server 2
//                        → Server 3

// Layer 4 (TCP): fast, routes by IP/port
// Layer 7 (HTTP): smarter, can route by URL/headers/cookies

// Health checks: LB periodically pings servers
// If server fails health check → removed from rotation
// When it recovers → added back

// Cache-aside pattern (most common):
// 1. App receives request
// 2. Check cache (Redis/Memcached)
// 3. Cache HIT → return cached data
// 4. Cache MISS → query database → store in cache → return

// Eviction policies:
// LRU: remove least recently used (most common)
// LFU: remove least frequently used
// TTL: expire after fixed time

// Cache invalidation strategies:
// 1. TTL-based: set expiry, eventually consistent
// 2. Event-based: invalidate on write
// 3. Version-based: cache key includes version number

// Hash-based sharding:
// shard_id = hash(user_id) % num_shards
// User 12345 → hash(12345) % 4 → shard 2

// Example with 4 shards:
// Shard 0: users where hash(id) % 4 = 0
// Shard 1: users where hash(id) % 4 = 1
// Shard 2: users where hash(id) % 4 = 2
// Shard 3: users where hash(id) % 4 = 3

// Consistent hashing: minimizes data movement when adding/removing shards
// Instead of hash % N, map keys and shards to a ring

// CP systems (consistency over availability):
// - Bank transactions: must be consistent
// - Examples: HBase, MongoDB (with majority write concern)
// - During partition: some requests may fail

// AP systems (availability over consistency):
// - Social media feeds: slightly stale data is OK
// - Examples: Cassandra, DynamoDB
// - During partition: may serve stale data

// Real-world: most systems mix both
// Critical data (payments) → strong consistency
// Non-critical data (user profile pic) → eventual consistency

// REST:
// GET /users/123        → full user object
// GET /users/123/posts  → all posts
// Problem: 2 requests, might get unused fields

// GraphQL:
// POST /graphql
// query {
//   user(id: 123) {
//     name
//     posts(limit: 5) {
//       title
//     }
//   }
// }
// → exactly the fields requested, single request

// When to use REST:
// - Simple CRUD APIs, caching is important (HTTP caching)
// - Public APIs, broad adoption

// When to use GraphQL:
// - Mobile apps (bandwidth-sensitive)
// - Complex data relationships
// - Multiple client types needing different data shapes

// Without queue:
// User request → Process image → Respond (slow, 5 seconds)

// With queue:
// User request → Enqueue 'process image' → Respond immediately (50ms)
// Background worker → Dequeue → Process image → Update status

// Kafka vs SQS:
// Kafka: ordered, replayable, high throughput, log-based
// SQS: simple, managed, at-least-once delivery, auto-scaling

// Key concepts:
// At-least-once: message may be delivered multiple times
// At-most-once: message may be lost but never duplicated
// Exactly-once: hardest to achieve, often app-level idempotency

// Token bucket pseudocode:
// bucket has 'tokens' (max capacity), refill rate
// On request:
//   refill tokens based on elapsed time
//   if tokens >= 1:
//     tokens -= 1
//     allow request
//   else:
//     reject (429 Too Many Requests)

// Example: 100 requests/minute, burst of 10
// capacity = 10, refill rate = 100/60 ≈ 1.67 tokens/sec

// Where to implement:
// API Gateway level (centralized)
// Application level (per-service)
// Client-side (self-throttling)

// Distributed rate limiting:
// Use Redis INCR + EXPIRE for shared counter across instances