Giao diện
🏆 SYSTEM DESIGN CASE STUDIES
Phase 4: Real-World Applications
🎓 Giáo sư Tom
"Lý thuyết mà không thực hành thì chỉ là lý thuyết suông. Trong Phase này, chúng ta sẽ áp dụng toàn bộ kiến thức từ Phase 1-2-3 để thiết kế lại các siêu ứng dụng mà hàng tỷ người dùng mỗi ngày."
📚 Overview
Module này trả lời câu hỏi: "Làm thế nào để xây dựng X từ con số 0 đến 100 triệu người dùng?"
Mỗi case study được thiết kế theo cấu trúc chuẩn:
| Section | Mô tả |
|---|---|
| 📊 Back-of-Envelope | Tính toán QPS, Storage, Bandwidth |
| 🏗️ High-Level Architecture | Sơ đồ kiến trúc tổng thể |
| 🔄 Core Flows | Sequence diagrams cho các luồng chính |
| 💡 Deep Dive | Phân tích sâu vấn đề cốt lõi |
| ⚖️ Trade-offs | Ma trận đánh đổi các quyết định |
| 💰 Cost Estimation | Ước tính chi phí hạ tầng cloud |
🗂️ Case Studies
🐦 Design Twitter
Timeline & Fan-out Patterns at Scale
- Scale: 300M DAU, 600M tweets/day
- Core Problem: Fan-out on Write vs Fan-out on Read
- Key Insight: Hybrid approach cho Celebrity Problem
📺 Design YouTube
Video Streaming & CDN Architecture
- Scale: 2B DAU, 500 hours video uploaded/minute
- Core Problem: Video transcoding pipeline & CDN distribution
- Key Insight: Adaptive Bitrate Streaming (HLS/DASH)
🚗 Design Uber
Real-time Location & Matching Engine
- Scale: 100M MAU, 15M trips/day
- Core Problem: Geospatial indexing & driver matching
- Key Insight: S2 Geometry cells cho location queries
💬 Design WhatsApp
Real-time Messaging & End-to-End Encryption
- Scale: 2B MAU, 100B messages/day
- Core Problem: Persistent connections & message delivery
- Key Insight: Signal Protocol cho E2EE
🎯 Challenge Exercise: Design TicketMaster
🔥 Final Boss Challenge
Thiết kế hệ thống bán vé concert có thể xử lý 1 triệu người mua đồng thời trong 1 phút khi Taylor Swift mở bán vé.
Problem Statement
Bạn được giao nhiệm vụ thiết kế hệ thống bán vé cho các sự kiện lớn (concert, thể thao, festival). Hệ thống phải:
- Handle flash sales: 1M concurrent users trong 60 giây
- Prevent overselling: Không bán quá số vé có sẵn
- Fair queuing: Người đến trước được phục vụ trước
- Bot prevention: Chặn scalpers và bots
📊 Back-of-Envelope Targets
Hãy tự tính toán và so sánh với các con số dưới đây:
💡 Hint: Expected Calculations
| Metric | Target |
|---|---|
| Peak QPS | ~17,000 (1M users / 60s) |
| Inventory updates/sec | ~5,000 (assuming 30% conversion) |
| Database writes/sec | ~10,000 (tickets + orders) |
| Queue throughput | 1M enqueue trong 60s |
🧩 Key Components to Design
🎓 Giáo sư Tom's Hints
Hãy suy nghĩ về các vấn đề sau trước khi xem solution:
1. Inventory Management
- Làm sao để đảm bảo không oversell khi có 1M requests đồng thời?
- Optimistic locking vs Pessimistic locking?
- Redis atomic operations?
2. Virtual Queue System
- Làm sao để fair queuing cho 1M users?
- Queue position tracking?
- Estimated wait time calculation?
3. Payment Processing
- Làm sao để hold inventory trong khi user thanh toán?
- Timeout và release mechanism?
- Idempotency cho payment retries?
4. Anti-Bot Measures
- CAPTCHA timing và placement?
- Device fingerprinting?
- Rate limiting strategies?
🏗️ Architecture Hints
┌─────────────────────────────────────────────────────────────────┐
│ TICKETMASTER ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [Users] → [CDN/WAF] → [Queue Service] → [Booking Service] │
│ ↓ ↓ │
│ [Redis Queue] [Inventory Service] │
│ ↓ │
│ [Payment Service] │
│ ↓ │
│ [Order Database] │
│ │
└─────────────────────────────────────────────────────────────────┘✅ Success Criteria
Thiết kế của bạn nên đáp ứng:
- [ ] Handle 1M concurrent users
- [ ] Zero overselling
- [ ] P99 latency < 5 seconds cho queue entry
- [ ] Fair queue ordering
- [ ] Bot detection rate > 95%
- [ ] Payment success rate > 99%
🔧 Raizo's Note
"Trong thực tế, TicketMaster đã fail nhiều lần với Taylor Swift sales. Đây là bài toán cực kỳ khó - đừng nản nếu thiết kế đầu tiên của bạn có lỗ hổng. Quan trọng là học từ mỗi iteration."