Common System Design Problems

# CHAPTER 16

Common System Design Problems #

1. Chapter Introduction #

You have learned the individual puzzle pieces: Load Balancers, Redis, NoSQL, Kafka, and WebSockets. In an interview, your job is to assemble these pieces into a working architecture under pressure. This chapter provides high-level architectural blueprints for the three most common System Design interview questions: The URL Shortener, The Chat Application, and The Social Media Feed.

2. Design Problem 1: The URL Shortener (e.g., bit.ly) #

Requirements: Take a long URL, return a short URL. When users click the short URL, redirect them. Must be highly available. Estimation: 100M URLs generated per month. Read-heavy (100 Reads for every 1 Write).

The Architecture:

1. 1. API Gateway: Handles Rate Limiting (preventing a single user from generating 1M links a second).

1. 2. Web Tier: Stateless Node.js servers.

1. 3. The Hash Generator (The Core Logic):

• How do we generate a unique 7-character string? We can use Base62 encoding (A-Z, a-z, 0-9).

• We use a central Database Sequence (auto-increment ID) or a dedicated service (e.g., Twitter Snowflake) to generate a unique numeric ID.

• We convert the ID (e.g., 10000) into a Base62 string (e.g., Ab3).

1. 4. Data Storage: A Relational DB (PostgreSQL) is fine, but a Key-Value Store (DynamoDB) is better because we only ever query by the short hash.

1. 5. Caching (Crucial): 90% of clicks hit the same 10% of viral links. Place a Redis Cache in front of the DB.

1. 6. Redirection: When the GET request hits the Web Server, it queries Redis, gets the Long URL, and returns an HTTP 301 Permanent Redirect to the client.

3. Design Problem 2: The Chat Application (e.g., WhatsApp) #

Requirements: 1-on-1 real-time chat, group chat, message history, online presence. Estimation: 500M Daily Active Users. High throughput, ultra-low latency required.

The Architecture:

1. 1. Connection Tier: Clients connect to WebSocket Servers via a Load Balancer configured for long-lived connections.

1. 2. State Management: When User A connects to WebSocket Server 1, we save their location in a Redis SessionCache (UserA -> Server_1).

1. 3. Message Routing (Pub/Sub):

• User A sends a message to User B.

• Server 1 queries Redis: "Where is User B?"

• Redis says "User B is on Server 2."

• Server 1 publishes the message to a Redis Pub/Sub channel that Server 2 is listening to.

• Server 2 pushes the message down User B's open WebSocket.

1. 4. Data Storage: Chat history is massive and unstructured. Use a Wide-Column Store (Cassandra) or a Key-Value store (HBase) optimized for rapid time-series ingestion.

1. 5. Presence Service: A separate microservice that receives "Heartbeats" (pings) from clients every 5 seconds to update their Online/Offline status in Redis.

4. Design Problem 3: The Social Media Feed (e.g., Twitter/Instagram) #

Requirements: Users can post text/images. Users can view a chronological timeline of posts from people they follow. Estimation: 300M Users. Extremely Read-heavy.

The Architecture (The Fan-out Problem): The hardest part of designing Twitter is generating the timeline. *Approach 1: Fan-out on Read (Pull Model)*

• When I open my app, the server queries the DB: "Find all users I follow. Fetch their last 20 posts. Sort by time."

• *Flaw:* Devastatingly slow. Too many JOINs.

*Approach 2: Fan-out on Write (Push Model - The Correct Answer)*

• We pre-compute the timeline.

• When User A posts a tweet, a background Kafka worker looks up all of User A's followers.

• The worker *pushes* the new tweet into the individual Redis Timeline Caches of every single follower.

• When a follower opens their app, the server simply fetches their pre-computed timeline from Redis in 1 millisecond. O(1) time complexity.

*The Celebrity Edge Case:* If Justin Bieber tweets, pushing that tweet into 100M Redis caches will crash the system. For celebrities, we use a hybrid approach: we *pull* their tweets on read and merge them with the pre-computed Redis timeline in memory.

5. HR Perspective: The "Perfect" Answer Myth #

Interviewers do not expect you to build a flawless system. They want to see you struggle with the tradeoffs. When designing the Social Media Feed, if you explicitly identify the "Celebrity Edge Case" on your own without being prompted, you immediately jump from Mid-Level to Senior in the interviewer's mind.

6. Mini Project: Design the Instagram Feed #

Combine your knowledge:

1. 1. Define the APIs: POST /api/v1/posts (Upload image), GET /api/v1/feed (View timeline).

1. 2. Database: PostgreSQL for User Data, MongoDB for Post Metadata, AWS S3 for actual Image files.

1. 3. Caching: Redis for pre-computed user feeds.

1. 4. CDN: CloudFront to cache the heavy S3 images globally.

7. Common Mistakes #

• Ignoring Scale: Designing a system that works for 100 users but fails for 1 million. Always start your interview with the "Back-of-the-Envelope Estimation" step to define the scale.

• Forgetting the CDN: If the prompt involves photos or videos (Instagram, Netflix, YouTube), you MUST draw a CDN on the whiteboard.

8. Best Practices #

• Asynchronous Workers: Any heavy lifting (like generating video thumbnails or pre-computing feeds) should be moved off the main HTTP thread and processed asynchronously using a Message Queue (SQS/Kafka).

9. Exercises #

1. 1. In the URL Shortener design, why is a Key-Value store (DynamoDB) better than a Relational database (MySQL)?

1. 2. In the Chat App design, explain how Redis Pub/Sub solves the problem of users being connected to different WebSocket servers.

10. MCQs #

11. Interview Questions #

• Q: "Design a global Ride-Sharing app (like Uber). How do you handle the real-time tracking of 100,000 drivers broadcasting their GPS coordinates every 3 seconds?" (Hint: Think about WebSockets, Geo-spatial databases, and heavy write throughput).

12. FAQs #

• Q: Should I memorize these architectures?

A: Memorize the *patterns* (e.g., "Heavy Reads = Cache", "Heavy Writes = Cassandra", "Bi-directional = WebSockets"), not the exact blueprints. Interviewers will twist the requirements to ensure you aren't just reciting a script.

13. Summary #

Mastering system design requires applying distributed system patterns to real-world problems. For a URL Shortener, prioritize Base62 encoding, Key-Value stores, and heavy caching. For a Chat App, prioritize WebSockets, Redis Pub/Sub routing, and Wide-Column storage. For Social Media, prioritize the "Fan-out on Write" model using Kafka and Redis to pre-compute timelines, while handling the Celebrity Edge Case gracefully.

14. Next Chapter Recommendation #

We have designed the systems; now let's see how the tech giants actually did it. In Chapter 17: FAANG-Level System Design Case Studies, we will analyze the real-world architectures of YouTube, Netflix, and Uber.