Back-of-the-Envelope: Kỹ năng Ước lượng Hệ thống Nhanh

Bước 2: Tính lượng Request mỗi giây (QPS)

• Tổng Request / Ngày = DAU × số actions.
• QPS trung bình = Tổng Request / 86400 (số giây trong ngày, hoặc làm tròn 100,000 để dễ tính).
• QPS đỉnh (Peak QPS) = QPS trung bình × 2 (hoặc × 3, tùy thuộc vào đặc thù sản phẩm có bị hiệu ứng "giờ vàng" hay không).

Bước 3: Ước lượng Kích thước Dữ liệu (Data Size) Phải nhớ các quy đổi cơ bản:

• 1 char = 1 byte (ASCII) hoặc 2 bytes (Unicode).
• 1 User ID / Integer = 4 hoặc 8 bytes.
• 1 dòng text ngắn / Metadata = 100 - 500 bytes.
• 1 bức ảnh = 100 KB - 2 MB.
• 1 video ngắn = 10 MB - 50 MB.

Bước 4: Ước lượng Lưu trữ & Băng thông (Storage & Bandwidth)

• Lưu trữ = (Số lượt tạo data / ngày) × Kích thước 1 data. Mở rộng ra 1 năm, 5 năm.
• Băng thông = (Số request / giây) × Kích thước payload trung bình.

4. Ví dụ thực tế (Case Study Application)

Bối cảnh: Shopee muốn ra mắt tính năng "Shopee Video Reviews" cho phép người mua đăng tải video đánh giá sản phẩm dài tối đa 1 phút. Yêu cầu tính toán lưu trữ và băng thông.

• DAU của app: 50 triệu.
• Chỉ 5% DAU mua hàng mỗi ngày = 2.5 triệu đơn hàng.
• Tỷ lệ để lại video review là 10% trên số đơn hàng = 250,000 video được upload mỗi ngày.
• Kích thước trung bình 1 video: 20 MB (đã qua nén).
• Tỷ lệ xem (Read) / Đăng (Write) là 20:1 (Mỗi video được xem trung bình 20 lần mỗi ngày).

• Lưu trữ mới mỗi ngày: 250,000 videos × 20 MB = 5,000,000 MB = 5 TB / ngày.
• Lưu trữ cho 1 năm: 5 TB × 365 = ~ 1.8 PB / năm. (Insight: Dữ liệu này rất lớn, đòi hỏi sử dụng hệ thống Cold Storage cho các video cũ không còn ai xem để tiết kiệm chi phí).

• Ingress (Băng thông tải lên): 5 TB / ngày chia cho ~100,000 giây (làm tròn số giây 1 ngày) = 50 MB/giây.
• Egress (Băng thông tải xuống - Read): Do Read/Write ratio là 20:1, băng thông tải xuống sẽ gấp 20 lần = 50 MB × 20 = 1000 MB/giây (hay 1 GB/giây). (Insight: 1 GB/giây tải xuống liên tục đòi hỏi phải sử dụng mạng lưới CDN (Content Delivery Network) mạnh mẽ để giảm tải cho server chính).

5. Anti-patterns & Những cạm bẫy cần tránh (Trade-offs)

Mặc dù BOTE rất hữu ích, nhưng nhiều PM và Engineer thường rơi vào các cạm bẫy hệ thống sau:

• Sự chính xác ảo (False Precision): Cố gắng tính toán ra kết quả kiểu "3,456.78 GB". BOTE chỉ cần ước lượng theo các bậc lớn (Order of Magnitude). Làm tròn mọi thứ để nhẩm được trong đầu.
• Bỏ qua "Tải Đỉnh" (Ignoring Peak Load): Thiết kế hệ thống chịu được QPS trung bình là sai lầm chết người. Một chiến dịch Flash Sale lúc 0h sáng có thể tạo ra QPS gấp 10-50 lần mức trung bình. Nếu BOTE không tính đến hệ số an toàn (Peak load multiplier), hệ thống sẽ sập ngay khi vừa ra mắt.
• Lạc lối trong hằng số mà quên Business Logic: Việc tính toán quá máy móc theo công thức mà không xét đến đặc thù sản phẩm. Ví dụ: Tính bộ nhớ Cache cho toàn bộ 100% video là lãng phí. Theo nguyên lý Pareto (80/20), chỉ có 20% video thịnh hành chiếm 80% lượt xem, do đó chỉ cần tính RAM/Cache để chứa 20% lượng dữ liệu này.
• Không giải thích các Giả định (Silent Assumptions): Trong phỏng vấn hoặc họp bàn, việc chốt ra kết quả "Hệ thống cần 10 server" mà không nói rõ bạn đã lấy DAU là bao nhiêu và tỷ lệ chuyển đổi thế nào sẽ khiến người nghe mất niềm tin hoàn toàn vào con số đó.

Sẵn sàng làm chủ việc ước lượng hệ thống?

Hãy thử nghiệm framework này ngay hôm nay. Hãy chọn một tính năng trong backlog của bạn, viết ra các giả định về DAU, định lượng kích thước payload và thử tính nhẩm QPS trong vòng 5 phút. Tư duy hệ thống bắt đầu từ việc hiểu rõ giới hạn vật lý của sản phẩm bạn đang xây.