Performance & Scale Handbook

01Vì sao đây là điểm yếu chung — và cách chữa

Phần lớn kỹ sư phần mềm tại Việt Nam ít có cơ hội chạm hệ thống thật sự lớn. Hệ quả là kiến thức về performance và scale bị học lý thuyết: thuộc tên pattern nhưng không có trực giác về bậc độ lớn. Biểu hiện điển hình:

• Nghe "scale" là nghĩ ngay tới microservices và Kafka, trong khi bài toán chỉ thiếu một index
• Không ước lượng được 5 triệu bản ghi/ngày là nhiều hay ít
• Không phân biệt được "hệ thống chậm" và "hệ thống không scale" — hai bài toán khác nhau hoàn toàn
• Thiết kế cho tải trung bình, quên tải đỉnh

01APerformance khác Scale như thế nào?

Hai khái niệm liên quan nhưng không đồng nghĩa:

Trình tự xử lý: đo và sửa bottleneck hiện tại trước, sau đó mới tính cách hấp thụ tải tăng. Không dùng microservices, cache hoặc sharding để che một lỗi performance chưa được profile.

02Bộ số phải thuộc lòng

Đây là phần cụ thể nhất, dễ dạy nhất và tạo khác biệt lớn nhất. Yêu cầu cả cohort thuộc, kiểm tra miệng đầu mỗi buổi Dojo. Không cần chính xác — cần đúng bậc độ lớn.

Độ trễ

Dung lượng & thông lượng

03Napkin math — quy trình 5 bước

Mọi bài toán trong Architecture Dojo đều bắt đầu bằng 5 phút này, làm trên giấy, không máy tính.

Ví dụ mẫu — campaign engine FMI

Yêu cầu: 5 triệu thông báo cá nhân hoá/ngày, đỉnh dồn trong 30 phút

Bước 1  5.000.000 / 100.000 s        ≈ 50 msg/s trung bình
Bước 2  Đỉnh: 60% lượng dồn 30 phút
        3.000.000 / 1.800 s          ≈ 1.700 msg/s  ← con số thiết kế
        (gấp 34× trung bình — thiết kế theo 50/s là sai hoàn toàn)
Bước 3  5 triệu × 500 B × 90 ngày    ≈ 225 GB  → ×3 (index+replica) ≈ 675 GB
Bước 4  1.700/s × 500 B              ≈ 850 KB/s ra ngoài — không đáng lo
Bước 5  1.700 write/s vào Postgres   → CHẠM TRẦN một instance
        1.700 msg/s vào Kafka        → thoải mái (dưới 1% năng lực)

Kết luận: nút thắt nằm ở tầng ghi dữ liệu, không phải tầng vận chuyển.
          Thiết kế phải tập trung vào batching / async write, không phải
          vào việc chọn message broker nào.

04Thang bậc mở rộng — 7 bậc, không nhảy cóc

Lỗi phổ biến nhất: nghe "scale" là nhảy thẳng lên bậc 5–6. Dạy và áp dụng đúng thứ tự.

05Bốn hiện tượng phải hiểu bằng trực giác

① Hot partition — chia đều trên lý thuyết, lệch trong thực tế

Dữ liệu thực tế gần như luôn tuân theo phân phối lệch. Trong B2B, khoảng 10% khách hàng lớn tạo ra 70–80% giao dịch. Partition theo customer_id nghe hợp lý, nhưng shard chứa khách hàng lớn nhất sẽ chết trước trong khi các shard khác nhàn rỗi.

Cách nhận diện: hỏi "10 giá trị phổ biến nhất của partition key chiếm bao nhiêu phần trăm dữ liệu?" Nếu trên 30% thì đã có vấn đề.

Cách xử lý: composite key (customer_id + thời gian hoặc + hash bucket) · tách riêng nhóm khách hàng lớn · hoặc chọn key khác hoàn toàn.

② Tail latency amplification — chia nhỏ service không miễn phí

Một request gọi song song 10 service, mỗi service có p99 = 100 ms. Xác suất ít nhất một service rơi vào p99 là 1 − 0.99¹⁰ ≈ 9,6%. Nghĩa là gần 10% request tổng sẽ chậm ít nhất 100 ms — dù mỗi service đều "khoẻ".

Hệ quả kiến trúc: càng fan-out rộng, p99 của hệ thống càng xấu theo cấp số. Đây là lý do kỹ thuật khiến "cứ tách nhỏ service ra" là lời khuyên nguy hiểm khi chưa có hedged request, timeout hợp lý và khả năng trả kết quả một phần.

③ Cascading failure — hệ thống chết dây chuyền

Chuỗi nhân quả điển hình: một service downstream chậm → caller giữ connection lâu hơn → connection pool cạn → caller ngừng phục vụ mọi request kể cả những request không liên quan → service gọi caller cũng chết theo → toàn hệ thống sập trong vài phút.

④ Chi phí phối hợp — Universal Scalability Law

Thêm node không làm throughput tăng tuyến tính, vì hai lý do: tranh chấp (chờ tài nguyên dùng chung) và chi phí đồng bộ (các node phải nói chuyện với nhau). Sau một ngưỡng, thêm node còn làm throughput giảm.

Ứng dụng thực tế: khi kết quả load test cho thấy tăng gấp đôi số node chỉ tăng 30% throughput, đó không phải lỗi cấu hình — đó là dấu hiệu có điểm đồng bộ hoặc tài nguyên dùng chung. Phải tìm ra điểm đó, không phải thêm node tiếp.

06Đọc và diễn giải chỉ số

07Ba bài toán scale gắn bối cảnh SU02

Ba đề trong Problem Bank lấy trực tiếp từ domain của phòng — đây là chỗ kiến thức chuyển thành thực chiến.

08Checklist rà soát thiết kế về performance & scale

Panel dùng checklist này ở mọi buổi Dojo. Người thiết kế dùng để tự rà trước khi trình bày.

Câu hỏi tổng quát về các cơ chế thường dùng

Đây là câu hỏi định hướng để review, không phải checklist cấu hình của một nền tảng cụ thể.

09Anti-patterns về scale