FAANG-Level System Design Case Studies

# CHAPTER 17

FAANG-Level System Design Case Studies #

1. Chapter Introduction #

There is theoretical system design, and then there is how things actually work in production at Google, Netflix, and Uber. FAANG companies regularly publish engineering blogs detailing how they survive internet-breaking traffic. By studying their actual architectures, you elevate your interview answers from textbook definitions to battle-tested strategies. This chapter dissects three massive real-world case studies: Streaming at Netflix, Ride Dispatch at Uber, and Global Scale at YouTube.

2. Case Study 1: Designing Netflix (Video Streaming) #

The Challenge: Serving massive 4K video files globally while maintaining an ultra-fast, personalized UI browsing experience. Netflix accounts for ~15% of the world's total internet bandwidth.

The Architecture: Netflix fundamentally splits its architecture into two distinct systems:

1. 1. The Control Plane (AWS): This handles everything *except* the video file. User Authentication, Billing, Search, and the UI metadata (thumbnails, descriptions) are hosted on AWS using a Microservices architecture. They use Cassandra for massive, highly available data storage across multiple regions.

1. 2. The Data Plane (Open Connect CDN): Netflix built its own custom global CDN called Open Connect. They place massive physical hard drives (appliances) directly inside the buildings of local Internet Service Providers (like Comcast or AT&T).

*The Workflow:*

• Your TV connects to AWS (Control Plane) to browse movies.

• You click "Play."

• AWS determines your location and sends your TV the IP address of the Open Connect appliance physically located closest to your house.

• Your TV streams the heavy 4K video file directly from the local ISP node (Data Plane), bypassing the global internet entirely.

3. Case Study 2: Designing Uber (Real-Time Dispatch) #

The Challenge: Matching millions of moving riders and drivers in real-time. Extremely high Write-throughput (drivers updating GPS every 3 seconds).

The Architecture:

1. 1. Real-Time Connections: Both Driver and Rider apps maintain a persistent WebSocket connection to the server for instant communication.

1. 2. The Location Backend: 100,000 drivers pinging their GPS every 3 seconds would destroy a SQL database. Uber uses Redis and massive in-memory data grids to store the *current* location of drivers.

1. 3. Geo-Spatial Indexing (Quadtrees/Geohashes): How do you quickly find 5 drivers near a rider? You cannot scan the whole database. You divide the map into a grid (using Geohashes). The database groups drivers by their current Grid ID. The system only searches the Rider's immediate grid and the 8 surrounding grids.

1. 4. The Dispatcher (Kafka): When a Rider requests a ride, the request is placed into Kafka. A matching engine consumes the request, calculates ETAs, finds the best driver, and pushes a WebSocket notification to the driver.

4. Case Study 3: Designing YouTube (Video Processing Pipeline) #

The Challenge: Users upload 500 hours of video every minute. The system must transcode this raw video into dozens of different resolutions and formats (1080p, 720p, iOS format, Android format) instantly.

The Architecture (Event-Driven):

1. 1. Upload & Storage: The user uploads a massive raw video file directly to cloud object storage (AWS S3 or Google Cloud Storage).

1. 2. The Pipeline (Message Queues): The Web Server does *not* process the video. It drops an event ({"task": "transcode", "video_id": 456}) into a highly durable message queue (Kafka / RabbitMQ).

1. 3. Distributed Worker Nodes: An auto-scaling group of hundreds of powerful CPU-optimized worker servers pull tasks from the queue.

• Worker 1 transcodes the video to 1080p.

• Worker 2 simultaneously transcodes the video to 720p.

1. 4. CDN Distribution: The workers save the processed chunks back to Object Storage, which replicates the files globally across a CDN.

1. 5. Metadata: The metadata (Title, Likes, Comments) is stored in a heavily sharded Relational Database (MySQL) fronted by a massive Memcached layer.

5. Common Threads in FAANG Architectures #

Notice the recurring themes across all three companies:

• Separation of Concerns: Keep heavy data (video) entirely separate from lightweight data (UI metadata).

• Asynchronous Processing: Use Kafka/Queues to move heavy lifting to background workers.

• Microservices: Breaking monolithic databases into Polyglot Persistence (using MySQL, Cassandra, and Redis simultaneously).

• The CDN: The internet is physically too slow to serve heavy assets globally from a single data center. Edge caching is mandatory.

6. Mini Project: Apply the Lessons #

Take the "Quadtree/Geohash" concept from the Uber case study. How would you use that exact same spatial indexing concept to design Yelp (finding restaurants near a user)? *Answer:* Store restaurants in a database grouped by Geohash. When a user opens Yelp, the app sends their GPS coordinates. The server calculates their Geohash and queries the database *only* for restaurants in that specific Geohash and the immediate neighbors, returning results in milliseconds.

7. Common Mistakes in Interviews #

• Forgetting the "Write" Path: Candidates love to explain how a user streams a video on YouTube (the Read path). They completely forget to architect the complex, asynchronous queue system required to upload and process the video (the Write path).

• Database Monogamy: Assuming FAANG companies use one database for everything. State explicitly: "We will use Cassandra for high-write telemetry, Redis for location caching, and PostgreSQL for financial billing."

8. Best Practices #

• Read Engineering Blogs: The best way to prepare for FAANG interviews is to read the engineering blogs of Netflix, Uber, Discord, and Meta. They literally give you the answers to the test.

9. Exercises #

1. 1. In the Netflix architecture, why do they use AWS for the UI but a custom CDN for the video files?

1. 2. In the Uber architecture, why is a WebSocket used instead of standard HTTP REST for the driver's app?

10. MCQs #

11. Interview Questions #

• Q: "Design a scalable Web Crawler (like Googlebot) that downloads and indexes millions of web pages. How do you ensure the crawler doesn't download the exact same page twice?"

12. FAQs #

• Q: Do I have to design systems exactly like Netflix does in an interview?

A: No. Netflix's architecture solves Netflix's specific problems. Interviewers want you to apply the *principles* (Caching, CDNs, Asynchronous Queues), not just memorize their exact stack.

13. Summary #

FAANG architectures rely on the extreme separation of concerns. Netflix separates lightweight UI microservices (AWS) from heavy video delivery (Custom CDNs). Uber utilizes WebSockets for real-time tracking and geo-spatial indexing to match riders efficiently. YouTube relies on massive, asynchronous Message Queues to distribute heavy video transcoding tasks to parallel worker nodes. Understanding these real-world blueprints provides the ultimate foundation for your interview.

14. Next Chapter Recommendation #

You have all the knowledge. Now you must perform. In Chapter 18: Mock System Design Interviews, we will break down the exact 45-minute timeline of the interview, how to draw on the whiteboard, and how to communicate effectively with the hiring manager.