[SYSTEM DESIGN TẬP 17] CHUNG KẾT WORLD CUP: CÚ SẬP NGUỒN 5 PHÚT TẠI CHÂU ÂU, BÍ MẬT GEO DNS TTL 60S VÀ NGHỊCH LÝ SPLIT 4 THẮNG SPLIT 16 ($96.50 ★★★)! ⚽⚡
Tiếng còi mãn cuộc của Màn 26 vừa dứt, toàn bộ sảnh đấu System Design Arena bỗng tắt phụt đèn.
Trên màn hình mái vòm khổng lồ, một chiếc cúp vàng bóng đá rực sáng giữa hai nửa bán cầu Trái Đất. Dòng chữ đỏ thẫm nhấp nháy chói lòa: TRÙM CUỐI WORLD 2 — MÀN 27 (world_cup_final — CHUNG KẾT WORLD CUP)!
Thằng Đ đứng bật dậy, hai mắt dán chặt vào bảng đề bài:
- *"Anh Kido! Trận chung kết bóng đá hành tinh được tiếp sóng trực tiếp cho khán giả toàn cầu! Nửa ở Mỹ (50%), nửa ở châu Âu (50%), tổng lưu lượng $700\text{ req/s}$. Trong đó $600\text{ req/s}$ là khán giả bấm xem live stream để cộng dồn vào bộ đếm view chung, còn $100\text{ req/s}$ là mở bảng tỷ số để đọc số view trực tiếp!"*
Nó vừa thở phào vì thấy con số $700\text{ req/s}$ không quá khủng khiếp như Màn 13 Flash Sale, thì dòng cảnh báo phía dưới khiến mặt nó tái mét:
⚠️ THẢM HỌA KHẮC NGHIỆT (TWIST EVENT):
Trận đấu dài 600 giây. Đúng phút thứ 3 (giây thứ 180), TOÀN BỘ HẠ TẦNG VÙNG CHÂU ÂU (EU)
BỊ MẤT ĐIỆN VÀ SẬP HOÀN TOÀN TRONG SUỐT 5 PHÚT (300 GIÂY LIÊN TỤC)!
Toàn bộ database chính bắt buộc đặt tại Mỹ (US).
- *"Chết dở! Đang xem chung kết mà mất điện cả lục địa châu Âu 5 phút thì 350 request/giây của fan bóng đá EU đi về đâu?! Chưa kể ngân sách ban tổ chức siết chặt cứng: tối đa
$111.00/thángvà đơn giá mỗi triệu request không được vượt quá$0.06!"* — Đ cuống cuồng vò đầu bứt tai.
1. CÚ LỪA GEO DNS TTL 300S VÀ THẢM CẢNH NÉM PACKET VÀO HỐ ĐEN 🌐🕳️
Thằng Đ lập tức trổ tài phân luồng địa lý. Nó kéo một hộp Geo DNS Tier S ($1.50/tháng) đặt ở cửa ngõ, kéo 1 máy App Server Tier S (EU) ($15.00) phục vụ châu Âu, và 1 máy App Server Tier S (US) ($15.00) phục vụ khán giả Mỹ.
Nó hớn hở:
- "Em để Geo DNS tự động nhận diện IP người dùng. Khán giả EU thì trỏ về máy chủ EU, khán giả US trỏ về máy chủ US, chuẩn bài phân tán đa vùng!"
Đoạn, nó tự tin bấm nút ▷ Chạy.
Từ giây 0 đến giây 179, hệ thống chạy êm ru. Cả hai vùng Mỹ và châu Âu xanh mướt, độ trễ chỉ 45 ms.
Nhưng đúng giây thứ 180, tiếng còi báo động rít lên chói tai. Toàn bộ cụm máy chủ EU trên bản đồ biến thành màu đen kịt!
[ALERT 180s - 480s] EU DATACENTER TOTAL POWER OUTAGE!
[ERROR] Users EU: Connection Refused / Timeout 30,000ms!
[ERROR] SLA Drop: 51.4% (Yêu cầu >= 90%) -> THẤT BẠI!
Thằng Đ nhảy dựng lên:
- "Ủa?! Geo DNS thông minh lắm cơ mà! Cụm EU chết rồi sao nó không tự động đẩy khách EU sang cụm US giùm em?!"
Tôi gõ đầu nó một cái đau điếng:
- *"Mày nhìn vào ô cấu hình Geo DNS của mày xem! TTL mặc định là bao nhiêu?! 300 GIÂY!
Khi client ở EU hỏi DNS lần đầu, nó nhận được IP của cụm EU kèm chỉ thị: 'Hãy cache IP này trong 300 giây'. Đúng giây 180 cụm EU sập, nhưng máy tính của hàng triệu fan hâm mộ EU vẫn ngoan ngoãn gửi request vào cái IP đã chết thêm đúng 300 giây nữa — tức là vừa khít toàn bộ 5 phút mất điện!
Mày vừa bắt nửa hành tinh đứng nhìn màn hình quay tít trong suốt hiệp đấu! Phải đổi ngay
TTL: 60s!"*
flowchart TD
subgraph Trap["❌ Cái bẫy TTL 300s (Client cache IP chết suốt 5 phút)"]
U_EU1["Khách EU (350 req/s)"] -->|"Cache IP cũ 300s"| DEAD["❌ Cụm EU đã chết cháy (Hố đen Timeout!)"]
end
subgraph Fix["✅ Tuyệt chiêu Geo DNS TTL 60s (Failover dưới 1 phút)"]
U_EU2["Khách EU (350 req/s)"] -->|"Hết hạn 60s -> Hỏi lại Geo DNS"| DNS["Geo DNS (TTL 60s)"]
DNS -->|"Failover chuyển hướng sang Mỹ"| US_CLUSTER["🇺🇸 Cụm App Server US (Gánh tải 700 req/s)"]
end
- "Nhưng khi EU sập, toàn bộ 350 req/s của EU sẽ tràn sang Mỹ. Khi đó cụm Mỹ phải gánh trọn vẹn: $350 + 350 = \mathbf{700\text{ req/s}}$!
Mày nhìn lại con máy
App Server Tier S (US)của mày đi: công suất tối đa của nó chỉ là 500 req/s. Nếu mày chỉ để 1 máy ở Mỹ, lúc chuyển vùng nó sẽ bị 700 request đè bẹp dí ngay tức khắc! Tăng ngay Cụm máy chủ US lên 2 máy Tier S ($30.00) để có công suất $1.000\text{ req/s}$, nuốt trọn toàn bộ lưu lượng của cả hai bán cầu!"
2. NGHỊCH LÝ SHARDED COUNTER: VÌ SAO CHỌN SPLIT 16 LÀ TỰ SÁT TẬP THỂ? 🧮💥
Thằng Đ sửa xong DNS và cụm App US, rồi quay sang nhìn khối Cơ sở dữ liệu:
- "Anh Kido! Đề bài có $600\text{ writes/s}$ cộng dồn vào đúng 1 row
view_count. Em nhớ bài học Màn 10: Giới hạn vật lý của PostgreSQL chỉ chịu được tối đa~200 updates/giây trên 1 hàngdo tranh chấp Row-Level Lock. Vậy em chọn ngayCounter: Split 16trên Database để băm nhỏ bộ đếm ra 16 slot cho nó mượt nhé?!"
Nó vừa định bấm chọn split_16 thì tôi chộp lấy cổ tay nó:
- "Dừng lại ngay! Nếu mày chọn
Split 16, mày sẽ giết chết con Database chỉ trong vòng nửa nốt nhạc!"
Đ tròn xoe mắt, không hiểu tại sao:
- "Ủa? Băm càng nhỏ thì ghi càng nhanh chứ anh?! $600 / 16 = 37.5\text{ writes/giây/slot}$, nhỏ hơn 200 rất nhiều mà?!"
Tôi lôi tập giấy nháp ra vẽ một bảng so sánh toán học:
- *"Mày chỉ nhìn một nửa bài toán là GHI (
Write), mà quên mất nửa còn lại là ĐỌC (Read)! Mỗi giây có $100\text{ lượt đọc}$ xem tổng số view trận đấu. Khi bộ đếm bị chia làm $N$ slot, để trả về con số tổng, Database bắt buộc phải thực hiện truy vấn: $$\text{SELECT SUM(count) FROM view_counter}$$ Tức là hệ thống phải quét và cộng dồn toàn bộ $N$ slot lại với nhau! Mỗi request đọc sẽ nhân tải lên gấp $N$ lần bên trong engine!"*
Tôi viết công thức tổng tải dội lên Database: $$R_{db} = W_{write} + (R_{read} \times N)$$
Hãy nhìn vào hai ngã rẽ định mệnh:
Nếu chọn
Counter: Split 16($N = 16$):- Tải đọc bị phóng đại: $100 \times 16 = \mathbf{1.600\text{ ops/s}}$!
- Cộng thêm tải ghi: $600\text{ writes/s}$.
- Tổng tải đập vào Database: $1.600 + 600 = \mathbf{2.200\text{ req/s}}$!
- Trong khi con
Relational DB Tier L($50.00) công suất tối đa chỉ chịu được $1.500\text{ req/s}$! - 💥 Kết quả: Database quá tải 146%, nổ tung ngay lập tức! Muốn sống sót mày phải cắn răng mua con
DB Tier XLgiá$200.00/tháng— vượt thủng trần ngân sách $111.00 và rớt đài ngay!
Nếu chọn
Counter: Split 4($N = 4$):- Tải ghi mỗi slot: $\frac{600}{4} = \mathbf{150\text{ writes/s/slot}} < 200\text{ updates/s}$ ➔ Triệt tiêu hoàn toàn Row Lock!
- Tải đọc dội lên DB: $100 \times 4 = \mathbf{400\text{ ops/s}}$.
- Tổng tải đập vào Database: $600 + 400 = \mathbf{1.000\text{ req/s}} \ll 1.500\text{ req/s}$!
- ✅ Kết quả: Nằm gọn gàng, êm ái trong lòng con
Relational DB Tier Ltrị giá chỉ$50.00/tháng!
| Tiêu chí so sánh | Chọn Split 16 (Cái bẫy phóng đại đọc) |
Chọn Split 4 (Điểm cân bằng vàng) |
|---|---|---|
| Tải ghi trên mỗi slot | $37.5\text{ writes/s}$ (Rất nhẹ) | $150\text{ writes/s}$ (An toàn $< 200$) |
| Hệ số phóng đại đọc ($100\text{ reads/s}$) | $\times 16 \rightarrow \mathbf{1.600\text{ ops/s}}$ | $\times 4 \rightarrow \mathbf{400\text{ ops/s}}$ |
| Tổng tải lên Database | $600 + 1.600 = \mathbf{2.200\text{ req/s}}$ | $600 + 400 = \mathbf{1.000\text{ req/s}}$ |
| Tier DB bắt buộc để sống | Tier XL ($200.00/tháng) ➔ Cháy túi! |
Tier L ($50.00/tháng) ➔ Vừa vặn! |
| Kết quả chung cuộc | ❌ Vỡ nợ $246.50 (Sập tiệm) | 🏆 3 Sao rực rỡ ($96.50 Best Cost) |
Thằng Đ rùng mình toát mồ hôi hột:
- "Hóa ra băm sharding không phải cứ càng nhiều là càng tốt! Càng nhiều mảnh thì chi phí tái hợp nhất (
Re-aggregation Cost) lúc đọc càng hủy diệt hệ thống!"
3. CHỐT HẠ BÀN CỜ $96.50 VÀ CHIẾN TÍCH 3 SAO TRÙM CUỐI WORLD 2 🏆⚽
Chúng tôi cùng nhau ráp lại toàn bộ bàn cờ chiến thuật cho Màn 27:
- 1 Geo DNS Tier S ($1.50/tháng) cấu hình
TTL: 60s. - 1 Cụm App Server US (2 máy Tier S) ($30.00/tháng, công suất $1.000\text{ req/s}$).
- 1 Máy App Server EU (1 máy Tier S) ($15.00/tháng, công suất $500\text{ req/s}$).
- 1 Relational DB Tier L (Mỹ) ($50.00/tháng) cấu hình
Counter: Split 4. (Tuyệt đối không dùng Load Balancer vì bản thân Geo DNS đã phân bổ thẳng vào App Server, tiết kiệm trọn vẹn $20/tháng!)
flowchart TD
U_US["🇺🇸 Khán giả US (350 req/s)"] -->|"http"| DNS["🌐 Geo DNS (Tier S · TTL: 60s · $1.50)"]
U_EU["🇪🇺 Khán giả EU (350 req/s)"] -->|"http"| DNS
DNS -->|"Bình thường (0-180s & 480-600s)"| APP_EU["🇪🇺 App Server EU (1 máy Tier S · $15)"]
DNS -->|"Failover tức thì khi EU cúp điện (180-480s)"| APP_US["🇺🇸 App Server US (Cụm 2 máy Tier S · $30 · 1.000 req/s)"]
APP_US -->|"sql (150 writes/s/slot + 400 reads/s)"| DB["🗄️ Relational DB US (Tier L · Split 4 · $50)"]
APP_EU -->|"sql xuyên lục địa"| DB
Tôi bảo Đ:
- "Bấm chạy đi em trai! Đón chào chiếc cúp vàng World 2!"
Đ nhấn nút. Trận đấu mô phỏng 600 giây diễn ra nghẹt thở:
- Phút thứ 3, EU mất điện! Cụm EU vụt tắt.
- Nhưng chỉ sau đúng 60 giây, toàn bộ lưu lượng khán giả EU được Geo DNS nắn mượt mà sang cụm 2 máy tại Mỹ.
- Đồ thị CPU cụm Mỹ nhích lên 70%, nuốt trọn 700 req/s mà không rơi rụng một gói tin nào.
- Con Database Tier L Split 4 chạy điềm đạm ở ngưỡng $1.000\text{ req/s}$, giải quyết ngọt xớt từng đợt cập nhật view và đọc tỷ số.
Bảng tổng kết vàng óng hiện ra rạng rỡ:
================================================================================
🎉 HOÀN THÀNH MÀN 27 — CHUNG KẾT WORLD CUP (TRÙM CUỐI WORLD 2)!
================================================================================
- Tỷ lệ phản hồi thành công: 98.6% (Yêu cầu >= 90%) ✅ PASS
- Độ trễ phản hồi trung bình: 112 ms (Yêu cầu <= 300 ms) ✅ PASS
- Tổng chi phí hạ tầng: $96.50/tháng (Ngân sách tối đa: $111.00) ✅ PASS
- Chi phí mỗi triệu request: $0.0531 / 1M req (Yêu cầu <= $0.06) ✅ PASS
🏆 KỶ LỤC THẾ GIỚI 3 SAO (BEST COST): $96.50 / $111.00! ★★★
================================================================================
Đ nhảy cẫng lên ôm chầm lấy tôi giữa sảnh đấu:
- "Thắng rồi anh ơi! Trùm cuối World 2 chính thức gục ngã dưới con số $96.50! Không ngờ bí quyết để nuốt trọn một trận chung kết thế giới lại nằm ở một cái TTL 60 giây và con số 4 diệu kỳ!"
Tôi cười, đưa cho nó lon nước ngọt ướp lạnh:
- "Nghỉ ngơi đi. Phía trước chúng ta là World 3: AI Applications — nơi những con quái vật Token, LLM Streaming và Rate Limit 429 đang chờ đợi!"