🏗️🧠 System Design không phải đoán mò: 3 con số quyết định kiến trúc - System Design P4

Estimation 101: Ước Lượng “Đủ Xài” Trong System Design – Khi Những Con Số Định Hình Kiến Trúc

Tại sao phần lớn các kỹ sư thường bỏ qua bước ước lượng khi bắt đầu thiết kế một hệ thống? Câu trả lời tôi thường nhận được là: "Chúng ta có Cloud, nó sẽ tự động scale" hoặc "Đến lúc đó tính sau, giờ cứ lo logic tính năng đã."

Thẳng thắn mà nói, đây là cách nhanh nhất để đốt sạch ngân sách hạ tầng mà không mang lại một giây uptime nào. Nếu bạn không biết hệ thống của mình sẽ phải chịu tải bao nhiêu, bạn không phải đang "thiết kế", bạn đang "đánh bạc".

1. Dẫn nhập: Hiểu lầm kinh điển về những con số

Niềm tin phổ biến (Common Belief): Cloud là tài nguyên vô hạn và tính năng auto-scaling là chiếc đũa thần có thể giải quyết mọi vấn đề về tải.

Thực tế (Reality): Mọi tài nguyên vật lý đều có giới hạn cứng. Băng thông mạng (bandwidth), tốc độ đọc ghi của ổ cứng (IOPS), hay giới hạn kết nối của database không tự nhiên phình to ra chỉ vì bạn bật auto-scaling cho application server. Nếu thiết kế ban đầu sai lệch hoàn toàn về mặt vật lý, hệ thống của bạn sẽ saturate (bão hòa) và gãy ngay từ tầng hạ tầng. Việc scale theo chiều ngang (horizontal scaling) lúc này chỉ làm tăng thêm chi phí mà không giải quyết được các điểm nghẽn cổ chai (bottlenecks).

Luận điểm cốt lõi: Estimation (ước lượng) không cần chính xác tới từng byte. Nó cần "đủ tốt" để giúp bạn loại bỏ các phương án thiết kế phi thực tế. Một Senior Engineer không dùng máy tính để tìm số thập phân; họ dùng các bậc lũy thừa để quyết định kiến trúc.

2. Câu chuyện từ Production: Cái giá của việc "Thiết kế mù"

Tại TechCraft, tôi từng xử lý sự cố cho một team backend triển khai hệ thống xử lý đơn hàng. Họ dùng Microservices, Kafka, K8s – toàn những công nghệ "xịn" nhất. Logic code hoàn hảo, unit test phủ 90%. Nhưng khi đi vào vận hành thực tế vào ngày lễ mua sắm, hệ thống vỡ vụn ngay khi traffic vượt qua giả định mơ hồ ban đầu.

Hậu quả không chỉ là downtime. Latency tăng vọt khiến khách hàng bỏ giỏ hàng, database rơi vào trạng thái connection pool exhaustion. Team vận hành hối hả nâng cấp tài nguyên cloud một cách vô vọng, dẫn đến hóa đơn hạ tầng tăng 500% chỉ trong 24 giờ. Các kỹ sư kiệt sức vì trực chiến liên tục. Lỗi ở đây không nằm ở công nghệ, mà nằm ở việc thiết kế trong bóng tối mà không hề biết mình đang phục vụ 103 hay 106 người dùng.

3. Tại sao phải ước lượng? (The "Why" Before "What")

Ước lượng là công cụ tư duy để chuyển hóa yêu cầu nghiệp vụ thành giới hạn kỹ thuật:

• Định hình Technical Constraints: Giúp bạn biết hệ thống sẽ "chạm trần" ở đâu. Bạn đang đối mặt với bài toán về ghi dữ liệu (write-heavy) hay bài toán về truy xuất (read-heavy)?
• Lựa chọn công nghệ (Decision Thinking): Con số sẽ ép bạn phải lựa chọn. Ví dụ: Nếu Throughput vượt quá giới hạn của một database SQL đơn lẻ, bạn phải chọn Sharding hoặc NoSQL ngay từ đầu thay vì đợi lúc sập mới sửa.
• Tối ưu hóa nguồn lực: Tránh việc dùng "dao mổ trâu để giết gà". Một hệ thống chỉ có 10 RPS không cần đến một kiến trúc microservices phức tạp với Kafka và Redis cluster.

4. Tư duy "Back-of-the-envelope": Nghệ thuật của các bậc lũy thừa

Trong System Design, chúng ta tư duy theo Orders of Magnitude (quy tắc lũy thừa của 10). Sai số 10-20% không quan trọng bằng việc biết hệ thống đang ở mức 103 hay 106 requests.

Dưới đây là bảng thông số latency kinh điển mà mọi kiến trúc sư cần "khắc cốt ghi tâm" để làm hệ quy chiếu khi thiết kế:

5. Các trụ cột ước lượng trong System Design

Throughput (QPS/RPS)

Đừng bao giờ thiết kế cho con số trung bình. Hãy thiết kế cho Peak Traffic.

• Công thức nhanh: 1 triệu DAU ≈ 12 RPS trung bình. Nhưng thực tế, Peak Traffic có thể gấp 10-20 lần (~240 RPS).
• Quyết định kiến trúc: Nếu Peak RPS > 10.000, đừng mơ mộng việc ghi trực tiếp vào SQL DB mà không có một Message Queue (như Kafka/RabbitMQ) để buffer áp lực ghi.

Storage (Dữ liệu tích lũy)

Tính toán dung lượng lưu trữ trong 3-5 năm giúp bạn định hình chiến lược quản lý dữ liệu.

• Quyết định kiến trúc: Nếu dữ liệu dự kiến vượt 10TB trong 3 năm, bạn phải tách biệt dữ liệu nóng (Hot data - dùng SSD/SQL) và dữ liệu lạnh (Cold data - dùng S3/Cold Storage) ngay để tối ưu chi phí và hiệu năng.

Bandwidth (Băng thông)

Đặc biệt quan trọng với Social Network.

• Ví dụ thực tế: Nếu mỗi user lướt 50 ảnh/ngày (200KB/ảnh), với 1 triệu DAU, bạn cần phục vụ 10TB dữ liệu mỗi ngày.
• Quyết định kiến trúc: 10TB egress mỗi ngày không chỉ là bài toán kỹ thuật mà là một hóa đơn Cloud khổng lồ. Bạn bắt buộc phải dùng CDN để giảm tải egress cost và tăng trải nghiệm người dùng.

6. Phân tích đánh đổi (Trade-off Analysis)

Mọi quyết định dựa trên ước lượng đều có giá của nó:

7. Các trường hợp thất bại (Failure Cases)

1. The Hidden Bottleneck (Deadlock): Bạn scale K8s lên 100 pods để chịu tải, nhưng database Postgres chỉ cấu hình 500 connections. Mỗi pod cố lấy 10 connections. Hệ thống không chỉ chậm mà rơi vào trạng thái deadlock, các pod mới không thể khởi động vì không lấy được connection để health check.
2. The Storage Explosion: Quên tính overhead của Index và Replication. Một bản ghi 100 bytes thực tế tiêu tốn 300 bytes trên đĩa. Sau 6 tháng, hệ thống sập toàn bộ vì disk full ngay trong đêm do log và index phình to ngoài dự kiến.
3. The Bandwidth Trap: Thiết kế hệ thống media mượt mà nhưng bỏ qua phí truyền tải (egress bandwidth). Cuối tháng, hóa đơn cloud gửi về cao hơn cả doanh thu, đẩy sản phẩm vào tình trạng lỗ vốn vận hành.

8. Lăng kính Senior: Từ con số đến quyết định kiến trúc

Một Senior Engineer không nhìn con số như bài tập toán, mà nhìn chúng như các ranh giới kiến trúc (Architectural Boundaries):

"Nếu Write QPS > 5.000: Bắt buộc phải có Message Queue và xử lý Async."

"Nếu Read QPS > 20.000: Cần Multi-layer Caching (Local cache + Redis)."

"Nếu Data Size > 5TB: Phải bắt đầu thiết kế Database Sharding hoặc Partitioning."

Các con số chính là "la bàn" để bạn không bị lạc lối giữa rừng công nghệ.

9. Tổng kết và Bài học mang về

• ✅ Estimation là tư duy, không phải phép tính: Mục tiêu là để loại bỏ các thiết kế bất khả thi (impossible designs).
• ✅ Tư duy Orders of Magnitude: Đừng quan tâm 10 hay 12, hãy quan tâm là 101 hay 102.
• ✅ Peak over Average: Luôn thiết kế cho mức tải cao điểm, không phải mức trung bình.
• ✅ Trade-off là bắt buộc: Mọi con số đều dẫn đến sự đánh đổi giữa Chi phí - Độ phức tạp - Độ tin cậy.

10. Tiếp theo là gì?

Khi đã có những con số ước lượng "đủ xài" trong tay, làm thế nào để phác thảo toàn bộ hệ thống một cách mạch lạc chỉ trong vòng 1 phút? Đó chính là lúc chúng ta cần đến sức mạnh của High-Level Architecture.

🚀 Tiếp tục hành trình cùng TechCraft

Bài viết này là một phần trong hành trình khám phá Backend Engineering, System Design và Production Systems tại TechCraft.

Nếu bạn muốn học theo một lộ trình rõ ràng hơn, TechCraft đang xây dựng Dev Insider như nơi tập trung các series chuyên sâu hơn về:

• Backend Internals
• Database Internals
• Transaction & Consistency
• Distributed Systems
• Production System Design
• AI-Proof Engineer

🚀 Dev Insider
https://www.patreon.com/techcraft_official/posts/vi-sao-dev-ra-161163881?collection=2220113

📘 Facebook
https://www.facebook.com/techcraft.official

🎥 YouTube
https://www.youtube.com/@techcraft.official

🎵 TikTok
https://www.tiktok.com/@techcraft.official

Hiểu hệ thống. Không chỉ framework.