# ADR-009 — Chiến lược HA/DR cho nhóm dịch vụ giao dịch lõi (Payment, Cart & Order, Identity & Access): RPO ≤15 phút, RTO ≤1 giờ

*Tên file: `adr/ADR-009_chien-luoc-ha-dr-dich-vu-giao-dich-loi.md`*

| | |
|---|---|
| **Status** | `Proposed` *(🔴 radar ≥8 — theo `decision-radar.md §2`/§6, **không được chuyển `Accepted` khi chưa diễn tập DR**; đây cũng là điều kiện tiên quyết ký AG2, không chỉ điều kiện riêng của ADR này)* |
| **Date** | 2026-09-15 |
| **Người quyết** | SA + Ops/SRE (hạ tầng/HA-DR — `decision-radar.md §5`: đề xuất SA, chốt SA+SRE, phủ quyết PO nếu vượt ngân sách) |
| **Người đề xuất** | SA (qua skill `sa-2-architecture`, hoạt động `adr`) |
| **Điểm radar** | **~9/10** — 🔴 bắt buộc diễn tập DR trước `Accepted` |
| **Supersedes** | — |
| **Superseded by** | — |
| **Liên quan** | `ASR-010` · `QAS-008` · `OQ-022` · `DEC-12` · `CMP-02`, `CMP-04`, `CMP-11` |

> ⚠️ **ADR bất biến sau khi `Accepted`.** Muốn đổi quyết định thì viết ADR mới có
> `Supersedes: ADR-009` và đổi trạng thái bản cũ thành `Superseded by`.

---

## 1. Bối cảnh

Payment, Cart & Order, Identity & Access (`ASR-010` gọi là "nhóm giao dịch cốt lõi") phải có khả
năng khôi phục sau sự cố với RPO ≤15 phút và RTO ≤1 giờ. `QAS-008` đã ghi rõ: con số này **kế
thừa nguyên trạng** từ `SAD.md §5.3.2/§9.5.2` (tài liệu trước khi có pipeline `sa-lifecycle`),
**chưa được SA thiết kế lại** ở lượt chạy này, và **chưa từng diễn tập** — theo `SKILL.md` mục 7:
"RTO/RPO chưa diễn tập là RTO/RPO trên giấy". `DEC-12` (duyệt từng phần `QAS`) đã chốt điều kiện:
diễn tập DR phải thực hiện **trước khi ký AG2** — đây không chỉ là điều kiện riêng của ADR này mà
là điều kiện tiên quyết của cả gate AG2.

**Ràng buộc đang chi phối:**

| Nguồn | Nội dung |
|---|---|
| `ASR-010` | RPO ≤15 phút, RTO ≤1 giờ cho Payment/Cart&Order/Identity — phải chứng minh bằng diễn tập trước AG2 |
| `QAS-008` | Con số kế thừa từ `SAD.md`, chưa thiết kế lại, chưa diễn tập |
| `OQ-022` | Lịch diễn tập DR đầu tiên — vẫn chờ Ops/SRE, đã chốt là điều kiện bắt buộc AG2 (`DEC-12`) |

**Cái đã biết chắc / cái còn là giả định:**

| Điều | 🟢 Đã kiểm chứng / 🔴 Giả định | Bằng chứng |
|---|---|---|
| RPO ≤15 phút / RTO ≤1 giờ là mục tiêu đã "chốt" trong tài liệu gốc | 🟡 Ước lượng có cơ sở | `SAD.md §5.3.2/§9.5.2` — nhưng là tài liệu kỹ thuật trước pipeline `sa-*`, chưa qua AG2 |
| Kiến trúc Multi-AZ hiện tại (`SAD §7` deployment view) đủ để đạt RPO/RTO này | 🔴 Giả định | Chưa diễn tập failover thật |
| Đội Ops/SRE sau go-live đủ năng lực thực hiện failover trong 1 giờ | 🔴 Giả định | `OQ-008` (số người/năng lực Ops chưa xác nhận), `CON-08` |

## 2. Phương án đã cân nhắc

### PA-1 — Multi-AZ trong 1 region (`ap-southeast-1`), backup point-in-time, không multi-region

| | |
|---|---|
| **Mô tả** | RDS Multi-AZ (failover tự động trong region), ECS Fargate chạy ≥2 AZ, backup PITR cho RDS (WAL archiving liên tục để đạt RPO ≤15 phút); DR = khôi phục từ backup/failover AZ trong cùng region |
| **Ưu** | Chi phí thấp hơn multi-region đáng kể; đủ chống chịu mất 1 AZ (sự cố phổ biến nhất); khớp `TCO §3.2` hiện tại (không phát sinh chi phí region thứ hai) |
| **Nhược** | Không chống được sự cố toàn bộ region `ap-southeast-1` (hiếm nhưng đã từng xảy ra với các nhà cung cấp cloud); RTO ≤1 giờ cho trường hợp phải khôi phục từ backup (không phải failover AZ) **chưa diễn tập** — có thể lạc quan hơn thực tế |
| **Chi phí đảo ngược** | Trung bình — nâng cấp lên multi-region sau này là dự án hạ tầng riêng, không phải cấu hình nhỏ |

### PA-2 — Multi-region active-passive (thêm region dự phòng, VD `ap-northeast-1`)

| | |
|---|---|
| **Mô tả** | Toàn bộ 3 service lõi có bản sao passive ở region thứ hai, đồng bộ liên tục, failover thủ công/tự động sang region đó khi region chính sập |
| **Ưu** | Chống được cả sự cố toàn region — RTO/RPO ổn định hơn trong kịch bản xấu nhất |
| **Nhược** | Tăng chi phí hạ tầng đáng kể (gấp ~1,5-2 lần cho 3 service lõi) — chưa có trong `TCO §3.2` hiện tại, cần PO duyệt ngân sách bổ sung; residency dữ liệu (NĐ13/2023) cần xác nhận lại nếu region thứ hai không phải `ap-southeast-1` (liên quan `ADR-008`) |
| **Chi phí đảo ngược** | Thấp — có multi-region rồi thu hẹp về 1 region dễ hơn chiều ngược lại |

### Bảng so sánh

| Tiêu chí | PA-1 (Multi-AZ, 1 region) | PA-2 (Multi-region active-passive) |
|---|---|---|
| Chi phí hạ tầng thêm | Thấp (đã có trong `TCO`) | Cao — cần PO duyệt bổ sung |
| Chống chịu mất 1 AZ | ✅ | ✅ |
| Chống chịu mất toàn region | ❌ | ✅ |
| Khớp ngân sách hiện tại (`CON-01`, `TCO §3.2`) | ✅ | ❌ Chưa có trong ngân sách |
| Rủi ro residency nếu region 2 khác `ap-southeast-1` | N/A | Cần xác nhận lại (`ADR-008`) |

## 3. Quyết định

> **Chọn PA-1 — Multi-AZ trong `ap-southeast-1`, backup point-in-time, không multi-region ở
> MVP.**

**Vì sao:** Khớp ngân sách hiện tại (`TCO §3.2` chưa tính chi phí multi-region) và đủ chống chịu
sự cố phổ biến nhất (mất 1 AZ). Multi-region là đánh đổi ngân sách vs độ sẵn sàng — thuộc thẩm
quyền PO (`D10`), chưa có đề nghị PO tăng ngân sách cho việc này.

**Phạm vi áp dụng:** Payment, Cart & Order, Identity & Access (nhóm giao dịch cốt lõi theo
`ASR-010`). Không áp dụng cho Nhóm Hỗ trợ (chưa có yêu cầu RPO/RTO tương đương).

### Điều kiện chuyển `Proposed → Accepted`

| Điều kiện | Ai xác nhận | Trạng thái hiện tại |
|---|---|---|
| **Diễn tập DR (failover drill) thật** đạt RPO ≤15 phút, RTO ≤1 giờ | Ops/SRE | 🔴 **Chưa từng diễn tập** (`OQ-022`) |
| Lịch diễn tập đầu tiên được xác nhận | Ops/SRE | Mở |
| Đây là điều kiện tiên quyết ký AG2 (không chỉ điều kiện riêng ADR này) | Tech Lead + Security + Ops/SRE | Theo `DEC-12` |

🔴 **Bắt buộc theo `decision-radar.md §2`/§6** — điểm radar ~9 (≥8) đồng nghĩa ADR này **không
được chuyển `Accepted`** cho tới khi có diễn tập DR thật. Nếu diễn tập cho kết quả không đạt: ghi
nhận vào `ARISK` mới, đánh giá lại kiến trúc backup/failover trước khi thử lại — không hạ thấp
tiêu chí RPO/RTO để "cho qua".

## 4. Phương án bị loại và lý do

| Phương án | Loại vì | Gắn với | Điều kiện nào thì xét lại |
|---|---|---|---|
| PA-2 — Multi-region active-passive | Chi phí thêm chưa có trong ngân sách đã duyệt (`TCO §3.2`); chưa có nhu cầu nghiệp vụ rõ ràng cho chống chịu mất toàn region ở MVP | `CON-01`, `TCO §3.2` | Nếu PO chấp nhận tăng ngân sách **và** đánh giá rủi ro mất toàn region là không chấp nhận được cho MVP — trình bảng đánh đổi cho PO quyết (`D10`), chưa có yêu cầu này |

## 5. Hệ quả

**Hệ quả tích cực**

- Khớp ngân sách hiện tại — không cần PO duyệt thêm chi phí ngoài `TCO §3.2`
- Đủ chống chịu sự cố phổ biến nhất (mất 1 AZ) mà không cần độ phức tạp vận hành của
  multi-region

**Hệ quả tiêu cực phải sống chung**

- Không chống được sự cố toàn region `ap-southeast-1` — rủi ro đã ghi nhận, chấp nhận có ý thức
  cho tới khi PO quyết định khác
- RTO ≤1 giờ cho khôi phục từ backup (không phải failover AZ tự động) phụ thuộc năng lực đội
  Ops/SRE thật — chưa xác nhận (`OQ-008`)

**Cái quyết định này khoá lại**

| Muốn đổi về sau thì | Tốn |
|---|---|
| Nâng cấp lên multi-region sau go-live | Dự án hạ tầng riêng — thiết kế đồng bộ dữ liệu xuyên region, xác nhận lại residency, tăng chi phí vận hành liên tục |

**Việc phát sinh**

| Việc | Chủ | Hạn | Ghi ở đâu |
|---|---|---|---|
| Xác nhận lịch diễn tập DR đầu tiên | Ops/SRE | Trước khi ký AG2 | `OQ-022` |
| Chạy diễn tập DR, ghi kết quả | Ops/SRE | Trước khi `Accepted` và trước AG2 | `ARISK_e-commerce_v1.0.md` (kết quả mới) |
| Trình PO bảng đánh đổi multi-region nếu Ops/SRE thấy cần | SA + Ops/SRE | Sau lần diễn tập đầu tiên nếu phát hiện rủi ro cao | `TCO` (cập nhật nếu PO chấp nhận) |

## 6. Cách kiểm chứng quyết định này được tuân thủ

| Cách kiểm | Công cụ | Chạy ở đâu | `FIT` |
|---|---|---|---|
| Diễn tập failover AZ (dừng 1 AZ giả lập) đo RTO thật | Chaos engineering thủ công / AWS Fault Injection Simulator | Staging, sau đó production (giờ thấp điểm) | — (kết quả ghi vào `ARISK`) |
| Backup PITR chạy đúng tần suất để đạt RPO ≤15 phút | Kiểm tra cấu hình WAL archiving/backup schedule | CI/CD (kiểm tra hạ tầng) | `FIT-12` (ứng viên) |
| Runbook failover được viết và diễn tập theo đúng bước | Review thủ công + diễn tập | Định kỳ (đề xuất 2 lần/năm, chưa chốt) | `⚠️ Khuyến nghị — không tự kiểm được, cần diễn tập thủ công` |

## 7. Điều kiện xét lại

| Dấu hiệu | Ngưỡng | Ai theo dõi |
|---|---|---|
| Diễn tập DR không đạt RPO/RTO | RPO > 15 phút hoặc RTO > 1 giờ | Ops/SRE |
| PO yêu cầu nâng mức sẵn sàng lên multi-region | Khi PO chấp nhận chi phí bổ sung | PO |
| Sự cố production thật cho thấy RTO/RPO thực tế khác đo ở diễn tập | Bất kỳ lần nào | SRE |

## 8. Tham chiếu

- POC: Diễn tập DR (chưa chạy) — xem `ARISK_e-commerce_v1.0.md` (kết quả sẽ bổ sung)
- Bài đo: `FIT-12` (ứng viên GĐ3)
- Tài liệu ngoài: `QAS_e-commerce_v1.0.md §A3 QAS-008`, `e-commerce/docs/sections/09-van-hanh-kiem-thu.md §9.5.2` (kế thừa nguyên trạng)
- Thảo luận: `ASR_e-commerce_v1.0.md §B2 ASR-010`, `DEC-12` (00-index/DEC_e-commerce.md)

## 9. Review log (không đổi Status)

| Ngày | Người review | Vai trò | Quyết định | Lý do chưa chuyển `Accepted` |
|---|---|---|---|---|
| 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, chế độ chạy thử) | Tech Lead (ký thay, ngoại lệ `DEC-01`) | `Reviewed (Proposed giữ nguyên)` — nội dung đủ làm cơ sở thiết kế tiếp (`icd`/`dat`/`sec`/`inf`/`fail`) | Radar 9 — bắt buộc diễn tập DR (failover drill) PASS trước khi `Accepted`, cũng là điều kiện tiên quyết `AG2`; chưa chạy |

> Đây là ghi nhận **review nội dung**, không phải "sign" theo nghĩa gate: `Status` giữ nguyên
> `Proposed`. Xem `00-index/ADL_e-commerce.md` (Change Log — Review 2026-09-15) và `ADL §8`
> "Việc phải làm" cho điều kiện chuyển `Accepted`. Confidence tổng thể của lượt review: 🔴 —
> `AG2` chưa ký.