Designing Popular Real-World Systems

# CHAPTER 18

Designing Popular Real-World Systems #

1. Introduction #

2. Learning Objectives #

• Synthesize core components to architect massive, real-world systems.

• Design a heavy media streaming architecture (YouTube/Netflix).

• Architect a read-heavy, high-availability social feed (Instagram).

• Design a persistent, low-latency messaging system (WhatsApp).

• Understand the geolocation and matchmaking requirements of ride-sharing (Uber).

3. Case Study 1: Design YouTube / Netflix (Heavy Media & Streaming) #

• The Upload Pipeline:

• Client uploads raw video using a Pre-Signed URL directly to AWS S3 (Object Storage) to avoid crashing the API servers.

• S3 triggers an event to a Message Queue (Kafka).

• Worker Servers pull from the queue, slice the video into small chunks, transcode them into multiple resolutions (1080p, 4K), and save them back to S3.

• The Delivery (Read):

• The metadata (Title, Views, Author) is stored in a heavily replicated SQL database and cached in Redis.

• The massive video chunks are globally distributed to edge servers via a Content Delivery Network (CDN). When a user hits play, the video streams from a server located just a few miles away.

4. Case Study 2: Design Instagram / Twitter (The News Feed) #

• The Data Store: User relationships (Followers) are stored in a Graph Database or Relational DB. The actual posts (text/image URLs) are stored in a NoSQL database (like Cassandra) for massive horizontal scale.

• The Feed Generation (Fanout Architecture):

• *Fanout-on-Write (Push):* When a user with 500 followers posts a photo, a background worker instantly calculates the new feed for those 500 followers and pushes the Post ID into their individual "Feed Caches" in Redis. When those 500 users log in, their feed loads instantly from RAM (O(1) time).

• *The Celebrity Exception:* If Justin Bieber (100M followers) posts a photo, pushing it to 100 million Redis caches instantly will crash the system. For massive celebrities, we use *Fanout-on-Read (Pull)*. The system merges the celebrity's posts into the user's feed only at the exact moment the user logs in.

5. Case Study 3: Design WhatsApp / Discord (Real-Time Messaging) #

• The Connection: Users do not use HTTP polling. They establish a persistent WebSocket connection to a "Chat Server."

• The Architecture:

• We have 1,000 Chat Servers. User A connects to Server 1. User B connects to Server 500.

• A "Presence Service" (backed by Redis) tracks exactly which server each user is connected to.

• User A sends a message. Server 1 queries the Presence Service, finds that User B is on Server 500, and routes the message internally via a Pub/Sub Broker to Server 500, which pushes it down the WebSocket to User B.

• The Database: Messages are temporarily stored in a highly optimized, write-heavy NoSQL database (like Cassandra) until they are delivered and backed up.

6. Case Study 4: Design Uber (Geolocation & Matchmaking) #

• The Driver Tracking: Drivers' apps send their current GPS coordinates every 4 seconds via WebSockets.

• The Storage (QuadTrees): Standard SQL databases cannot query "Find all drivers within 2 miles of me" efficiently. We use specialized Geospatial databases (like Redis GeoHash or a QuadTree data structure) that map the physical world into grid sectors, allowing instant spatial lookups.

• The Matchmaking: A centralized Dispatch Service looks at the user's location grid, queries the geospatial database for nearby drivers, and executes a complex algorithm evaluating ETA and traffic before pushing the ride offer to a specific driver.

7. Diagrams/Visual Suggestions #

[ Normal User Posts ] --> [ Web Server ] --> [ MQ ] --> [ Fanout Worker ]
                                                             |
                                           (Pushes to Follower Caches in Redis)
                                                             |
                                                             v
[ Follower 1 Feed Cache ]   [ Follower 2 Feed Cache ]   [ Follower 3 Feed Cache ]

8. Best Practices #

• Trade-offs in Interviews: In a real system design interview, there is no single "perfect" architecture. The interviewer wants to hear you debate the trade-offs. (e.g., "I am choosing to pre-compute the feeds and store them in Redis. This will cost millions of dollars in RAM, but it is the only way to achieve sub-100ms load times for the users.")

9. Common Mistakes #

• The "Relational Database for Everything" Mistake: If asked to design Uber, and you propose storing the drivers' rapidly changing GPS coordinates in a strict PostgreSQL database, you have failed. The extreme volume of location updates (millions of writes per second) will cause massive locking and crash the SQL DB. You MUST use memory-based or highly optimized key-value stores for ephemeral, high-velocity data.

10. Mini Project: Map the System Design Interview Flow #

1. 1. Clarify Requirements: Never start drawing immediately. Ask: "How many daily active users? Is the system read-heavy or write-heavy? Are we optimizing for latency or data accuracy?"

1. 2. Back-of-the-Envelope Estimation: Calculate the required storage and bandwidth. (e.g., "1M users * 2MB photos = 2TB of new storage a day").

1. 3. High-Level Design: Draw the basic boxes: Client -> Load Balancer -> API Gateway -> Web Servers -> Database -> S3.

1. 4. Deep Dive & Bottlenecks: Identify the breaking points. "The database will melt from the read traffic, so I will inject a Redis cache and implement Master-Slave replication."

11. Practice Exercises #

1. 1. Explain the "Fanout-on-Write" architecture used by social media companies (like Twitter/Instagram) to generate news feeds. Why is this model incredibly fast for normal users, but disastrous if applied to celebrities with millions of followers?

1. 2. Compare the architectural requirements of a streaming app (Netflix) versus a real-time chat app (WhatsApp). Which system relies heavily on CDNs, and which relies heavily on persistent WebSockets?

12. MCQs with Answers #

13. Interview Questions #

• Q: You are asked to design Twitter. Explain your database architecture choice. Would you use a single Relational database, or a combination of SQL, NoSQL, and Graph databases? Defend your choices based on specific features (User profiles vs. The massive Tweet stream vs. Follower relationships).

• Q: Walk me through the architecture of a WhatsApp-style group chat. When one user sends a message to a group of 50 people, how do the chat servers efficiently route that single message to 50 different WebSockets spread across multiple different physical servers?

• Q: In a system design interview, what is the purpose of conducting "Back-of-the-Envelope" estimations before drawing the architecture? How does calculating the expected Read-to-Write ratio fundamentally change your design?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #