System Design · HLD Interview Questions

Answer: Design a global high-throughput URL shortening service supporting 100M new URLs/month and 10B clicks/month with sub-10ms redirection latency.

• Solution Link: https://algomaster.io/learn/system-design-interviews/design-url-shortener
• Key Design Decisions:
  1. Base62 Encoding: Convert a unique 64-bit auto-incrementing ID or Snowflake ID into a 7-character Base62 string ([a-zA-Z0-9]), supporting $62^7 \approx 3.52 \text{ Trillion}$ unique URLs.
  2. Key Generation Service (KGS): Pre-generate random 7-character keys and store them in an active key table to eliminate collision checking at write time.
  3. HTTP 301 vs. 302: Use 302 Found (or 307 Temporary Redirect) to ensure every click passes through backend servers for accurate geographic and referrer analytics tracking.
  4. Caching Layer: Cache the top $20%$ of hot URLs in Redis with LRU eviction to serve $80%$ of redirect requests directly from in-memory cache.

Answer: Design a real-time social broadcasting platform handling 500 million daily tweets, user follow graphs, and instant timeline rendering.

• Solution Walkthrough (Video): https://www.youtube.com/watch?v=wYk0xPP_P_8
• Solution Guide (Text): https://www.geeksforgeeks.org/interview-experiences/design-twitter-a-system-design-interview-question/
• Key Design Decisions:
  1. Hybrid Fanout Engine: Use Fanout-on-Write for regular users (pushing tweet IDs to followers' Redis timeline lists) and Fanout-on-Read for celebrity accounts with millions of followers (merging celebrity tweets dynamically at query time).
  2. Snowflake ID Generation: 64-bit integer IDs generated with 41-bit timestamp, 10-bit machine/datacenter ID, and 12-bit sequence number to guarantee chronological sorting without centralized database locks.

Answer: Design a photo and video sharing platform supporting media uploads, social follow graphs, news feed generation, and high-speed image delivery.

• Solution Link: https://algomaster.io/learn/system-design-interviews/design-instagram
• Key Design Decisions:
  1. Object Storage & CDN: Images and videos are stored in Amazon S3 / Google Cloud Storage and distributed globally across Cloudflare / CloudFront CDN edge caches.
  2. Metadata Sharding: Shard user metadata, posts, and like counters across PostgreSQL clusters using user_id as the shard key.
  3. Feed Ranking: Asynchronous feed generation workers pre-compute ranking feeds combining chronological post streams with ML engagement scoring models.

Answer: Design a real-time 1-on-1 and group messaging platform supporting billions of messages daily, read receipts, typing indicators, and media attachments.

• Solution Link: https://www.geeksforgeeks.org/system-design/desiging-facebook-messenger-system-design-interview/
• Key Design Decisions:
  1. Persistent WebSockets: Maintain millions of persistent full-duplex WebSocket connections terminated at an edge Gateway fleet.
  2. Message Routing: An in-memory Message Sync Broker maps active user connections to gateway servers.
  3. Storage Architecture: Use distributed wide-column NoSQL databases (Apache Cassandra / HBase) partitioned by conversation_id and sorted by message timestamp for fast pagination.

Answer: Design an ultra-lightweight, end-to-end encrypted messaging service prioritizing zero server storage retention, instant delivery, and offline message buffering.

• Solution Link: https://algomaster.io/learn/system-design-interviews/design-whatsapp
• Key Design Decisions:
  1. Erlang / Elixir Actor Model: High-concurrency lightweight processes running on ejabberd / custom Erlang gateways to handle 2M concurrent connections per physical server.
  2. End-to-End Encryption (Signal Protocol): Public key exchange via server; message payloads are encrypted with Double Ratchet on client devices.
  3. Ephemeral Storage: Server holds messages in memory/queue only until the recipient device acknowledges delivery (ACK), after which messages are deleted permanently from servers.

Answer: Design a distributed file system managing petabytes of data across thousands of commodity storage servers with high sequential read/write throughput.

• Original Research Paper: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
• Key Design Decisions:
  1. Architecture Topology: Single Master / NameNode managing metadata in memory, paired with thousands of ChunkServers / DataNodes storing raw data chunks.
  2. Large Chunk Size (64MB): Reduces metadata overhead and eliminates frequent master communication.
  3. Replication & Durability: Chunks replicated $3\times$ across different racks with background heartbeat rebalancing.

Answer: Design a cloud storage and file synchronization platform supporting desktop/mobile sync, conflict resolution, bandwidth-efficient delta syncing, and offline edits.

• Solution Guide (Text): https://www.geeksforgeeks.org/system-design/design-dropbox-a-system-design-interview-question/
• Deep-Dive Walkthrough (Video): https://www.youtube.com/watch?v=U0xTu6E2CT8
• Key Design Decisions:
  1. Chunking & Content-Addressable Storage (CAS): Split files into 4MB chunks and hash each chunk (SHA-256). Store chunks by their hash in S3 to achieve cross-user deduplication.
  2. Delta Sync: When a 500MB file changes, calculate the binary delta (rsync algorithm) and upload only the modified 4MB chunks rather than re-uploading the entire file.
  3. Sync Engine: Desktop client watches file system changes, maintains a local SQLite database, and pushes metadata events via WebSockets.

Answer: Design a distributed web crawler fetching billions of web pages monthly with strict politeness policies, duplicate detection, and robust error handling.

• Solution Walkthrough (Video): https://www.youtube.com/watch?v=BKZxZwUgL3Y
• Key Design Decisions:
  1. URL Frontier: Priority queues for page importance + Politeness queues partitioned by host domain with rate-limiting delays.
  2. Duplicate URL & Content Detection: Bloom Filter for visited URLs ($0.1%$ false positive rate); 64-bit SimHash algorithm for duplicate HTML content detection.
  3. DNS Caching: Custom in-memory DNS caching fleet to eliminate external DNS lookup latency.

Answer: Design an omni-channel notification platform sending billions of transactional and marketing alerts across iOS (APNS), Android (FCM), SMS (Twilio), and Email (SendGrid).

• Solution Link: https://algomaster.io/learn/system-design-interviews/design-notification-service
• Key Design Decisions:
  1. Priority Queues: Separate Kafka topics for high-priority transactional alerts (OTP / Payment receipts) vs low-priority marketing blasts.
  2. Deduplication & Rate Limiting: Deduplicate notifications within a 5-minute sliding window using Redis keys (SETNX user:notif:template_id) to prevent spamming users on network retries.
  3. Integration Adapters: Decoupled vendor adapter microservices with circuit breakers and fallback providers.

Answer: Design a global distributed rate limiter protecting API backends at scale with sub-millisecond decision latency and atomic synchronization.

• Solution Walkthrough (Video): https://www.youtube.com/watch?v=mhUQe4BKZXs
• Algorithm Deep-Dive: https://blog.algomaster.io/p/rate-limiting-algorithms-explained-with-code
• Key Design Decisions:
  1. Redis + Lua Scripts: Execute token bucket evaluations inside atomic Redis Lua scripts to prevent read-modify-write race conditions.
  2. Sliding Window Counter: Combine current and previous window weights to achieve $O(1)$ memory usage per user while smoothing boundary traffic bursts.
  3. Local Memory + Centralized Sync: Maintain local in-memory token counters at each API Gateway, asynchronously batching sync deltas to Redis every 100ms.