Part 10 · System Design · 10.1.02
Từ user journey đến SLO và invariant
“Scale lớn, nhanh, HA” không phải requirement; cần operation, percentile, window và failure semantics cụ thể.
Mental model: trước khi chọn database, cache, queue hay multi-region, hãy khóa phạm vi chức năng, outcome mà user nhìn thấy, mức reliability cần bảo vệ và invariant tuyệt đối không được phá.
1. Functional scope: thiết kế đúng bài toán trước khi thiết kế hệ thống
Xác định actors, write/read journeys, admin/abuse flows, lifecycle và exclusions. Chọn 2–3 critical journeys làm xương sống; không thiết kế toàn bộ sản phẩm tưởng tượng.
| Câu hỏi scope | Cần chốt | Ví dụ cách phát biểu |
|---|---|---|
| Ai dùng hệ thống? | Actors và quyền chính | User tạo đơn; admin review; anti-abuse có thể khóa request. |
| Journey nào quan trọng? | 2–3 luồng write/read cốt lõi | Create order → pay → read order status. |
| Lifecycle ra sao? | Create, update, archive/delete, retention | Order immutable sau settlement; dữ liệu audit giữ theo policy. |
| Không làm gì? | Explicit exclusions | Không thiết kế recommendation engine trong vòng interview này. |
Scope guarantee: một requirement tốt nói rõ operation và outcome. “Hệ thống phải scale lớn” chưa cho biết scale cho write, read, fan-out, storage hay recovery.
2. Quality attributes: biến “nhanh, ổn định, an toàn” thành tiêu chí đo được
Latency theo p95/p99 và endpoint/journey; availability theo successful event / eligible traffic / window; durability theo accepted writes; consistency theo operation; retention, privacy, residency và audit theo data class.
| Attribute | Cách đặc tả | Điểm cần tránh |
|---|---|---|
| Latency | Gắn percentile với endpoint hoặc end-to-end journey. | Chỉ nói “low latency” hoặc dùng average che tail latency. |
| Availability | Định nghĩa successful event, eligible traffic và cửa sổ đo. | Đếm mọi HTTP 200 là success dù user outcome thất bại. |
| Durability | Nói rõ accepted write nào phải sống qua failure. | Trộn durability với availability. |
| Consistency | Chọn semantics theo từng operation/journey. | Yêu cầu “strong consistency everywhere” mà không gắn business need. |
| Data governance | Retention, privacy, residency, audit theo từng data class. | Dùng một policy chung cho mọi dữ liệu. |
Ví dụ format SLI/SLO: “Trong cửa sổ 28 ngày, 99.9% eligible checkout attempts hoàn tất thành công; p99 latency của bước confirm dưới ngưỡng đã thống nhất.” Nếu đo đơn giản trên 30 ngày, availability 99.9% tương đương khoảng 43.8 phút unavailable; design vẫn phải định nghĩa successful event, eligible traffic, window, partial degradation và scope endpoint/journey. Con số cụ thể phải đến từ business/reliability requirement, không tự suy diễn.
3. RPO, RTO, SLO và error budget
RPO là data loss tối đa chấp nhận; RTO là thời gian phục hồi. Multi-AZ/region chỉ có ý nghĩa khi detection, traffic shift, state recovery và verification đáp ứng hai mục tiêu này. Error budget giúp trade reliability với delivery.
| Khái niệm | Câu hỏi nó trả lời | Ảnh hưởng thiết kế |
|---|---|---|
| RPO | Sau sự cố, tối đa được mất bao nhiêu dữ liệu? | Replication, backup frequency, write acknowledgement, recovery source. |
| RTO | Tối đa bao lâu phải khôi phục service? | Detection, failover, traffic shift, restore/rebuild, verification. |
| SLO | Trong một window, mức service user-facing nào phải đạt? | SLI definition, alerting, capacity headroom, degradation policy. |
| Error budget | Ta còn bao nhiêu “room” cho unreliability trong SLO? | Cân bằng tốc độ delivery và reliability work. |
Failure semantics: “multi-region” không tự động đồng nghĩa RPO≈0 hoặc RTO ngắn. Phải mô tả cả chuỗi phát hiện lỗi → chuyển traffic → phục hồi state → xác minh hệ thống đã an toàn.
4. Invariant first: điều gì tuyệt đối không được sai?
Payment không double charge; seat không oversell; message per conversation có order; short URL không đổi destination trái phép. Invariant quyết định transaction, idempotency, partition key và reconciliation.
| Invariant | Rủi ro nếu vi phạm | Thiết kế bị chi phối |
|---|---|---|
| Payment không double charge | User bị trừ tiền nhiều lần khi retry/unknown outcome. | Idempotency key, atomic boundary, reconciliation. |
| Seat không oversell | Hai người cùng sở hữu một inventory unit. | Concurrency control, reservation/transaction semantics. |
| Message có order trong conversation | Conversation hiển thị sai thứ tự business. | Partition/routing key, sequence handling. |
| Short URL không đổi destination trái phép | Integrity/security bị phá. | Authorization, immutable/controlled update path, audit. |
Interview rule: nói invariant trước primitive. Đừng bắt đầu bằng “dùng distributed transaction”; hãy nói business property cần giữ, rồi mới giải thích transaction/idempotency/partitioning nào đáp ứng nó.
5. Partial degradation: bảo vệ critical path khi dependency hỏng
Định nghĩa critical vs optional: checkout vẫn chạy khi recommendations chết; notification có thể delay nhưng payment ledger không mất. SLI phải phản ánh user-visible outcome, không chỉ HTTP 200.
| Thành phần | Khi lỗi có thể làm gì? | Không được phá gì? |
|---|---|---|
| Recommendations | Ẩn module, dùng fallback hoặc stale result. | Không chặn checkout critical journey. |
| Notification | Delay/retry xử lý. | Không làm mất payment state chỉ vì email/SMS chậm. |
| Payment ledger | Không coi như optional. | Accepted financial state không được mất. |
User-visible SLI: endpoint trả 200 nhưng order không được tạo, payment bị double charge hoặc checkout không hoàn tất thì đó không phải success theo góc nhìn user journey.
6. Checklist dùng khi làm System Design
- Actors, read/write/admin/abuse flows và exclusions đã rõ chưa?
- Đã chọn 2–3 critical journeys để làm xương sống chưa?
- Latency có percentile + endpoint/journey không?
- Availability có success event + eligible traffic + window không?
- Durability và consistency có được phát biểu theo operation không?
- Retention, privacy, residency, audit có theo data class không?
- RPO/RTO có nối với detection, traffic shift, state recovery và verification không?
- Invariant nào quyết định transaction, idempotency, partition key và reconciliation?
- Dependency optional nào được degrade để bảo vệ critical path?
- SLI có đo user-visible outcome thay vì chỉ infrastructure/HTTP status không?
Tài liệu chính thức từ source BK: Google SRE: Service Level Objectives · AWS Well-Architected: Reliability