Back-of-the-envelope capacity estimation là gì và làm thế nào để ước lượng QPS, storage, bandwidth cho một hệ thống trong buổi phỏng vấn?

Mục đích không là con số chính xác, mà để chọn kiến trúc đúng tầm (cần shard chưa? cache bao nhiêu? vài server hay vài nghìn?). Phỏng vấn viên đánh giá cách bạn suy luận, không phải số thập phân.

Quy trình:
1. Bắt đầu từ DAU và hành vi: vd 100M DAU, mỗi user 10 read + 1 write/ngày.
2. Ra QPS trung bình: 100M × 10 / 86,400s ≈ 11.5K read/s. Nhân peak factor 2–3× → ~30K read/s.
3. Storage: kích thước mỗi bản ghi × số bản ghi/ngày × thời gian giữ. Vd tweet 300 byte × 200M/ngày ≈ 60 GB/ngày → ~21 TB/năm (chưa tính index/replica ×3).
4. Bandwidth: QPS × payload size. Đọc 30K/s × 1KB ≈ 30 MB/s egress.
5. Memory cho cache: áp 80/20 — cache 20% hot data. Vd 20% của 60GB/ngày ≈ 12GB Redis.

Mẹo số tròn (cần thuộc):
- 1 ngày ≈ 86,400s ≈ 100K giây (làm tròn cho dễ chia).
- Đọc thường ≫ ghi (10:1 đến 100:1) → thiết kế read-heavy (replica, cache).
- Powers of 2: KB→MB→GB→TB.

Lưu ý: nêu rõ giả định ngay từ đầu ("giả sử mỗi user..."); luôn nhân peak; tách read/write vì chúng dẫn tới quyết định khác nhau (cache vs sharding).

The goal is not an exact number but to pick the right-sized architecture (need sharding yet? how much cache? a few servers or thousands?). Interviewers grade your reasoning, not decimals.

Process:
1. Start from DAU and behavior: e.g. 100M DAU, each does 10 reads + 1 write/day.
2. Average QPS: 100M × 10 / 86,400s ≈ 11.5K reads/s. Apply a peak factor 2–3× → ~30K reads/s.
3. Storage: record size × records/day × retention. E.g. a 300-byte tweet × 200M/day ≈ 60 GB/day → ~21 TB/year (before index/replica ×3).
4. Bandwidth: QPS × payload. 30K reads/s × 1KB ≈ 30 MB/s egress.
5. Cache memory: apply 80/20 — cache 20% hot data. E.g. 20% of 60GB/day ≈ 12GB Redis.

Round-number tricks (memorize):
- 1 day ≈ 86,400s ≈ 100K seconds (round for easy division).
- Reads usually ≫ writes (10:1 to 100:1) → design read-heavy (replicas, cache).
- Powers of 2: KB→MB→GB→TB.

Note: state assumptions up front ("assume each user..."); always multiply by peak; separate reads/writes because they drive different decisions (cache vs sharding).