sys-analysis-design/sa-output/e-commerce/02-architecture/adr/ADR-009_chien-luoc-ha-dr-dich-vu-giao-dich-loi.md

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ý.