# OPT — Solution Options & Trade-off — e-commerce

| | |
|---|---|
| **Version** | 1.0 |
| **Date** | 2026-09-12 |
| **Author** | SA (skill sa-1-context, chế độ `go`, hoạt động `options`) |
| **Status** | 🟡 Draft *(duyệt từng phần — xem `Approved by`; §1 Khuyến nghị, §2 Bộ tiêu chí và trọng số mặc định (đóng `ASM-09`), §4 Bảng chấm điểm, §5 Phương án bị loại (P3/P4) đã được duyệt tạm để làm nền cho Bước 5/GĐ2 — **chọn P2** có điều kiện (`OQ-010`, `OQ-012`); đây **chưa phải** AG1 toàn phần — Tech Lead chưa ký, `OQ-004` còn mở, quyết định kiến trúc chính thức (`ADR`) vẫn để GĐ2; xem "Tự chấm" §① — vẫn 4/7 tiêu chí ✅)* |
| **Approved by** | PO (uỷ quyền, chế độ chạy thử): **Điều phối dự án** — duyệt **từng phần** bản v1.0 · 2026-09-12: chấp nhận bộ tiêu chí và trọng số mặc định (§2, đóng `ASM-09`), bảng chấm điểm (§4), hai phương án bị loại P3/P4 (§5), và khuyến nghị P2 có điều kiện (§1). **Chọn P2** (modular monolith + managed AWS, tách riêng Payment) làm nền cho Bước 5 và GĐ2, điều kiện: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC SQS/EventBridge được ghi vào `ARISK` ở Bước 5 (`OQ-012`), trước khi chốt `ADR` message backbone GĐ2. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-06`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở. Duyệt này vẫn là duyệt **từng phần**, không phải AG1 toàn phần, và **không thay thế yêu cầu `ADR` chính thức ở GĐ2** (kiểu kiến trúc tổng thể là quyết định thuộc danh mục bắt buộc ADR theo `decision-radar.md §3`). · Tech Lead: — *(chưa ký)* |
| **Source** | `01-context/CTX_e-commerce_v1.0.md` (v1.2 trong header) §2 (`DRV-01…09`), §3 (`CON-01…09`), §4.2 (đối tác 🔴), §4.4 (năng lực tổ chức) · `e-commerce/docs/SAD.md` v0.2 §3.1–§3.4 (`e-commerce/docs/sections/03-kien-truc.md`) · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` (FR/NFR) · `e-commerce/bid/estimate.computed.json` (Draft, `priceComplete:false`) · `e-commerce/bid/bid-config.md` (Draft) · `00-index/OQ_e-commerce.md` v1.4 · `00-index/DEC_e-commerce.md` v1.4 |
| **Scope** | Toàn sàn e-commerce (marketplace đa seller) theo `SAD.md` v0.2 — phạm vi đã chốt cho lượt chạy này; `OQ-003` (giữ toàn sàn hay thu hẹp về Giỏ hàng & Checkout) **vẫn mở**, chưa ảnh hưởng cấu trúc phương án ở đây vì cả ba phương án đều mô tả ở mức kiến trúc tổng thể toàn sàn |
| **Confidence** | 🔴 Giả định chưa xác minh — kế thừa nguyên nhân của `CTX` (BA chưa ký G1 thật, AG1 GĐ1 SA chưa từng chạy, ngoại lệ gate `DEC-01/03/04` tiếp tục ở `DEC-05`). Riêng phần điểm số ở đây còn thêm hai lý do: (a) `CON-01`/`CON-02`/`CON-05` — ba tiêu chí input trực tiếp cho bảng chấm — đều "Chưa xác định/Mềm" trong `CTX`, chỉ có số tham khảo từ hồ sơ thầu Draft; (b) con số hạ tầng dùng để so sánh P1/P2 ở đây là **số lượng/loại thành phần quản lý (managed component)**, không phải tiền — `TCO` bằng VND thật để Bước 5, ngoài phạm vi lượt chạy này. Duyệt từng phần theo `DEC-06`
**không** nâng `Confidence` này (phê duyệt không phải bằng chứng nguồn mới) — vẫn chờ `OQ-004`
(tính hợp lệ ký thay), `OQ-010` (kinh nghiệm team thật), `OQ-012` (POC SQS/EventBridge) |

## Change Log

| Version | Date | Người sửa | Thay đổi | ADR/DEC |
|---|---|---|---|---|
| 1.0 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `options`) | Bản đầu — Bước 4 của `sa-1-context`: chốt bộ tiêu chí (từ `DRV`/`CON`), dựng 3 phương án chấm điểm (P0 giữ nguyên, P1 modular microservices theo `SAD.md`/hồ sơ thầu, P2 modular monolith + managed AWS — phương án đối trọng độc lập), 2 phương án bị loại có lý do (P3 mua/tích hợp nền tảng sẵn có, P4 serverless-first). Khuyến nghị **P2 có điều kiện** — không tự quyết thay PO/Tech Lead (`D10`). Tiếp tục ngoại lệ gate `DEC-01`/`DEC-03`/`DEC-04`, ghi thêm `DEC-05`. Không sửa `CTX` §2–§5 đã duyệt từng phần; chỉ tham chiếu. `Confidence` 🔴 toàn tài liệu. | `DEC-05` |
| 1.0 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **từng phần** bản v1.0: chấp nhận bộ tiêu chí và trọng số mặc định (§2, đóng `ASM-09`), bảng chấm điểm (§4), hai phương án bị loại P3/P4 (§5), khuyến nghị P2 có điều kiện (§1). **Chọn P2** (modular monolith + managed AWS, tách riêng Payment) làm nền cho Bước 5 và GĐ2, điều kiện: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC SQS/EventBridge (`ASM-07`) ghi vào `ARISK` ở Bước 5, trước khi chốt `ADR` message backbone GĐ2 (`OQ-012`). Không đổi nội dung chuyên môn. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-06`; **không phải chữ ký PO/Tech Lead thật** — `OQ-004` giữ mở, Tech Lead **chưa ký**. `Confidence` giữ 🔴. Status **giữ** 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện (4/7 tiêu chí ✅, xem §①); quyết định kiến trúc chính thức vẫn để `ADR` ở GĐ2, DEC-06 chỉ ghi nhận hướng đi tạm. `OQ-011` đóng trong sổ `00-index/OQ_e-commerce.md` bằng chính câu trả lời có điều kiện này. | `DEC-06` |

> ⚠️ **Đây là tài liệu PO + Tech Lead ký để qua AG1.** Đọc §1 và §5 là đủ để quyết. Tài liệu này
> **chưa đủ điều kiện baseline AG1 một mình** — vẫn thiếu `TCO` (Bước 5) và `ARISK`/kế hoạch POC
> (Bước 5), xem "Tự chấm" ở cuối `CTX_e-commerce_v1.0.md` §Tự chấm ① (cập nhật lại ở cuối file
> này).

> Sơ đồ thắng về **quan hệ và luồng** (ai gọi ai, đồng bộ/bất đồng bộ). Bảng/văn bản thắng về
> **ràng buộc và con số** (timeout, quyền, đơn vị hạ tầng). Mâu thuẫn ngoài hai loại này là lỗi
> tài liệu, phải sửa chứ không chọn bên (`D12`).

---

## 0. Ghi chú Preflight & ngoại lệ gate — tiếp nối `CTX`

Gate AG1 (PO + Tech Lead) của chính GĐ1 SA **chưa từng chạy** cho dự án e-commerce, và BA vẫn
chưa ký G1 chính thức (`BRIEF_CartCheckout` Draft) — như đã ghi ở `CTX §0`, `DEC-01`, `DEC-03`,
`DEC-04`. Người dùng (vai điều phối dự án chạy thử) **tái khẳng định muốn tiếp tục** sang Bước 4
(`OPT`) của `sa-1-context` dù các điều kiện trên chưa đạt.

> **DEC-05 (SA)** — Tiếp tục chạy `sa-1-context` Bước 4 (Phương án — `OPT`) cho dự án e-commerce
> trong khi BA vẫn chưa qua G1 và AG1 (gate của chính GĐ1 SA) vẫn chưa từng chạy — tiếp nối
> `DEC-01`/`DEC-03`/`DEC-04`.
> **Quyết định:** Tiếp tục, `Confidence 🔴` cho toàn bộ nội dung điểm số (dựa trên `CON` còn
> "Chưa xác định/Mềm") cho tới khi có số ngân sách/deadline/team thật (`OQ-005`, `OQ-006`,
> `OQ-008`).
> **Người quyết:** Điều phối dự án (đại diện PO, dự án chạy thử).
> **Radar (ước lượng):** ~3–4 (chi phí đảo ngược thấp — nội dung `OPT` sửa lại khi có số thật
> không tốn nhiều · bán kính ảnh hưởng: toàn bộ quyết định kiến trúc GĐ2 phụ thuộc phương án
> chọn ở đây, nhưng bản thân *việc ghi tài liệu dưới ngoại lệ* thì nhỏ · chưa chạm trực tiếp một
> `QAS` cụ thể (`QAS` chưa tồn tại, đây vẫn là GĐ1) · không ràng buộc dài hạn (ngoại lệ tạm thời)
> · không tranh cãi mới, tiếp nối tiền lệ) → **ghi `DEC-nn`, không cần `ADR`** theo
> `decision-radar.md §1–§2`.
> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng `sa-1-context` ở cuối Bước 3, không có `OPT` để
> PO/Tech Lech tham khảo cho tới khi BA ký G1 thật và/hoặc AG1 chạy đủ vòng đầu — chậm tiến độ
> chạy thử tương ứng.

🔴 **Lưu ý quan trọng cho người ký:** bảng chấm điểm dưới đây dùng số liệu tham khảo từ hồ sơ
thầu (`e-commerce/bid/`, Draft, `priceComplete:false`) cho các tiêu chí Chi phí/Thời gian/Team —
đây là ước lượng của **nhà thầu cho mục đích đấu thầu**, không phải số đã được PO xác nhận
(`OQ-005`, `OQ-006`, `OQ-008` vẫn mở). Điểm số vì vậy phản ánh **thứ tự tương đối** hợp lý giữa
các phương án hơn là giá trị tuyệt đối đáng tin cậy.

---

## 1. Khuyến nghị *(đọc mục này trước)*

| | |
|---|---|
| **Phương án khuyến nghị** | **P2 — Modular monolith + managed AWS services, tách riêng Payment Service** |
| **Vì sao** | Khớp Conway với team giả định `DEC-02`/hồ sơ thầu (BE trung bình chỉ ~2,6 FTE/tháng trên 7 tháng — xem §3 P2 "Ai vận hành") — 10 service độc lập của P1 vượt quá năng lực vận hành thực tế của một team cỡ này (`CON-05`); đồng thời P2 vẫn giữ nguyên yêu cầu cứng `CON-06` (cô lập Payment Service cho PCI-DSS SAQ A) và không đổi vùng AWS (`CON-03`) |
| **Chỗ phương án này THUA** | Thua P1 ở tiêu chí "Đáp ứng `DRV` Must" (4 so với 5) — khả năng scale-out **độc lập** Catalog/Search khỏi Cart/Checkout (`DRV-04`) yếu hơn khi cả hai còn chung một nhóm deployable ở giai đoạn đầu; đây là đánh đổi thật, không phải P2 thắng tuyệt đối |
| **Điều kiện kèm theo** | (1) Tech Lead xác nhận đội thi công thật (không phải đề xuất hồ sơ thầu) — trả lời `OQ-010`; (2) trước khi chốt `ADR` message backbone ở GĐ2, chạy POC đo throughput SQS/EventBridge cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải tương đương `DRV-04` (`ASM-07`, `OQ-012`) — **POC fail (không đạt thông lượng cần thiết) ⇒ bổ sung Kafka/MSK riêng cho hot-path đặt hàng (kiến trúc lai), không chuyển hẳn sang P1** vì phần còn lại của P1 (10 service tách rời) vẫn vi phạm Conway; (3) PO xác nhận ngân sách đủ để về sau tách Catalog/Search ra khỏi monolith nếu traffic thật vượt ngưỡng dự kiến (`ASM-08`) |
| **Quyết định này cần ai ký** | PO (đánh đổi giữa scale-out sớm và phù hợp năng lực team hiện tại) · Tech Lead (khả thi thi công/vận hành với team thật) — **chưa ký, đây vẫn là khuyến nghị của SA, không phải quyết định** (`D10`) |

---

## 2. Bộ tiêu chí *(chốt TRƯỚC khi mô tả phương án)*

*Tiêu chí sinh từ `DRV` (Must trước) và `CON` (cứng là điều kiện loại, không phải điểm số).
Trọng số dùng nguyên bộ mặc định của `sa-1-context/templates/option-tradeoff.md` — chưa có
buổi duyệt trọng số riêng với PO/Tech Lead (kế thừa hạn chế elicitation của `CTX`), ghi nhận là
giả định tiếp theo.*

### 2.1 Điều kiện loại (gate cứng — pass/fail trước khi chấm điểm)

| `CON` | Nội dung | Bắt buộc gì | P0 | P1 | P2 | P3 | P4 |
|---|---|---|---|---|---|---|---|
| `CON-03` | Cloud AWS bắt buộc | Không dùng cloud khác/on-prem | N/A (không xây) | ✅ Pass | ✅ Pass | ⚠️ Phụ thuộc bản build nền tảng — hầu hết nền tảng open-source multi-vendor có thể tự host trên AWS, coi là Pass được nếu tự triển khai | ✅ Pass (Lambda/Step Functions đều AWS) |
| `CON-06` | PCI-DSS SAQ A (không lưu thẻ) + NĐ13/2023 (PII/KYC) — Payment phải là biên cô lập duy nhất | Thiết kế phải tách được Payment Service/module ra làm biên cô lập | N/A | ✅ Pass — đã thiết kế sẵn trong `SAD.md` §3.1 | ✅ Pass — Payment tách riêng dù phần còn lại gộp (xem §3 P2) | ❌ **Không kiểm chứng được** với lõi đóng gói sẵn của nền tảng mua/tích hợp mà không sửa sâu — xem §5 lý do loại | ⚠️ Chưa kiểm chứng cô lập Payment trong mô hình serverless (Lambda dùng chung VPC/role) — chưa loại nhưng là rủi ro cao, xem §5 |

**Đọc bảng:** `CON-06` là lý do loại chính của P3. `P4` không bị loại bởi gate cứng nhưng bị
loại ở bước chấm điểm rủi ro kỹ thuật + thiếu bằng chứng năng lực team (§5).

### 2.2 Tiêu chí chấm điểm (áp dụng cho phương án đã qua gate cứng)

| # | Tiêu chí | Trọng số | Sinh từ | Đo bằng |
|---|---|---|---|---|
| 1 | Đáp ứng `DRV` mức Must (`DRV-01,02,03,04,05,06,07,08`) | 25% | `DRV-01…08` | Có/không cho từng driver, quy về thang 1–5 |
| 2 | Chi phí 3 năm (sơ bộ — số lượng/loại managed component, **không** phải VND; `TCO` VND thật ở Bước 5) | 20% | `CON-01` (chưa xác định số thật) | Số lượng thành phần hạ tầng quản lý riêng biệt phải vận hành |
| 3 | Thời gian tới bản chạy được | 15% | `CON-02` (7 tháng thầu / 9–12 tháng brief) | Effort WBS liên quan tới việc dựng nền tảng (tuần/MD, theo `estimate.computed.json`) |
| 4 | Rủi ro kỹ thuật | 15% | Nguồn rủi ro "Công nghệ mới"/"Phụ thuộc bên ngoài" (`decision-radar.md`) | Có bằng chứng team từng chạy production công nghệ này chưa (`CTX §4.4`) |
| 5 | Phù hợp năng lực team & vận hành (Conway) | 15% | `CON-05`, `DEC-02` | Số service/module so với FTE BE trung bình thật (nguồn `estimate.computed.json.mmByRole`) |
| 6 | Khả năng tiến hoá (chi phí đảo ngược) | 10% | — | Chi phí tách/gộp lại về sau |

**Trọng số do ai duyệt · ngày:** Chưa ai duyệt chính thức — SA dùng bộ mặc định của template vì
chưa có buổi làm việc PO/Tech Lech riêng cho trọng số (kế thừa hạn chế elicitation, xem `OQ-001`
của `CTX`). Ghi nhận: nếu PO/Tech Lead muốn đổi trọng số (ví dụ tăng "Rủi ro kỹ thuật" hoặc "Chi
phí" vì ngân sách hạn chế theo `CON-01`), chấm lại theo trọng số mới trước khi ký AG1.

🔴 Trọng số này **không** được chốt trong một buổi làm việc PO xác nhận — nếu điểm tổng P2 so
với P1 (§4) đổi thứ hạng khi tăng trọng số "Chi phí" hoặc "Năng lực team" (hai tiêu chí P2 đang
mạnh), khuyến nghị càng vững; nếu PO tăng mạnh trọng số "Đáp ứng DRV Must" (tiêu chí P1 mạnh
hơn), thứ hạng có thể đổi — xem `OQ-011`.

---

## 3. Các phương án

### P0 — Không làm gì / giữ nguyên *(mốc so sánh, bắt buộc có)*

| | |
|---|---|
| **Mô tả** | Không triển khai sàn e-commerce ở giai đoạn này. Vì đây là dự án **greenfield** (`CTX §4.1`), "giữ nguyên" nghĩa là **không có gì để giữ** — khách hàng/seller tiếp tục không có nền tảng giao dịch tập trung nào (không có quy trình thủ công đang chạy để so sánh, khác dự án loại "mở rộng") |
| **Chi phí 3 năm** | Không phát sinh chi phí xây dựng/vận hành kiến trúc. **Chi phí cơ hội không định lượng được ở lượt này** — `DRV-01` đã ghi rõ: không có luồng giao dịch ⇒ **0 giao dịch ghi nhận, toàn bộ mô hình kinh doanh marketplace bị chặn hoàn toàn**, đây là hệ quả định tính nghiêm trọng nhất trong toàn bộ `CTX`, dù không quy ra được một con số tiền cụ thể (không có doanh thu mục tiêu bằng số trong nguồn hiện có) |
| **Vì sao không chọn** | Vi phạm trực tiếp `DRV-01` (Must, blocker) — đây là driver mạnh nhất trong toàn bộ `CTX`. Giữ P0 làm mốc so sánh, không phải phương án khả thi |

### P1 — Modular microservices theo `SAD.md` v0.2 / hồ sơ thầu (điểm khởi đầu tham khảo, `DEC-04`)

| | |
|---|---|
| **Ý tưởng một câu** | ~10 service theo bounded-context, database-per-service, giao tiếp REST đồng bộ + Kafka/MSK bất đồng bộ cho chuỗi nghiệp vụ sau đặt hàng |
| **Thành phần chính** | Identity, Catalog & Inventory, Search (OpenSearch), Cart & Order (+ Dispute), Payment, Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment — mỗi service một RDS PostgreSQL Multi-AZ logic riêng, ElastiCache Redis dùng chung cho cache/session/giỏ hàng, Kafka/MSK là xương sống bất đồng bộ, ECS Fargate/EKS auto-scaling theo domain, CloudFront + WAF phía trước |
| **Mua gì / tự làm gì** | Toàn bộ business logic tự xây; hạ tầng dùng AWS managed service (RDS, MSK, ElastiCache, OpenSearch, ECS/EKS, CloudFront, WAF) — không mua phần mềm lõi thương mại nào |
| **Dữ liệu nằm ở đâu, ai sở hữu** | Mỗi service sở hữu schema/DB riêng (database-per-service) — không service nào truy cập trực tiếp DB service khác, chỉ qua API/event (`SAD.md §3.2`) |
| **Ai vận hành** | Đội DevOps/SRE phải vận hành ~10 service group riêng + 1 cụm Kafka/MSK + 1 cụm OpenSearch đa node — theo hồ sơ thầu, FTE DevOps trung bình toàn dự án chỉ **~4,92 MM/~7 tháng ≈ 0,7 FTE trung bình** (`estimate.computed.json.mmByRole.DEVOPS`), đỉnh điểm cao hơn ở WBS-01/02/03 |
| **Thời gian tới bản chạy được** | Riêng hạng mục nền tảng dịch vụ & event backbone (`WBS-03`, complexity **XL**, risk **high**) đã ước **52 MD + 18,2 MD dự phòng (35%) = 70,2 MD** chỉ để dựng xương sống, **trước khi** làm bất kỳ nghiệp vụ nào (nguồn: `estimate.computed.json`) |
| **Chi phí 3 năm (sơ bộ, số lượng thành phần — chưa quy đổi VND)** | ~10 RDS logic + 1 cụm MSK (Kafka) + 1 cụm OpenSearch đa node + ~10 ECS/EKS service group tự động mở rộng riêng — nhiều thành phần phải trả phí/quản lý độc lập nhất trong 3 phương án đã qua gate cứng. **8/8 khoản chi phí non-labor trong hồ sơ thầu đều `amount: null`** (`CON-01`) — không có số VND thật để so sánh, chỉ so sánh được số lượng/loại thành phần |
| **Rủi ro chính** | (a) Không có bằng chứng team từng vận hành Kafka/MSK, OpenSearch cluster, EKS trong production (`CTX §4.4`); (b) 4 đối tác tích hợp bên ngoài (VNPay/Momo/GHN/GHTK) chưa sandbox thật (`CTX §4.2`, độc lập với lựa chọn kiến trúc nội bộ nhưng số lượng service tăng số điểm tích hợp phải xử lý retry/idempotent riêng lẻ); (c) `WBS (42,48 MM) lệch 54,47% so với UCP (27,5 MM)` — cảnh báo tự động trong `estimate.computed.json.crosscheck` vượt ngưỡng 25%, dấu hiệu ước lượng effort chưa ổn định. *(Chưa lập `ARISK-nn` chính thức — thuộc Bước 5, ngoài phạm vi lượt chạy này; ba điểm trên là ứng viên trực tiếp)* |
| **Đảo ngược được không, tốn bao nhiêu** | Ranh giới service theo domain đã rõ — dễ **thay/rút bớt từng service riêng lẻ** về sau (ví dụ gộp Review vào Promotion nếu tải thấp) mà không phải viết lại toàn bộ; nhưng **gộp ngược lại thành ít service hơn** (nếu phát hiện team quá nhỏ để vận hành 10 service) tốn công tái cấu trúc network/DB đáng kể |

**Sơ đồ mức khối** *(C4 Context/Container — chỉ hộp lớn, chưa phải component; xem legend §3.3)*

```mermaid
flowchart LR
    subgraph P1["P1 — Modular microservices (~10 service, database-per-service)"]
        Client1["Web/Seller/Admin Clients"] -->|"1 · HTTPS REST, sync"| GW1["API Gateway / BFF"]
        GW1 -->|"2 · REST, sync"| SVC1["~10 bounded-context services\n(Identity, Catalog, Search, Cart&Order,\nPayment, Seller, Commission, Promo,\nReview, Notify, Shipping)"]
        SVC1 -->|"3 · publish, async"| MQ1[("Kafka / Amazon MSK")]
        MQ1 -->|"4 · consume, async"| SVC1
        SVC1 -->|"5 · SQL, sync"| DB1[("RDS PostgreSQL Multi-AZ\ndatabase-per-service, ~10 logic DB")]
        SVC1 -->|"6 · cache/session, sync"| CACHE1[("ElastiCache Redis")]
        SVC1 -->|"7 · index/query, sync"| SEARCH1[("OpenSearch, đa node")]
        SVC1 -->|"8 · REST/webhook, sync+async"| EXT1["VNPay · Momo · GHN · GHTK · Email/SMS"]
    end
```

### P2 — Modular monolith + managed AWS services, tách riêng Payment *(phương án đối trọng độc lập)*

| | |
|---|---|
| **Ý tưởng một câu** | Một (hoặc vài) deployable module hoá theo domain, chạy trên ECS Fargate với 2–3 nhóm service thay vì 10, dùng SQS/EventBridge thay Kafka/MSK, tách riêng duy nhất **Payment Service** để giữ ranh giới PCI-DSS |
| **Thành phần chính** | Modular monolith gồm module: Identity, Catalog & Inventory, Cart & Order (+ Dispute), Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment — chạy trong 2–3 nhóm ECS Fargate service (ví dụ: nhóm "giao dịch" Cart/Order/Catalog tách riêng để scale nhanh hơn nhóm "hỗ trợ" Seller/Promo/Review/Notify/Shipping); **Payment Service** tách hoàn toàn độc lập (network + IAM riêng) — bắt buộc theo `CON-06`, không phải tuỳ chọn |
| **Mua gì / tự làm gì** | Giống P1 về business logic tự xây; khác ở lựa chọn hạ tầng: SQS/EventBridge (không cần cụm Kafka tự quản lý), OpenSearch **hoãn** dùng managed service đa node ngay từ đầu — dùng Postgres full-text search cho giai đoạn đầu MVP, chuyển sang OpenSearch khi có bằng chứng cần (dựa `DRV-04` số liệu thật sau go-live) |
| **Dữ liệu nằm ở đâu, ai sở hữu** | 1 RDS PostgreSQL Multi-AZ chính, chia theo schema-per-module (ranh giới logic rõ ràng dù chung instance) — **trừ** Payment có RDS riêng nhỏ, tách biệt hoàn toàn khỏi cụm chính (không service khác truy cập trực tiếp) |
| **Ai vận hành** | Cùng team FTE như P1 (chưa có số thật khác biệt — cả hai phương án dùng chung giả định `DEC-02`), nhưng **số đơn vị triển khai cần vận hành/on-call giảm từ ~10 xuống ~3** (2–3 nhóm monolith + 1 Payment Service riêng) — khớp trực tiếp với FTE DevOps trung bình thấp (~0,7 FTE, nguồn giống P1) |
| **Thời gian tới bản chạy được** | Không cần hạng mục dựng "event backbone Kafka/MSK" (XL, 35% contingency) như P1 — SQS/EventBridge là managed service dùng ngay, giảm phần lớn effort tương ứng trong `WBS-03`; các hạng mục nghiệp vụ (WBS-18…43) không đổi giữa P1/P2 vì cùng phạm vi FR |
| **Chi phí 3 năm (sơ bộ, số lượng thành phần — chưa quy đổi VND)** | 1–2 RDS instance (thay vì ~10 logic DB cần theo dõi riêng) + SQS/EventBridge (không có cụm phải patch/scale thủ công như MSK) + Postgres FTS giai đoạn đầu (không cần cụm OpenSearch đa node ngay) + 2–3 ECS service group (thay vì ~10) — ít thành phần quản lý độc lập hơn hẳn P1. Cùng hạn chế: **8/8 khoản non-labor trong hồ sơ thầu `amount: null`** — không có số VND thật, chỉ so sánh số lượng/loại thành phần |
| **Rủi ro chính** | (a) SQS/EventBridge chưa được đo throughput thật cho tải đỉnh `DRV-04` — `ASM-07`; (b) 1 RDS chính cho nhiều module chưa đo tải ghi/đọc gộp — `ASM-08`; (c) cùng rủi ro đối tác bên ngoài 🔴 như P1 (`CTX §4.2`, không phụ thuộc kiến trúc nội bộ); (d) nếu traffic thật vượt xa dự kiến, tách Catalog/Search ra khỏi monolith muộn sẽ tốn hơn tách từ đầu (đánh đổi đã nêu ở §1). *(Chưa lập `ARISK-nn` chính thức — Bước 5)* |
| **Đảo ngược được không, tốn bao nhiêu** | Module hoá rõ theo domain trong code (namespace/package riêng biệt) giúp tách thành service riêng về sau **có kế hoạch** khi có bằng chứng tải thật cần (khác gộp ngược từ 10 service như P1) — nhưng tốn công tách hạ tầng (network, DB, CI/CD riêng) tại thời điểm tách, không miễn phí |

**Sơ đồ mức khối** *(C4 Context/Container — chỉ hộp lớn; xem legend §3.3)*

```mermaid
flowchart LR
    subgraph P2["P2 — Modular monolith + managed AWS, Payment tách riêng"]
        Client2["Web/Seller/Admin Clients"] -->|"1 · HTTPS REST, sync"| GW2["API Gateway / ALB"]
        GW2 -->|"2 · REST, sync"| MONO2["Modular monolith\n(Identity, Catalog, Cart&Order, Seller,\nCommission, Promo, Review, Notify, Shipping)\n2-3 nhóm ECS Fargate"]
        GW2 -->|"2b · REST, sync, cô lập mạng riêng"| PAY2["Payment Service\n(tách bắt buộc — CON-06 PCI-DSS SAQ A)"]
        MONO2 -->|"3 · publish, async"| BUS2[("SQS / EventBridge")]
        PAY2 -->|"3b · publish, async"| BUS2
        BUS2 -->|"4 · consume, async"| MONO2
        MONO2 -->|"5 · SQL, sync"| DB2[("RDS PostgreSQL Multi-AZ\n1 cụm chính, schema-per-module")]
        PAY2 -->|"5b · SQL, sync"| DBPAY2[("RDS riêng, nhỏ — chỉ Payment")]
        MONO2 -->|"6 · cache/session, sync"| CACHE2[("ElastiCache Redis")]
        MONO2 -->|"7 · index/query, sync"| SEARCH2[("Postgres full-text (giai đoạn đầu)\n→ OpenSearch khi có bằng chứng cần")]
        MONO2 -->|"8 · REST/webhook, sync+async"| EXT2["GHN · GHTK · Email/SMS"]
        PAY2 -->|"8b · REST/webhook, sync+async"| EXTPAY2["VNPay · Momo"]
    end
```

### 3.3 Legend cho cả hai sơ đồ P1/P2 *(bắt buộc theo `D4`)*

| Số | Loại mũi tên | Giao thức | Sync/Async | Ghi chú |
|---|---|---|---|---|
| 1 | Client → Gateway | HTTPS REST | Sync | Người dùng chờ phản hồi |
| 2 / 2b | Gateway → Service | REST (nội bộ) | Sync | 2b (P2): Payment nằm sau ranh giới mạng/IAM riêng, không chung network với monolith |
| 3 / 3b | Service → Message bus | Publish event | Async | Domain event (VD `OrderPlaced`) |
| 4 | Message bus → Service | Consume event | Async | Xử lý chuỗi sau đặt hàng (hoa hồng, payout, notify, loyalty) |
| 5 / 5b | Service → Database | SQL (JDBC/driver) | Sync | 5b (P2): Payment có RDS riêng, không service khác truy cập |
| 6 | Service → Cache | Redis protocol | Sync | Session, giỏ hàng, cache đọc |
| 7 | Service → Search | Query API | Sync | P1: OpenSearch ngay từ đầu · P2: Postgres FTS giai đoạn đầu |
| 8 / 8b | Service ↔ Đối tác ngoài | REST/webhook (theo `SAD.md §3.4`) | Sync (gọi) + Async (webhook/IPN) | Timeout/retry cụ thể: xem `CTX §4.2`, kế thừa `SAD.md §3.4` — **chưa kiểm chứng với sandbox thật** (🔴, `CON-04`) |

*C4 mức: **Container** (không phải Component) — mỗi hộp là một đơn vị triển khai/nhóm đơn vị
triển khai, chưa xuống tới class/module code. Không trộn mức.*

---

## 4. Bảng chấm điểm

*Thang 1–5. Chỉ chấm các phương án đã qua gate cứng §2.1 (P0, P1, P2). P3, P4 bị loại ở §5,
không chấm điểm đầy đủ.*

| Tiêu chí | Trọng số | P0 | P1 | P2 |
|---|---|---|---|---|
| 1. Đáp ứng `DRV` Must | 25% | 1 | 5 | 4 |
| 2. Chi phí 3 năm (sơ bộ) | 20% | 5 | 2 | 4 |
| 3. Thời gian tới bản chạy được | 15% | 5 | 2 | 4 |
| 4. Rủi ro kỹ thuật | 15% | 5 | 2 | 4 |
| 5. Năng lực team & vận hành (Conway) | 15% | 5 | 2 | 5 |
| 6. Khả năng tiến hoá | 10% | 1 | 4 | 3 |
| **Tổng có trọng số** | 100% | **3.60** | **2.95** | **4.05** |

**Lý do từng ô**

| Tiêu chí | P0 | P1 | P2 |
|---|---|---|---|
| 1. `DRV` Must | Không xây gì ⇒ vi phạm trực tiếp `DRV-01` (blocker) — điểm sàn | Đáp ứng đầy đủ nhất: scale-out **độc lập** Catalog/Search khỏi Checkout ngay từ đầu (`DRV-04`), event backbone tách chuỗi hoa hồng/payout khỏi luồng chính (`DRV-06`) | Đáp ứng phần lớn nhưng scale-out Catalog/Search **chưa độc lập** ở giai đoạn đầu (chung nhóm monolith) — thua P1 đúng một bậc, không giả vờ ngang bằng |
| 2. Chi phí (sơ bộ) | Không phát sinh chi phí hạ tầng | Nhiều thành phần managed độc lập nhất phải vận hành (~10 RDS logic + MSK + OpenSearch đa node + ~10 ECS group) — chi phí vận hành sơ bộ cao nhất trong 2 phương án đã qua gate | Ít thành phần hơn hẳn (1–2 RDS + SQS/EventBridge + Postgres FTS + 2–3 ECS group) — chi phí vận hành sơ bộ thấp hơn P1 |
| 3. Thời gian | Có ngay, 0 effort | `WBS-03` (dựng nền tảng dịch vụ & event backbone) một mình đã 70,2 MD (XL, +35% contingency) trước khi làm nghiệp vụ | Không cần dựng cụm Kafka/MSK — dùng managed service có sẵn ngay, effort nền tảng thấp hơn đáng kể so với P1 |
| 4. Rủi ro kỹ thuật | Không có rủi ro kỹ thuật (không xây) | Không có bằng chứng team từng vận hành Kafka/MSK, OpenSearch, EKS production (`CTX §4.4`); cảnh báo lệch WBS↔UCP 54,47% (`estimate.computed.json.crosscheck`) | Công nghệ managed phổ biến hơn (RDS, SQS/EventBridge, ECS Fargate) — rủi ro "công nghệ mới" thấp hơn; rủi ro đối tác bên ngoài 🔴 giữ nguyên như P1 (không đổi bởi kiến trúc nội bộ) |
| 5. Năng lực team (Conway) | Không cần team | ~10 service độc lập trong khi FTE BE trung bình toàn dự án chỉ **~18,31 MM/~7 tháng ≈ 2,6 FTE trung bình** (`estimate.computed.json.mmByRole.BE`) — mỗi kỹ sư BE ôm trung bình 3–4 service, vi phạm Conway rõ theo `DEC-02` | Số đơn vị triển khai cần vận hành giảm còn ~3 (2–3 nhóm monolith + Payment) — khớp với cùng FTE BE ~2,6 trung bình tốt hơn P1 |
| 6. Khả năng tiến hoá | Giữ nguyên = không tiến hoá được, mỗi ngày trì hoãn là một ngày mất cơ hội thị trường không thu hồi được | Ranh giới service đã tách sẵn — dễ thay/rút từng service riêng lẻ về sau | Module hoá trong code dễ tách dần khi có bằng chứng tải thật, nhưng tách hạ tầng lúc đó tốn công hơn P1 (đã tách sẵn) — thua P1 đúng ở tiêu chí này |

🔴 **Điểm tổng P1 (2.95) và P2 (4.05) chênh 1.10 — đủ phân biệt**, không rơi vào bẫy "chênh <0.3".
P0 (3.60) và P2 (4.05) chênh 0.45 — cũng đủ phân biệt, nhưng nhắc lại: **P0 vi phạm `DRV-01`
(Must, blocker)** nên dù điểm tổng gần P2, P0 **không phải lựa chọn khả thi** — đây là lý do
điểm P0 cao ở nhiều tiêu chí "chi phí/thời gian/rủi ro" (vì không làm gì thì các tiêu chí đó tự
nhiên thấp) nhưng lại thua tuyệt đối ở tiêu chí có trọng số cao nhất (Đáp ứng `DRV` Must, 25%).

---

## 5. Phương án bị loại và lý do *(bắt buộc — quy tắc `D3`)*

| Phương án | Đã cân nhắc vì | Loại vì | Gắn với | Điều kiện nào thì xét lại |
|---|---|---|---|---|
| **P3 — Mua/tích hợp nền tảng multi-vendor mã nguồn mở** (VD Medusa.js, Bagisto) + tuỳ biến tách đơn đa seller, hoa hồng/payout, KYC seller | Có thể giảm effort xây lõi catalog/cart/order từ đầu, tăng tốc thời gian ra bản chạy được — đúng như gợi ý cân nhắc trong ghi chú người duyệt | (a) Không có bằng chứng nền tảng ứng viên nào hỗ trợ sẵn mô hình hold 3–7 ngày + audit trail tài chính riêng theo đúng `DRV-06`/FR-21/22 — phải sửa lõi sâu, mất lợi thế "mua sẵn"; (b) **không kiểm chứng được cô lập Payment Service** cho PCI-DSS SAQ A nếu không sửa sâu lõi nền tảng — vi phạm `CON-06` (gate cứng §2.1); (c) chưa có bằng chứng năng lực team với stack cụ thể của nền tảng này (PHP/Laravel hay Node tuỳ nền tảng) — `ASM` mới, không phải số liệu đã có | `CON-06` (loại cứng), `CON-05` (rủi ro năng lực) | Nếu Tech Lead xác nhận có kinh nghiệm sâu với một nền tảng cụ thể **và** nền tảng đó chứng minh được (qua POC) khả năng cô lập Payment đúng yêu cầu SAQ A mà không sửa lõi — xét lại cho các module không nhạy cảm tài chính (VD Catalog/Review) |
| **P4 — Serverless-first** (Lambda + API Gateway + Step Functions + DynamoDB/Aurora Serverless, EventBridge cho toàn bộ luồng, không container) | Chi phí theo request, không cần quản lý cluster, scale tự động cho flash sale — đúng gợi ý cân nhắc trong ghi chú người duyệt | (a) Cold-start của Lambda cho luồng checkout đồng bộ có nguy cơ ảnh hưởng trải nghiệm ở đúng bước `DRV-02` (bỏ giỏ) — **chưa có POC đo cold-start trong ngữ cảnh VPC + kết nối RDS**; (b) chưa có bằng chứng năng lực team với serverless-at-scale (`CON-05`); (c) mô hình chi phí theo request khó ước lượng ở quy mô "hàng nghìn–chục nghìn concurrent user" (`DRV-04`) mà không có bài đo — rủi ro hoá đơn tăng phi tuyến (nguồn rủi ro "Chi phí", `SKILL.md` Bước 5) | `DRV-02`, `CON-05` | Nếu có POC đo cold-start đạt yêu cầu checkout và Tech Lead xác nhận năng lực serverless-at-scale — xét lại cho các luồng bất đồng bộ thuần (VD Notification, Commission batch) như một lựa chọn lai với P2, không nhất thiết toàn bộ hệ thống |

*"Team quen công nghệ X" là lý do hợp lệ — ở đây áp dụng ngược: P3/P4 bị loại một phần vì
**chưa có bằng chứng** team quen (`ASM` mới), không phải vì SA không thích công nghệ đó.*

---

## 6. Bảng đánh đổi trình PO

*Dịch lựa chọn kỹ thuật thành ngôn ngữ PO hiểu được — so sánh P1 và P2 (P0 đã loại ở §4 vì vi
phạm `DRV-01`).*

| Nếu chọn | Được | Mất | Tiền chênh 3 năm | Thời gian chênh |
|---|---|---|---|---|
| **P1** (giữ theo `SAD.md`/hồ sơ thầu) | Scale-out độc lập Catalog/Search khỏi Checkout **ngay từ đầu**; không cần thiết kế lại nếu traffic tăng nhanh hơn dự kiến | Rủi ro Conway cao với team hiện tại (mỗi BE ôm 3–4 service); effort dựng nền tảng lớn hơn; nhiều thành phần managed phải vận hành hơn (MSK, OpenSearch đa node) | **Chưa quy đổi VND** (`TCO` Bước 5) — sơ bộ **cao hơn P2** vì số lượng managed component nhiều hơn (8/8 khoản non-labor hồ sơ thầu đều chưa có số, không thể so tuyệt đối) | +70,2 MD riêng cho nền tảng event backbone (`WBS-03`) so với P2 không cần cụm Kafka/MSK riêng |
| **P2** (khuyến nghị SA) | Khớp Conway với team giả định `DEC-02`; thời gian tới bản chạy được nhanh hơn; ít managed component phải vận hành hơn | Scale-out độc lập Catalog/Search **kém hơn ngay từ đầu** — có thể phải tách service khi traffic thật vượt ngưỡng, tốn chi phí tái cấu trúc lúc đó (không miễn phí, không định lượng được ở lượt này) | **Chưa quy đổi VND** — sơ bộ **thấp hơn P1** | **-70,2 MD** so với P1 ở riêng hạng mục nền tảng; effort nghiệp vụ (WBS-18…43) không đổi giữa hai phương án |

---

## 7. Cắt gì thì giảm bao nhiêu

*Chưa áp dụng ở lượt chạy này.* `TCO` bằng VND thật (Bước 5) chưa tồn tại, và `CON-01` (ngân
sách) vẫn "Chưa xác định" (`OQ-005` còn mở) — không có số ngân sách đã duyệt để đối chiếu và đề
xuất cắt giảm có ý nghĩa. Mục này sẽ điền khi `TCO` (Bước 5) hoàn thành **và** `OQ-005` có câu
trả lời bằng số thật.

---

## 8. Giả định & Ngoài phạm vi

**Giả định** — `ASM-nn` ảnh hưởng tới lựa chọn này *(tiếp số từ `CTX §5`, bắt đầu `ASM-07`)*:

| ID | Giả định | Nếu sai thì phương án nào đổi |
|---|---|---|
| `ASM-07` | Amazon SQS/EventBridge (không phải Kafka/MSK) đủ đáp ứng thông lượng cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải đỉnh flash sale (`DRV-04`, "hàng nghìn–chục nghìn concurrent user") — **chưa có POC đo throughput thật trong ngữ cảnh này**. Cách xác minh: POC đo SQS FIFO/EventBridge với payload tương tự `OrderPlaced` ở tải giả lập tương ứng `DRV-04`. Chủ: Tech Lead. Hạn: trước khi chốt `ADR` message backbone ở GĐ2 | Nếu sai (không đủ throughput): P2 phải bổ sung Kafka/MSK riêng cho hot-path đặt hàng (kiến trúc lai P1+P2 cho riêng luồng này), không chuyển hẳn sang P1 vì phần còn lại của P1 vẫn vi phạm Conway |
| `ASM-08` | 1 cụm RDS PostgreSQL Multi-AZ chính (schema-per-module) đủ chịu tải ghi/đọc gộp cho toàn bộ module ngoại trừ Payment tách riêng — **chưa đo**. Cách xác minh: POC load test theo kịch bản `NFR-01`/`NFR-02`. Chủ: Tech Lead/DBA. Hạn: trước GĐ2 (`DAT`) | Nếu sai: phải tách read replica/DB riêng cho Catalog/Search sớm hơn dự kiến trong P2, tăng chi phí vận hành tiệm cận P1 cho phần đó |
| `ASM-09` | Bộ tiêu chí và trọng số ở §2.2 (mặc định từ template, chưa qua buổi duyệt riêng với PO/Tech Lead) phản ánh đúng ưu tiên thật của dự án — xem cảnh báo cuối §2.2 | Nếu PO tăng mạnh trọng số "Đáp ứng `DRV` Must", thứ hạng P1/P2 có thể đổi (P1 mạnh nhất ở tiêu chí này) — xem `OQ-011` |

*Giả định `ASM-01…06` của `CTX` (ngân sách, deadline, đội vận hành, residency, dùng `SAD.md` làm
điểm khởi đầu, hoá đơn điện tử hoãn) vẫn áp dụng nguyên trạng cho toàn bộ `OPT` — không lặp lại
nội dung ở đây, chỉ tham chiếu.*

**Ngoài phạm vi:**

- `TCO` bằng VND thật, 3 năm, ≥2 kịch bản tải — thuộc Bước 5, **chưa làm** ở lượt chạy này. Mọi
  con số "chi phí" trong tài liệu này là **số lượng/loại thành phần hạ tầng để so sánh tương
  đối**, không phải tiền.
- `ARISK` (sổ rủi ro kiến trúc chính thức) và kế hoạch POC có tiêu chí pass/fail viết trước —
  thuộc Bước 5, **chưa lập**. `ASM-07`/`ASM-08` ở trên là ứng viên trực tiếp để nâng thành
  `ARISK-nn` khi Bước 5 chạy.
- Thiết kế chi tiết ranh giới service/module (contract cụ thể, tên bảng, tên topic/queue) —
  thuộc GĐ2 (`SAD`, `ADR`), **không** được vẽ ở đây dù đã có gợi ý từ `SAD.md`/hồ sơ thầu.
- Quyết định cuối cùng chọn P1 hay P2 (hay phương án lai) — đây là khuyến nghị của SA, **chưa
  phải quyết định**; quyết định thật cần PO + Tech Lead ký (`OQ-011`).
- Đối chiếu chi tiết với `OQ-003` (giữ toàn sàn hay thu hẹp phạm vi) — cả ba phương án ở đây mô
  tả kiến trúc tổng thể toàn sàn theo phạm vi đã chốt của lượt chạy này; nếu `OQ-003` sau này
  quyết định thu hẹp, bảng chấm điểm có thể cần chấm lại với phạm vi hẹp hơn.

---

## 9. Open Questions

| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
|---|---|---|---|---|---|
| `OQ-010` | Tech Lead xác nhận: đội thi công **thật** (không phải đề xuất trong hồ sơ thầu) có kinh nghiệm vận hành production nào với Kafka/MSK, OpenSearch cluster, EKS chưa? Đây là input trực tiếp cho tiêu chí "Rủi ro kỹ thuật" đã chấm P1=2/P2=4 ở §4. | Tech Lead | 2026-09-12 | Điểm "Rủi ro kỹ thuật" của P1 trong `OPT`; `ARISK` Bước 5 | Nếu đội thật có kinh nghiệm Kafka/MSK/OpenSearch/EKS production: nâng điểm rủi ro kỹ thuật P1 lên 3–4, thu hẹp khoảng cách điểm tổng với P2 (từ 1.10 xuống có thể ~0.4–0.7) — vẫn cần xem lại tiêu chí "Năng lực team & vận hành" (Conway) vì đó không phụ thuộc kinh nghiệm công nghệ mà phụ thuộc **số người** so với **số service** |
| `OQ-011` | PO + Tech Lead chọn phương án nào giữa P1 (theo `SAD.md`/hồ sơ thầu hiện có) và P2 (khuyến nghị SA), hay yêu cầu SA dựng thêm phương án lai (VD P2 nhưng tách Catalog/Search từ đầu)? Đây chính là nội dung cần ký ở AG1 cho `OPT`. | PO + Tech Lead | 2026-09-12 | Ký AG1 cho `OPT`; bắt đầu Bước 5 (`TCO`/`ARISK`) theo đúng phương án đã chọn | Nếu chọn P1 dù rủi ro Conway cao: phải tăng team BE thật lên gần mức bid đề xuất (đỉnh điểm 10 người, chủ yếu BE) **hoặc** giảm số service xuống dưới 10 trước khi GĐ2 chốt ranh giới — nếu không, ranh giới service ở `SAD` GĐ2 sẽ vi phạm Conway ngay từ thiết kế, phát hiện muộn hơn và tốn hơn theo đúng cảnh báo của `GUIDE.md` |
| `OQ-012` | Có cần chạy POC đo throughput SQS/EventBridge (`ASM-07`) **trước khi** chốt P2 làm phương án chính thức, hay chấp nhận rủi ro tạm thời và bổ sung `ARISK` + kế hoạch POC ở Bước 5 rồi mới đo? | Tech Lead | 2026-09-12 | `ADR` message backbone ở GĐ2; kế hoạch POC ở `ARISK` Bước 5 | Nếu không đo trước khi chốt `ADR` GĐ2 mà đo sau mới phát hiện SQS/EventBridge không đủ throughput: phải viết lại `ADR` (Supersede) sau khi đã thiết kế chi tiết — tốn hơn phát hiện ở GĐ1 theo đúng nguyên tắc `workflow.md §6` "GĐ2 → GĐ1" |

---

## Tự chấm

### ① Bảng tự chấm Gate AG1 *(`workflow.md §2`, cập nhật từ `CTX`)*

| # | Tiêu chí | ☐/✅ | Ghi chú |
|---|---|---|---|
| 1 | `CTX` có `DRV-nn`, mỗi driver ghi rõ áp lực kinh doanh | ✅ | Không đổi — xem `CTX §2` |
| 2 | `CTX` có `CON-nn` (ràng buộc 6 nhóm) | ✅ *(với lưu ý)* | Không đổi — xem `CTX §3` |
| 3 | `CTX` mô tả hiện trạng as-is | ✅ *(với lưu ý)* | Không đổi — xem `CTX §4` |
| 4 | `OPT` có ≥2 phương án được chấm điểm, nêu rõ phương án bị loại + lý do | ✅ | **Mới đạt ở lượt này** — 3 phương án chấm điểm (P0, P1, P2) + 2 phương án bị loại có lý do gắn `CON`/`DRV` cụ thể (P3, P4). Trọng số tiêu chí **chưa qua buổi duyệt riêng với PO/Tech Lead** (`ASM-09`) — đây là hạn chế cần ghi nhận, không phải lý do đánh rớt tiêu chí này (tiêu chí AG1 chỉ đòi hỏi "có ≥2 phương án chấm điểm + nêu loại", không đòi hỏi trọng số đã duyệt) |
| 5 | `TCO` có chi phí 3 năm, ≥2 kịch bản tải | ☐ | **Chưa tạo file `TCO`** — thuộc Bước 5, ngoài phạm vi lượt chạy này. `OPT` chỉ so sánh số lượng/loại thành phần hạ tầng, không phải VND |
| 6 | `ARISK` có rủi ro cao kèm chủ + biện pháp | ☐ | **Chưa tạo file `ARISK`** — thuộc Bước 5. `ASM-07`/`ASM-08` ở §8 là ứng viên trực tiếp để nâng thành `ARISK-nn` |
| 7 | Rủi ro cao chưa chứng minh được có kế hoạch POC | ☐ | Phụ thuộc `ARISK`, chưa làm. `OQ-012` đã đặt câu hỏi về thời điểm chạy POC SQS/EventBridge |

**Kết luận tự chấm AG1:** **Vẫn chưa đủ điều kiện ký** — 4/7 tiêu chí ✅ (tăng từ 3/7 ở `CTX`).
Cần Bước 5 (`TCO`, `ARISK` + kế hoạch POC) trước khi PO + Tech Lead có thể ký AG1 đầy đủ. Ngay
cả khi ký AG1 chỉ dựa trên `OPT` này, **khuyến nghị không ký cho tới khi `OQ-005`/`OQ-006`/
`OQ-008`/`OQ-010`/`OQ-011` có câu trả lời** vì bảng chấm điểm ở đây dùng số liệu tham khảo hồ sơ
thầu (Draft), không phải số đã xác nhận.

### ② Checklist D1–D12 *(`design-rules.md`)*

| # | Mục | ☐/✅ | Ghi chú |
|---|---|---|---|
| D1 | Một ADR một quyết định | N/A | Tài liệu này không tạo `ADR` — quyết định kiến trúc chính thức (nếu có) sẽ thành `ADR` ở GĐ2 sau khi P1/P2 được PO/Tech Lead chọn |
| D2 | Không NFR định tính | N/A | `OPT` không chứa `QAS`; các con số hạ tầng dùng nguồn cụ thể (`estimate.computed.json`), không phải mô tả định tính |
| D3 | Nêu phương án bị loại + lý do gắn `CON`/`QAS` | ✅ | §5 — P3 loại vì `CON-06` (gate cứng); P4 loại vì `DRV-02`/`CON-05` (rủi ro + thiếu bằng chứng năng lực). Cả hai đều có điều kiện xét lại rõ ràng, không phải loại vĩnh viễn theo cảm tính |
| D4 | Sơ đồ khai báo mức C4 + legend | ✅ | P1/P2 đều khai báo "C4 mức Container", có bảng legend chung §3.3 giải thích từng loại mũi tên + sync/async |
| D5 | Interface có chủ/contract | N/A | Chưa tới `ICD` (GĐ2) — §3.4 `SAD.md` chỉ kế thừa nguyên trạng đề xuất, ghi rõ chưa xác minh sandbox thật (`CON-04`) |
| D6 | Phụ thuộc ngoài process có timeout/retry | N/A | Chưa tới `FAIL` (GĐ2); bảng legend §3.3 dòng 8/8b dẫn về `CTX §4.2`/`SAD.md §3.4` cho chi tiết timeout/retry hiện có (đề xuất, chưa kiểm chứng) |
| D7 | Một chủ sở hữu dữ liệu | ✅ *(ở mức khối)* | Cả P1 và P2 đều ghi rõ Payment có DB riêng, không service/module khác truy cập trực tiếp — chi tiết từng thực thể để `DAT` (GĐ2) |
| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` (GĐ3) |
| D9 | Con số hạ tầng quy ra tiền + nguồn; `INF` khớp `TCO` | 🟡 Một phần | Mọi con số hạ tầng ở đây có **nguồn** (`estimate.computed.json`, `SAD.md §3.1-3.4`) nhưng **chưa quy ra tiền** — đúng theo yêu cầu "chỉ mức sơ bộ để so sánh tương đối" của ghi chú người duyệt; quy đổi VND đầy đủ + khớp `TCO`/`INF` là việc của Bước 5/GĐ2 |
| D10 | Không quyết định thay người có thẩm quyền | ✅ | §1 ghi rõ "khuyến nghị… chưa phải quyết định"; mọi lựa chọn cuối (P1 vs P2, trọng số tiêu chí, thời điểm chạy POC) đều để `OQ-010/011/012` kèm hệ quả phương án ngược bằng số/định tính cụ thể, không tự quyết |
| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §8 đầy đủ — `ASM-07/08/09` mới, có cách xác minh/chủ/hạn; mục "Ngoài phạm vi" liệt kê rõ `TCO`/`ARISK`/thiết kế chi tiết GĐ2/quyết định cuối cùng đều chưa làm |
| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có ngay sau Change Log |

### ③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì

Ba câu hỏi mới của `OPT` (`OQ-010`, `OQ-011`, `OQ-012`) cộng với các câu hỏi còn mở từ `CTX`
(`OQ-001`, `OQ-002` *(đã đóng, xem `CTX`)*, `OQ-003`, `OQ-004`, `OQ-005`, `OQ-006`, `OQ-007`,
`OQ-008`) — xem sổ đầy đủ tại `00-index/OQ_e-commerce.md` (đã đồng bộ ở Change Log v1.5).
Ba câu quan trọng nhất cho việc ký AG1 của chính `OPT` này: **`OQ-011`** (chọn P1/P2 — chặn ký
AG1 trực tiếp), **`OQ-010`** (kinh nghiệm team thật — chặn độ tin cậy điểm "Rủi ro kỹ thuật"),
**`OQ-005`/`OQ-006`/`OQ-008`** (ngân sách/deadline/team thật — chặn `TCO`/`ARISK` Bước 5 có ý
nghĩa).

**Nhắc:** AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header file này) trước khi chạy
`/sa-2-architecture`. Cần chạy tiếp Bước 5 (`TCO`, `ARISK`) của `sa-1-context` trước khi bảng tự
chấm AG1 đạt đủ 7/7 tiêu chí.