Ra quyết định kỹ thuật & Quản trị kiến trúcTechnical Decision-Making & Architecture Governance

Thuộc bộ kiến thức Engineering Manager Roadmap.

Tổng quan

Đâu đó giữa vị trí senior engineer và engineering manager, có một sự chuyển dịch âm thầm xảy ra: bạn không còn là người hiểu sâu nhất về bất kỳ subsystem cụ thể nào trong phòng họp nữa, và bạn trở thành người chịu trách nhiệm đảm bảo cả phòng vẫn đi đến được một quyết định tốt dù không phải bạn là chuyên gia. Đây là một chuyển đổi khó chịu với nhiều manager đi lên từ công việc kỹ thuật hands-on, vì nó có thể cảm giác như mất đi quyền lực. Thực ra không phải vậy — đó là sự thay đổi về loại quyền lực bạn nắm giữ. Công việc của bạn không còn là có câu trả lời tốt nhất; nó là sở hữu quy trình để câu trả lời tốt nhất có thể được tìm ra, được quyết định, và được ghi nhớ lại.

Note này nói về quy trình đó: các quyết định kỹ thuật nên được đưa ra như thế nào trong một team hay tổ chức, cách phân biệt giữa các quyết định đáng để cân nhắc kỹ và các quyết định nên được chốt trong năm phút, cách ghi lại quyết định để lý do đằng sau nó tồn tại lâu hơn những người đã đưa ra nó, và cách thiết lập vừa đủ tiêu chuẩn hóa (standardization) để engineer có thể di chuyển linh hoạt giữa các hệ thống mà không quá cứng nhắc đến mức không ai chọn được công cụ phù hợp cho một bài toán thực tế. Note này không thay thế kiến thức architecture kỹ thuật chuyên sâu — phần đó xem tại ../backend/en/14-software-architecture.md cho các architectural style, pattern và tradeoff, và ../backend/en/06-apis.md cho chi tiết API design. Note này nằm ở một lớp cao hơn: nó nói về cách manager đảm bảo công việc architecture diễn ra, diễn ra với đúng người, và luôn trung thực với những gì business thực sự cần.

Kiến thức nền tảng

Vai trò của manager là sở hữu quy trình, không phải “biết tất cả về kỹ thuật”

Một failure mode phổ biến của manager mới là cố gắng vẫn là người có thẩm quyền kỹ thuật cao nhất cho mọi quyết định trong team mình, hoặc vì họ đã quen là người đó, hoặc vì họ không tin ai khác có thể đảm nhận vai trò này. Cách này không scale được khi team lớn hơn vài người, và nó thực sự gây hại cho sự phát triển của team — nếu manager luôn có tiếng nói kỹ thuật cuối cùng, các senior engineer sẽ ngừng phát triển judgment và ngừng cố gắng xây dựng luận điểm mạnh mẽ, vì họ biết quyết định thực ra không phải của họ.

Mô hình lành mạnh hơn: công việc của manager là đảm bảo người gần nhất với vấn đề có đủ context, đủ mandate (thẩm quyền), và đủ áp lực để đưa ra một quyết định có lý lẽ vững — và quyết định đó thực sự được chốt trong một khoảng thời gian giới hạn. Cụ thể, điều đó có nghĩa là:

• Đảm bảo đúng người có mặt trong phòng — không phải tất cả mọi người, và không phải chỉ người nói to nhất.
• Đảm bảo các tradeoff thực sự được nêu ra rõ ràng thay vì để ngầm hiểu (chi phí, latency, quyền sở hữu team, khó khăn khi migration, thời gian ra thị trường).
• Đảm bảo ý kiến trái chiều được lắng nghe trước khi quyết định, không phải tranh cãi lại sau khi đã quyết.
• Đảm bảo có người thực sự chịu trách nhiệm chốt quyết định, thay vì để nó ở trạng thái “vẫn đang thảo luận” mãi mãi.
• Đảm bảo quyết định và lý do đằng sau nó được viết ra ở đâu đó lâu bền.

Bạn là người nhận ra khi một cuộc tranh luận đã ngừng đưa ra thông tin mới mà chỉ lặp lại các lập trường cũ — và là người có đủ vị thế để nói “chúng ta có đủ thông tin để quyết rồi, quyết đi.”

Decision paralysis và unilateral decision là hai mặt của cùng một vấn đề

Các team có xu hướng thất bại theo một trong hai hướng cực đoan:

Tê liệt vì đồng thuận (paralysis by consensus): mọi lựa chọn architecture đều bị đem ra tranh luận lại trong một cuộc họp với quá nhiều stakeholder, không ai sở hữu kết quả, và “quyết định” thực ra chỉ là một cuộc trò chuyện không đi đến đâu rồi lại được bàn tiếp ở sprint sau. Việc này đốt hàng tuần cho những thứ không xứng đáng, và nó dạy cho engineer rằng đưa ra một ý kiến mạnh là cách tốt để trì hoãn quyết định vô thời hạn.

Quyết định đơn phương bỏ qua chuyên môn (unilateral decisions): một manager, tech lead, hoặc senior IC tự quyết một mình, không tham khảo những người sẽ phải gánh hậu quả (on-call, team duy trì downstream service, security) — và quyết định hóa ra sai theo cách mà một cuộc trò chuyện năm phút lẽ ra đã phát hiện được. Việc này thường được biện minh là “để đi nhanh hơn,” nhưng thực ra nó chỉ đẩy chi phí xuống downstream và tạo thêm một khoản “thuế niềm tin” cho lần tiếp theo người đó ra quyết định.

Cả hai failure mode đều xuất phát từ cùng một mảnh ghép còn thiếu: không ai định nghĩa rõ ràng ai là người quyết, ai bắt buộc phải được tham khảo, và ai chỉ cần được thông báo. Giải quyết việc này bằng một framework nhẹ nhàng xử lý được cả hai vấn đề cùng lúc — nó giới hạn cuộc thảo luận (để không trở thành tê liệt) trong khi vẫn yêu cầu đúng chuyên môn được tham khảo (để không trở thành quyết định đơn phương bỏ qua expertise).

Khái niệm chính

DACI và RACI: gọi tên ai là người quyết

Thói quen có đòn bẩy cao nhất một manager có thể cài đặt là: gọi tên, trước khi cuộc tranh luận bắt đầu, ai thực sự là người cầm bút quyết định. Hai framework phổ biến:

DACI (Driver, Approver, Contributors, Informed) hướng đến một quyết định cụ thể:

Vai trò	Ý nghĩa
Driver	Sở hữu việc thúc đẩy quyết định tiến lên: thu thập input, định hình các phương án, đẩy nó đến khi chốt xong. Thường là tech lead hoặc senior engineer, không nhất thiết là manager.
Approver	Người (đôi khi hơn một người, tốt nhất không quá hai) có quyền phê duyệt cuối cùng. Mọi người cần biết trước ai là người này.
Contributors	Những người có chuyên môn hoặc có liên quan đến kết quả nên bắt buộc phải được tham khảo trước khi quyết định — engineer on-call, người review security, team sở hữu downstream dependency.
Informed	Những người cần biết kết quả nhưng không có quyền góp ý vào nó — họ được thông báo sau khi quyết định đã chốt, không phải trong lúc bàn.

RACI (Responsible, Accountable, Consulted, Informed) là phiên bản tổng quát hơn, thường dùng cho việc sở hữu công việc liên tục thay vì một quyết định đơn lẻ, và phân biệt “ai làm việc” (Responsible) với “ai chịu trách nhiệm cuối cùng” (Accountable) — một sự phân biệt mà DACI gộp chung vào Driver/Approver.

Với một quyết định architecture đơn lẻ, DACI thường phù hợp hơn vì nó có hình dạng của một quyết định chứ không phải của quyền sở hữu công việc. Việc của manager hiếm khi là làm Driver hay Approver — mà là đảm bảo các vai trò đó được gán trước khi cuộc tranh luận bắt đầu, công khai, để không ai bối rối giữa chừng về việc ý kiến phản đối của mình là một veto hay chỉ là một input.

Quyết định có thể đảo ngược (“cửa hai chiều”) vs. không thể đảo ngược (“cửa một chiều”)

Không phải quyết định kỹ thuật nào cũng xứng đáng với cùng một mức độ quy trình, và áp dụng quy trình nặng nề cho một quyết định nhẹ chính là một thất bại quản lý — nó dạy engineer coi quy trình là ma sát thay vì là sự bảo vệ. Lăng kính rõ ràng nhất để hiệu chỉnh mức độ quy trình là cách Jeff Bezos phân biệt giữa cửa một chiều (one-way door) và cửa hai chiều (two-way door):

• Quyết định cửa hai chiều rẻ để đảo ngược. Nếu hóa ra sai, bạn có thể quay lại qua cánh cửa đó: đổi config, rollback deploy, đổi thư viện, revert feature flag. Những quyết định này nên được đưa ra nhanh, bởi người gần nhất với công việc, không cần triệu tập hội đồng review.
• Quyết định cửa một chiều tốn kém hoặc bất khả thi để đảo ngược mà không trả giá lớn: công nghệ database mà toàn bộ hệ thống sẽ được xây dựng xung quanh, một public API contract mà khách hàng bên ngoài phụ thuộc vào, một data model chạm đến mọi downstream service, một cam kết vendor lock-in, một lựa chọn security architecture định hình compliance posture trong nhiều năm. Những quyết định này xứng đáng được cân nhắc thật sự — đúng Contributors được tham khảo, các phương án thay thế được xem xét nghiêm túc, và một bản ghi lại lý do.

Công việc thực tế của manager là giúp team phân loại đúng họ đang đứng trước loại cửa nào trước khi quyết định áp dụng bao nhiêu quy trình — vì phân loại sai một cửa một chiều thành có thể đảo ngược là cách các team mắc kẹt trong một architecture mà không ai từng cân nhắc kỹ, còn phân loại sai một cửa hai chiều thành không thể đảo ngược là cách các team giậm chân tại chỗ vì những quyết định không đáng để tốn công như vậy.

Architecture Decision Records (ADR)

ADR là một tài liệu ngắn ghi lại một quyết định architecture có ý nghĩa quan trọng: đã quyết định gì, tại sao, những phương án thay thế nào đã được xem xét, và hậu quả kỳ vọng (bao gồm cả mặt trái) là gì. Điểm mấu chốt của ADR không phải là “cái gì” — thường cái đó đã hiện diện trong code hoặc trong hệ thống — mà là tại sao. Sáu tháng hay hai năm sau, khi có ai đó (có thể là chính engineer đó, nhưng thường là người mới) nhìn vào một lựa chọn thiết kế kỳ lạ và tự hỏi “tại sao mình lại làm thế này,” ADR chính là artifact trả lời câu hỏi đó thay vì bắt người ta phải khảo cổ qua các Slack thread cũ và PR đã đóng.

ADR bắt nguồn từ bài viết năm 2011 của Michael Nygard và từ đó đã trở thành một chuẩn de facto trong ngành, với một template được sử dụng rộng rãi duy trì tại adr GitHub organization.

Ví dụ template ADR

# ADR-0012: Sử dụng PostgreSQL làm datastore chính cho Orders service

## Status
Accepted (2026-03-14)
<!-- Các giá trị có thể: Proposed, Accepted, Rejected, Deprecated, Superseded by ADR-00XX -->

## Context
Orders service hiện đang lưu order state trong một in-memory store được backup
bằng snapshot định kỳ lên S3, kế thừa từ bản prototype ban đầu. Khi order volume
đã vượt 50k đơn/ngày, chúng ta bắt đầu mất dữ liệu khi pod restart giữa các
snapshot, và không có khả năng chạy query ad-hoc cho support và analytics mà
không phải replay snapshot vào một môi trường riêng.

Chúng ta cần một persistence layer:
- Đảm bảo durability theo từng write, không phải theo chu kỳ snapshot
- Hỗ trợ transactional consistency giữa một order và các line item của nó
- Cho phép team support chạy read query mà không cần engineering can thiệp
- Có thể vận hành được bởi team hiện tại mà không cần tuyển DBA chuyên biệt

Các phương án đã xem xét: PostgreSQL (RDS), DynamoDB, MongoDB Atlas, giữ nguyên
cách snapshot hiện tại với chu kỳ ngắn hơn.

## Decision
Chúng ta sẽ dùng PostgreSQL, host trên Amazon RDS với Multi-AZ bật, làm datastore
chính cho Orders service.

Lý do:
- Transactional guarantee ánh xạ trực tiếp vào yêu cầu consistency giữa
  order/line-item mà không cần thêm logic compensation ở tầng application.
- Team đã có kinh nghiệm vận hành PostgreSQL sâu từ Billing service; không cần
  bộ kỹ năng vận hành mới.
- DynamoDB bị loại: các access pattern cho query support/analytics quá ad-hoc và
  đang thay đổi để cam kết vào yêu cầu thiết kế key ngay từ đầu của DynamoDB.
- MongoDB Atlas bị loại: không có lợi thế đáng kể nào so với PostgreSQL cho
  workload này, và sẽ tạo thêm gánh nặng vận hành document-store thứ hai bên
  cạnh các hệ thống relational hiện có.
- Rút ngắn chu kỳ snapshot bị loại vì đây chỉ là giải pháp tạm không giải quyết
  được vấn đề durability hay khả năng query, chỉ thu hẹp cửa sổ lỗi.

## Consequences
Tích cực:
- Durability theo từng write; không còn mất dữ liệu theo cửa sổ snapshot.
- Query ad-hoc trên read replica, không cần engineering can thiệp.
- Tái sử dụng runbook vận hành và kinh nghiệm on-call sẵn có từ Billing.

Tiêu cực / rủi ro:
- Thêm một stateful dependency mới cần vận hành và backup cho service này.
- Schema migration giờ cần kỷ luật tương tự (backward-compatible, được review)
  như Billing đã áp dụng — team này chưa từng làm việc này và sẽ cần thời gian
  ramp-up.
- Khả năng scale write theo chiều ngang bị giới hạn bởi một primary duy nhất;
  nếu order volume tăng gấp 10 lần, chúng ta có thể cần xem xét lại (sharding,
  hoặc một write path dựa trên queue).

## Related
- Supersedes: none
- Related to: ADR-0009 (thiết lập PostgreSQL cho Billing service, được dùng lại
  làm template vận hành)

Khi nào nên viết ADR — và khi nào là thừa thãi

Hãy viết ADR khi quyết định thực sự là một cửa một chiều, hoặc gần như vậy: lựa chọn core data store, thay đổi một public API contract, áp dụng một architectural pattern mới (chuyển sang event-driven, đưa vào service mesh), một lựa chọn thiết kế liên quan đến security hoặc compliance, hoặc bất cứ điều gì mà một engineer mới sau một năm nữa sẽ hợp lý khi hỏi “tại sao lại xây theo cách này?”

Đừng viết ADR cho các lựa chọn có thể đảo ngược, ít rủi ro — dùng linter config nào trong một service riêng lẻ, chọn thư viện utility nào trong hai thư viện tương đương, quy ước đặt tên cho một module đơn lẻ. Ép buộc viết ADR cho mọi quyết định làm mất giá trị của những ADR thực sự quan trọng; nếu engineer phải viết ADR cho những lựa chọn nhỏ nhặt, họ sẽ hoặc ngừng viết hoàn toàn hoặc biến nó thành một nghi thức vô nghĩa. Một heuristic hợp lý: nếu việc đảo ngược quyết định sau này sẽ tốn hơn một ngày công hoặc ảnh hưởng đến team khác, nó có lẽ xứng đáng có một ADR.

Tài liệu architecture luôn phản ánh đúng thực tế

Sơ đồ architecture xuống cấp nhanh hơn hầu như bất kỳ artifact nào khác trong codebase, vì không giống code, không có gì bắt buộc nó phải đồng bộ với thực tế — một sơ đồ không làm build fail khi hệ thống nó mô tả thay đổi bên dưới. Một sơ đồ từ design doc viết hai năm trước, thể hiện một architecture “kỳ vọng” mà sau đó bị đơn giản hóa dưới áp lực deadline, còn tệ hơn cả việc không có sơ đồ nào: nó chủ động đánh lừa bất kỳ ai tin tưởng nó, và làm giảm niềm tin vào mọi sơ đồ khác trên cùng wiki.

Một mô hình tư duy hữu ích để giữ tài liệu architecture vừa đầy đủ vừa trung thực là mô hình C4 (Context, Containers, Components, Code), cấu trúc tài liệu thành bốn mức zoom:

Mức	Thể hiện	Đối tượng
Context	Hệ thống như một khối duy nhất, người dùng của nó, và các hệ thống khác nó giao tiếp	Bất kỳ ai, kể cả stakeholder không kỹ thuật
Containers	Các đơn vị deploy chính bên trong hệ thống (service, database, web app) và cách chúng giao tiếp	Engineer ở các team khác nhau, người mới
Components	Các khối cấu trúc chính bên trong một container	Engineer làm việc trong container đó
Code	Chi tiết mức class/module (thường để cho chính code, hoặc sơ đồ tự sinh)	Engineer đang trực tiếp sửa code đó

Điều manager thực sự quan tâm ở đây không phải là vẽ sơ đồ — mà là biến mức Context và Container thành một artifact sống thay vì một deliverable làm một lần: được review với nhịp độ nhẹ nhàng (ví dụ mỗi quý, hoặc bất cứ khi nào một ADR thay đổi topology), được sở hữu bởi một người hoặc team cụ thể thay vì “ai viết ban đầu,” và được coi là không đáng tin và gắn cờ cần cập nhật ngay khi ai đó nhận ra nó không khớp thực tế. Một sơ đồ có ngày “last verified” hiển thị rõ ràng hữu ích hơn nhiều so với một sơ đồ được vẽ đẹp mà không ai nhìn đến trong một năm.

Vai trò giám sát của manager trong architecture review

Bạn không được kỳ vọng là chuyên gia architecture sâu nhất trong phòng — phần đó được nói ở ../backend/en/14-software-architecture.md, và đó là việc của senior engineer, staff engineer, và architect để mang đến chiều sâu đó. Điều bạn sở hữu là đảm bảo review thực sự diễn ra vào đúng thời điểm (trước khi đầu tư đáng kể, không phải như một con dấu cao su sau khi hệ thống đã xây dựng nửa chừng), đảm bảo nó bao gồm đúng Contributors dưới một phân công kiểu DACI, và — đây là phần thực sự thuộc về bạn — đảm bảo cuộc thảo luận luôn bám vào mục tiêu business thay vì trôi dạt sang sự tinh tế kỹ thuật vì chính nó.

Hoàn toàn có thể xảy ra việc một phòng đầy các engineer giỏi hội tụ vào một giải pháp architecture đẹp về mặt kỹ thuật nhưng sai đối với business: over-engineer so với quy mô thực tế sản phẩm sẽ đạt trong hai năm tới, tối ưu cho một sự linh hoạt mà sản phẩm sẽ không bao giờ cần, hoặc tốn thời gian xây dựng không tương xứng với doanh thu hoặc rủi ro mà nó giải quyết. Một phần công việc của bạn trong các review này là liên tục đặt các câu hỏi neo giữ: giải pháp này giải quyết vấn đề business nào, chi phí của việc làm cái đơn giản hơn thay vào đó là bao nhiêu, chuyện gì xảy ra nếu chúng ta sai về giả định tăng trưởng đang thúc đẩy thiết kế này? Bạn không cần biết công nghệ sâu như engineer của mình để đặt những câu hỏi tốt như vậy — bạn cần biết business và các ràng buộc của team rõ hơn bất kỳ ai khác trong phòng, và đó chính xác là sự bất đối xứng khiến sự hiện diện của bạn trong review có giá trị thay vì thừa thãi.

Technical standards: tradeoff giữa tiêu chuẩn hóa và linh hoạt

Mọi tổ chức cuối cùng đều phải quyết định mức độ tiêu chuẩn hóa: một ngôn ngữ được chấp thuận duy nhất hay để team tự chọn, một linter và style guide bắt buộc ở mọi nơi hay style riêng theo team, một danh sách infrastructure/service được duyệt hay tự do lựa chọn, một API framework duy nhất hay bất cứ thứ gì team muốn dùng.

Standardization mang lại lợi ích thực sự, tích lũy theo thời gian: engineer có thể chuyển giữa các team mà không tốn chi phí ramp-up, code review dễ dàng hơn đáng kể vì reviewer đã quen với idiom, incident response nhanh hơn vì engineer on-call nhận ra được hình dạng của bất kỳ service nào mình bị page vào, và tổ chức có thể đầu tư tập trung vào tooling (CI template dùng chung, thư viện dùng chung, dashboard dùng chung) thay vì mỗi team tự phát minh lại. Chi phí cũng có thật: một tiêu chuẩn đúng với nhu cầu tổ chức ba năm trước có thể trở thành một chiếc áo bó cho một team đang giải quyết một bài toán thực sự khác biệt, và over-standardization gửi tín hiệu (đúng đắn) đến senior engineer rằng judgment của họ không được tin tưởng.

Giải pháp thực tế mà hầu hết tổ chức lành mạnh áp dụng là một mô hình phân tầng:

Tầng	Ví dụ	Cách tiếp cận tiêu chuẩn hóa
Nền tảng / blast-radius cao	Version control, nền tảng CI/CD, core auth/identity, cloud provider chính	Bắt buộc toàn tổ chức; sai lệch cần escalation và một lý do thuyết phục
Dùng chung nhưng có thể thương lượng	Ngôn ngữ/runtime, họ datastore chính, API framework	Một danh sách được duyệt ngắn (2-3 lựa chọn), không phải một lựa chọn bắt buộc duy nhất; lựa chọn mới đi qua một review nặng như ADR
Cấp team	Thư viện nội bộ, cấu trúc project, các lựa chọn tooling không quan trọng, tinh chỉnh rule linter trong một baseline chung	Team tự quyết, miễn không tạo gánh nặng vận hành lên team khác

Công việc của manager là giữ cho phân tầng này rõ ràng và được xem xét lại — các tiêu chuẩn chưa từng được viết ra sẽ bị thực thi không nhất quán và gây khó chịu, còn các tiêu chuẩn đã viết ra nhưng không bao giờ được xem xét lại sẽ trở thành vấn đề sơ đồ architecture hai năm tuổi y hệt, chỉ là cho tooling thay vì cho hệ thống.

Chiến lược API ở cấp tổ chức

Internal API xứng đáng nhận cùng một tư duy quản trị như tech stack, và các pattern kỹ thuật sâu cho chính API design — REST vs RPC vs GraphQL, phương án versioning, pagination, định dạng error — được nói ở ../backend/en/06-apis.md. Ở cấp tổ chức, các câu hỏi liên quan đến manager lại khác: ai được phép dựng lên một internal API surface mới, chính sách versioning và deprecation nào là bắt buộc với bất kỳ ai expose một API mà team khác phụ thuộc vào, và — đòn bẩy lớn nhất — khi nào tổ chức bắt buộc dùng một shared API platform/gateway thay vì để mỗi team tự xây và expose API riêng.

Một shared platform (một API gateway chung, một pipeline sinh SDK nội bộ dùng chung, một schema registry bắt buộc) có lời một khi bạn có đủ số internal consumer để các quy ước không nhất quán giữa các team bắt đầu tạo ra chi phí tích hợp thực sự — mỗi team tiêu thụ phải học một auth pattern khác, một pagination convention khác, một error shape khác. Nó thường không đáng để bắt buộc với chỉ vài service ít internal consumer; overhead phối hợp của một shared platform có thể vượt quá chi phí không nhất quán mà nó nhằm ngăn chặn. Một dấu hiệu hợp lý để xem xét lại điều này với vai trò manager: khi bạn nhận thấy hơn một team đang xây các client wrapper riêng chỉ để chuẩn hóa lại sự không nhất quán giữa hai internal API của chính bạn, đó thường là dấu hiệu cho thấy khoản đầu tư vào platform đã trở nên đáng giá.

Dù tổ chức chọn hướng nào, có một thứ gần như luôn đáng để bắt buộc bất kể quy mô: một chính sách deprecation được nêu rõ cho bất kỳ API nào mà team khác phụ thuộc vào. “Bạn có thể thay đổi cái này, nhưng phải version nó và cho consumer N tuần thông báo trước khi gỡ bỏ phiên bản cũ” rẻ để viết ra và đắt để bỏ qua một khi breaking change đầu tiên được ship mà không cảnh báo và làm sập production của một team downstream.

Best Practices

Hiệu chỉnh mức độ quy trình theo loại cửa, không theo chức danh của người quyết

Failure mode phổ biến nhất trong quản trị là áp dụng quy trình cấp ủy ban cho một quyết định thực ra là cửa hai chiều, hoặc để một cửa một chiều bị quyết định trong một cuộc trò chuyện hành lang vì người quyết đủ senior nên không ai nghĩ đến việc kiểm tra lại. Trước khi cuộc tranh luận về quyết định bắt đầu, hãy hỏi rõ ràng thành lời: “nếu điều này hóa ra sai, việc đảo ngược nó tốn kém đến mức nào?” Chỉ một câu hỏi đó, được hỏi nhất quán, làm được nhiều hơn bất kỳ framework nào trong việc định cỡ đúng quy trình quyết định của tổ chức bạn.

Gán vai trò DACI trước cuộc tranh luận, không phải sau

Nếu một cuộc họp quyết định bắt đầu mà không có Driver và Approver được thống nhất, cuộc thảo luận sẽ hoặc kéo dài quá điểm có thông tin mới hữu ích, hoặc bị quyết định không chính thức bởi người senior nhất trong phòng — đó là một quyết định đơn phương khoác áo một cuộc họp nhóm. Gọi tên vai trò trong lời mời họp hoặc phần đầu tài liệu, trước khi mọi người bắt đầu tranh luận lập trường, tránh được cả hai failure mode.

Viết ADR khi context còn tươi mới, không phải nhiều tháng sau

ADR viết ngay tại thời điểm nắm bắt được các phương án thực sự đã được xem xét và loại bỏ, kể cả những phương án có vẻ hợp lý vào lúc đó. ADR viết hồi cứu, sau khi có ai đó hỏi “tại sao chúng ta làm thế này,” có xu hướng hợp lý hóa lựa chọn hiện tại thay vì ghi lại trung thực các tradeoff đã được cân nhắc — giá trị của artifact phần lớn bị mất đi.

Biến architecture review thành một cổng chắn, không phải một thủ tục hình thức

Nếu review chỉ diễn ra sau khi hệ thống đã được xây xong, nó không còn là một điểm quyết định nữa mà trở thành một ô cần tick trước khi merge. Lên lịch review vào thời điểm mà việc đổi hướng vẫn còn rẻ — sau design doc, trước khi đầu tư triển khai đáng kể — và trao cho Approver quyền thực sự để trả lại thiết kế, không chỉ để đóng dấu chấp thuận.

Xem xét lại tiêu chuẩn theo nhịp độ định kỳ, đừng chỉ thiết lập rồi bỏ quên

Một danh sách tech stack được duyệt hoặc style guide chưa được xem xét lại trong hai năm sẽ tích lũy các ngoại lệ âm thầm mà mọi người lặng lẽ lách qua, điều này còn tệ hơn cả không có tiêu chuẩn nào — nó tạo ảo tưởng về sự nhất quán trong khi sự nhất quán đã xói mòn từ lâu. Đặt một lịch review định kỳ, nhẹ nhàng (dù chỉ một hoặc hai lần một năm) thay vì chỉ xem xét lại tiêu chuẩn một cách phản ứng khi có ai đó phàn nàn.

Giữ sơ đồ Context và Container của C4 luôn cập nhật, coi sơ đồ Component/Code là có thể bỏ đi

Cố gắng giữ mọi mức sơ đồ architecture đồng bộ hoàn hảo với code là một trận chiến không thể thắng và thường không đáng công sức ở mức Component và Code, vốn thay đổi quá thường xuyên. Tập trung công sức bảo trì vào mức Context và Container, vốn ít thay đổi và là những mức mà người mới và người cộng tác liên team thực sự cần.

Phân biệt “tôi không được tham khảo” với “tôi không có quyền veto”

Khi input của một Contributor không được làm theo, họ vẫn nên cảm thấy input của mình đã được lắng nghe và cân nhắc thực sự — kể cả khi Approver cuối cùng chọn hướng khác. Đánh mất sự phân biệt này (cảm thấy bị bỏ qua so với cảm thấy bị gạt bỏ) là điều biến một quy trình DACI lành mạnh thành nguồn gốc của sự bất mãn âm thầm, và cuối cùng, sự thờ ơ với các cuộc thảo luận architecture trong tương lai.

Để biết các quyết định quản trị architecture này liên hệ thế nào với việc quản lý liên tục technical debt, deprecation, và tradeoff rủi ro theo thời gian, xem ./10-technical-roadmap-debt-and-risk.md.

Tài liệu tham khảo

• Michael Nygard, “Documenting Architecture Decisions” — đề xuất ADR gốc.
• joelparkerhenderson/architecture-decision-record — bộ sưu tập template và ví dụ ADR được sử dụng rộng rãi.
• Martin Fowler, “Architecture Decision Records”
• Martin Fowler, “Who Needs an Architect?”
• Mô hình C4 để trực quan hóa software architecture: c4model.com
• Amazon, “Are you a one-way or two-way door decision maker?” — nguồn gốc của cách phân biệt quyết định có thể đảo ngược/không thể đảo ngược.
• Atlassian, “DACI decision-making framework”
• ../backend/en/14-software-architecture.md — các pattern và style architecture kỹ thuật chuyên sâu.
• ../backend/en/06-apis.md — chi tiết API design được tham chiếu ở phần chiến lược API phía trên.

# ADR-0012: Use PostgreSQL as the primary datastore for the Orders service

## Status
Accepted (2026-03-14)
<!-- Possible values: Proposed, Accepted, Rejected, Deprecated, Superseded by ADR-00XX -->

## Context
The Orders service currently persists order state in an in-memory store backed by
scheduled snapshots to S3, inherited from the original prototype. As order volume
has grown past 50k orders/day, we're seeing data loss on pod restarts between
snapshots, and we have no ability to run ad-hoc queries for support and analytics
without replaying snapshots into a separate environment.

We need a persistence layer that:
- Guarantees durability per-write, not per-snapshot-interval
- Supports transactional consistency across an order and its line items
- Allows the support team to run read queries without engineering involvement
- Can be operated by our current team without hiring specialized DBAs

Candidates considered: PostgreSQL (RDS), DynamoDB, MongoDB Atlas, keeping the
current snapshot approach with a shorter interval.

## Decision
We will use PostgreSQL, hosted on Amazon RDS with Multi-AZ enabled, as the primary
datastore for the Orders service.

Rationale:
- Transactional guarantees map directly onto the order/line-item consistency
  requirement without extra application-level compensation logic.
- The team already has deep operational PostgreSQL experience from the Billing
  service; no new operational skill set is required.
- DynamoDB was rejected: the access patterns for support/analytics queries are
  too ad hoc and evolving to commit to DynamoDB's upfront key-design requirement.
- MongoDB Atlas was rejected: no meaningful advantage over PostgreSQL for this
  workload, and it would introduce a second document-store operational burden
  alongside our existing relational systems.
- Shortening the snapshot interval was rejected as a stopgap that doesn't solve
  the durability or queryability problems, only shrinks the failure window.

## Consequences
Positive:
- Per-write durability; no more snapshot-window data loss.
- Ad hoc read queries against a read replica, without engineering involvement.
- Reuses existing operational runbooks and on-call expertise from Billing.

Negative / risks:
- Introduces a new stateful dependency to operate and back up for this service.
- Schema migrations now require the same discipline (backward-compatible,
  reviewed) as Billing already applies — this team hasn't done that before and
  will need ramp-up.
- Horizontal write scaling is bounded by a single primary; if order volume grows
  10x we will likely need to revisit (sharding, or a queue-backed write path).

## Related
- Supersedes: none
- Related to: ADR-0009 (Billing service PostgreSQL setup, reused as an
  operational template)