Architecture on Thanh HV's Blog

Chương 16: Anti-patterns & Khi nào KHÔNG nên dùng DDD

Fri, 10 Jul 2026 00:00:00 +0700

Vị trí chương này trong tài liệu: Đây là chương cuối cùng. Sau khi đã đi qua toàn bộ strategic design (chương 01–05), tactical patterns (06–11), kiến trúc và distributed systems (12–13), đưa vào production (14) và các case study (15a, 15b), chương này làm hai việc mà một tài liệu trung thực bắt buộc phải làm: liệt kê những cách người ta làm hỏng DDD trong thực tế — với code thật, dấu hiệu nhận biết thật — và nói thẳng khi nào đừng dùng DDD. Cuối chương là phần tổng kết toàn bộ tài liệu và lộ trình học tiếp.

Chương 15b — Case Study: SaaS, Blockchain, Booking System, Social Network

Thu, 09 Jul 2026 23:00:00 +0700

Vị trí trong bộ tài liệu: nửa sau của phần case study. Chương 15a đi qua bốn ngành “kinh điển”; chương này chọn bốn ngành ở các thái cực khác nhau của trục nhất quán: SaaS (ranh giới tenant là luật sống còn), Blockchain exchange (nguồn sự thật nằm một nửa ngoài hệ thống của bạn), Booking (tranh chấp tài nguyên theo thời gian — bài toán strong consistency thuần khiết nhất), và Social Network (read-heavy, eventual consistency là mặc định nhưng moderation phức tạp bất ngờ). Đọc bốn ngành cạnh nhau để thấy: cùng một bộ pattern, liều lượng và điểm đặt hoàn toàn khác nhau — đó chính là kỹ năng của kiến trúc sư.

Chương 15a — Case Study: E-commerce, FinTech, Banking, Logistics

Thu, 09 Jul 2026 22:00:00 +0700

Vị trí trong bộ tài liệu: Đây là chương đầu tiên trong cặp chương case study (15a/15b), đứng sau Chương 14 — DDD trong Production. Toàn bộ lý thuyết từ chương 01–14 — Subdomain, Bounded Context, Context Mapping, Aggregate, Domain Event, kiến trúc và distributed systems — sẽ được “thử lửa” qua 4 ngành có độ phức tạp domain rất khác nhau: E-commerce, FinTech (ví điện tử/payment), Banking (core banking + lending), Logistics (last-mile delivery). Mục tiêu không phải là đưa cho bạn thiết kế để copy, mà là cho bạn thấy cách lập luận: cùng một pattern, tại sao ngành này dùng còn ngành kia thì không.

Chương 14: DDD trong Production — Refactoring, Adoption, Tổ chức Team và Vận hành Dài hạn

Thu, 09 Jul 2026 21:00:00 +0700

Vị trí chương này trong tài liệu: Sau khi đã nắm toàn bộ tactical patterns (chương 06–11), kiến trúc (chương 12) và distributed systems (chương 13), chương này trả lời câu hỏi thực tế nhất: làm sao đưa DDD vào một hệ thống đang chạy, đang có khách hàng, đang có team, đang có deadline? Đây là chương dành cho những người phải sống với hệ quả của quyết định kiến trúc — không phải trên slide, mà trong production lúc 2 giờ sáng. Chương tiếp theo (15a) sẽ áp dụng toàn bộ những gì bàn ở đây vào các case study cụ thể.

Chương 13: DDD và Distributed Systems

Thu, 09 Jul 2026 20:00:00 +0700

Vị trí trong lộ trình: Chương 12 kết thúc ở ranh giới của một process — kiến trúc bảo vệ domain model bên trong một deployable. Chương này bước qua ranh giới đó. Ngay khi hệ thống của bạn có từ hai deployable trở lên (dù chỉ là API + worker, chưa cần tới microservices), một loạt định luật vật lý mới có hiệu lực: message có thể lặp, mất, đến trễ hoặc sai thứ tự; transaction không trải qua hai database; “lưu xong rồi publish” không còn là một hành động atomic. Đây là chương dài nhất của bộ tài liệu, vì đây là nơi phần lớn hệ thống production thật sự gãy — không phải ở chỗ model Entity hay Value Object, mà ở chỗ hai bounded context nói chuyện với nhau qua một đường mạng không đáng tin. Sau chương này là 14 - DDD trong Production.

Chương 12: DDD và Kiến trúc hệ thống

Thu, 09 Jul 2026 19:00:00 +0700

Vị trí trong lộ trình: Đến chương này, bạn đã có đầy đủ tactical patterns — Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event, Specification. Câu hỏi tiếp theo không còn là “mô hình hóa domain thế nào” mà là “đặt cái domain model đó vào đâu trong codebase, và bảo vệ nó bằng cách nào”. Chương này trả lời câu hỏi đó: từ layered architecture truyền thống, qua Hexagonal/Onion/Clean, đến cấu trúc thư mục cụ thể cho NestJS và Go, rồi mở rộng lên câu hỏi lớn hơn — Modular Monolith hay Microservices. Chương 13 sẽ tiếp tục với các pattern cho distributed systems.

Chương 11 — Specification: Business rule dạng điều kiện cũng xứng đáng có nhà

Thu, 09 Jul 2026 18:00:00 +0700

Vị trí trong bộ tài liệu: chương khép lại phần Tactical Design. Entity/Value Object (06) chứa rule của một object, Aggregate (07) giữ invariant khi ghi, Domain Service (09) chứa nghiệp vụ vắt qua nhiều object, Domain Event (10) lan truyền hậu quả. Còn một loại rule chưa có nhà: câu hỏi có/không về một object — “khách này có đủ điều kiện X không?”. Chương này ngắn hơn các chương trước, vì pattern nhỏ — nhưng nó hay bị dùng sai theo cả hai chiều: không dùng khi cần, và lạm dụng khi không cần.

Chương 10: Domain Event — Ghi lại những gì ĐÃ xảy ra, để phần còn lại của hệ thống tự lo

Thu, 09 Jul 2026 17:00:00 +0700

Vị trí chương này: Chương 9 kết thúc bằng một món nợ: PlaceOrderUseCase gọi events.publishAll(order.pullDomainEvents()) và hứa “chương 10 giải thích”. Email xác nhận, SMS cho khách Platinum, cộng điểm loyalty, trừ kho — tất cả đã bị đuổi ra khỏi transaction đặt hàng mà chưa nói rõ chúng đi đâu. Chương này trả món nợ đó. Domain Event cũng là cây cầu nối sang phần sau của tài liệu: không hiểu nó thì không đọc được chương 12 (kiến trúc), chương 13 (distributed systems), và toàn bộ các case study 15a/15b.

Chương 9: Domain Service và Application Service — Tách "nồi lẩu" Service ra đúng tầng

Thu, 09 Jul 2026 16:00:00 +0700

Vị trí chương này: Bạn đã đi qua Entity, Value Object (chương 6), Aggregate (chương 7), Repository và Factory (chương 8). Đến đây, mô hình domain của bạn đã có “xương sống”. Nhưng thực tế sẽ nhanh chóng ném vào mặt bạn một câu hỏi: có những nghiệp vụ không thuộc về bất kỳ Entity nào cả — nhét nó vào đâu? Chương này trả lời câu hỏi đó, và quan trọng hơn: mổ xẻ cái OrderService 500 dòng mà gần như mọi codebase NestJS/Go đều có, rồi tách nó ra từng lớp một. Đây là chương “bẩn tay” nhất từ đầu tài liệu đến giờ.

Chương 08 — Repository và Factory: Cửa khẩu giữa Domain và hạ tầng lưu trữ

Thu, 09 Jul 2026 15:00:00 +0700

Vị trí trong bộ tài liệu: chương thứ ba của Tactical Design. Chương 06 xây viên gạch (Entity, Value Object), chương 07 xây bức tường (Aggregate và ranh giới nhất quán). Chương này trả lời câu hỏi còn treo: aggregate được lấy ra và cất vào đâu, bằng cách nào, mà domain model không bị ORM và SQL xâm thực.

1. Problem Statement: Domain model chết đuối trong query

Một codebase NestJS điển hình sau 18 tháng:

Chương 07 — Aggregate và Aggregate Root: Consistency Boundary trong thế giới concurrent

Thu, 09 Jul 2026 14:00:00 +0700

Vị trí chương này: Đây là chương quan trọng nhất của toàn bộ Tactical Design — nếu chỉ được đọc kỹ một chương trong nửa sau tài liệu, hãy đọc chương này. Chương 06 cho chúng ta Entity và Value Object — công cụ bảo vệ tính đúng đắn của từng object riêng lẻ. Nhưng bug đắt nhất trong production hiếm khi nằm ở một object: nó nằm ở invariant xuyên nhiều object, bị xé rách bởi các request chạy đồng thời. Aggregate là câu trả lời của DDD cho đúng bài toán đó. Hiểu sai Aggregate thì Repository (chương 08), Domain Event (chương 10) và toàn bộ phần distributed systems (chương 13) sẽ sai theo.

Chương 6: Entity và Value Object — Hai viên gạch đầu tiên của Tactical Design

Thu, 09 Jul 2026 13:00:00 +0700

Vị trí chương này: Từ chương 1 đến chương 5, chúng ta đã đi qua Strategic Design — cách chia hệ thống thành Domain, Subdomain, Bounded Context và cách các context nói chuyện với nhau. Từ chương này trở đi, chúng ta bước vào Tactical Design: cách viết code bên trong một Bounded Context. Entity và Value Object là hai building block cơ bản nhất — mọi thứ khác (Aggregate ở chương 7, Repository ở chương 8, Domain Service ở chương 9) đều xây trên hai khái niệm này. Nếu bạn hiểu sai Entity/Value Object, toàn bộ phần còn lại của Tactical Design sẽ méo theo.

Chương 05 — Context Mapping: Bản Đồ Quyền Lực Giữa Các Bounded Context

Thu, 09 Jul 2026 12:00:00 +0700

Vị trí chương này trong chuỗi tài liệu: Ở chương 04, chúng ta đã vẽ xong ranh giới — mỗi Bounded Context có model riêng, ngôn ngữ riêng, team riêng. Nhưng ranh giới không có nghĩa là cô lập: Ordering vẫn phải biết giá từ Catalog, Shipping vẫn phải nhận đơn từ Ordering, và cả hệ thống vẫn phải nói chuyện với core banking 20 năm tuổi của đối tác. Chương này trả lời câu hỏi: các context quan hệ với nhau như thế nào — về mặt kỹ thuật, và quan trọng hơn, về mặt tổ chức và quyền lực? Đây là chương khép lại phần strategic design; từ chương 06 trở đi chúng ta đi vào tactical design — xây dựng model bên trong một context.

Chương 04 — Bounded Context: Ranh Giới Ngữ Nghĩa Của Model

Thu, 09 Jul 2026 11:00:00 +0700

Vị trí chương này trong chuỗi tài liệu: Ở chương 02, chúng ta đã mổ xẻ domain và subdomain — tức là bài toán mà business đang phải giải. Ở chương 03, chúng ta thống nhất rằng ngôn ngữ chung giữa engineer và domain expert là nền móng của mọi model tốt. Chương này trả lời câu hỏi tiếp theo, và cũng là câu hỏi quan trọng bậc nhất của DDD chiến lược: ngôn ngữ đó, model đó, có hiệu lực đến đâu? Ranh giới của nó nằm ở chỗ nào? Nếu bạn chỉ được đọc một chương duy nhất trong toàn bộ phần strategic design, hãy đọc chương này. Chương kế tiếp — 05: Context Mapping — sẽ nói về chuyện gì xảy ra giữa các ranh giới đó.

Chương 03 — Ubiquitous Language: Ngôn ngữ chung là nền móng, không phải phụ kiện

Thu, 09 Jul 2026 10:00:00 +0700

Vị trí trong bộ tài liệu: chương cuối của phần Foundations. Chương 01 chỉ ra business complexity là kẻ thù chính; chương 02 dạy cách chia domain để phân bổ nguồn lực. Chương này trả lời câu hỏi nền tảng hơn cả hai: làm sao để những gì team hiểu về nghiệp vụ không bị bóp méo trên đường đi từ cuộc họp vào code. Không có chương này, mọi pattern phía sau đều xây trên cát.

Chương 02 — Domain và Subdomain: Bản đồ chiến lược trước khi viết dòng code đầu tiên

Thu, 09 Jul 2026 09:00:00 +0700

Vị trí trong bộ tài liệu: Chương trước (01 — Tại sao DDD ra đời) đã xác lập rằng business complexity là kẻ thù chính và DDD là phương pháp tư duy để quản lý nó. Chương này trả lời câu hỏi chiến lược đầu tiên mà mọi Architect phải trả lời trước khi chọn công nghệ, vẽ kiến trúc hay tạo class: độ phức tạp nghiệp vụ nằm ở đâu trong doanh nghiệp, phần nào tạo ra tiền, và phần nào đáng đầu tư kỹ sư giỏi nhất? Đây là nội dung Strategic Design thuần túy — chưa có một dòng Entity hay Aggregate nào. Chương tiếp theo: 03 — Ubiquitous Language. Mục lục: 00-muc-luc.md.

Chương 01 — Tại sao DDD ra đời: Business Complexity là kẻ thù thật sự

Thu, 09 Jul 2026 08:00:00 +0700

Vị trí trong bộ tài liệu: Đây là chương mở đầu của bộ tài liệu Domain-Driven Design (xem 00-muc-luc.md). Trước khi nói về Bounded Context, Aggregate hay Domain Event, chúng ta phải trả lời câu hỏi nền tảng nhất: DDD sinh ra để giải quyết vấn đề gì, và tại sao những cách làm quen thuộc — database-first, CRUD, transaction script — lại thất bại? Nếu bạn không đồng ý với chương này, mọi chương sau đều vô nghĩa với bạn. Chương tiếp theo: 02-domain-va-subdomain.md.

Domain-Driven Design — Bộ tài liệu chuyên sâu

Thu, 09 Jul 2026 07:00:00 +0700

Tài liệu dành cho Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect và Software Architect. Viết bằng tiếng Việt, giữ nguyên thuật ngữ chuyên ngành (Domain, Bounded Context, Aggregate, Entity, Value Object, Domain Event, Repository, Ubiquitous Language…). Code mẫu dùng TypeScript (NestJS) và Go, mỗi khái niệm đều được đối chiếu với cách làm phổ biến trong framework để chỉ ra những điểm dễ hiểu sai.

Tài liệu này viết theo triết lý nào

Không chương nào mở đầu bằng định nghĩa. Mọi khái niệm đi theo mạch: vấn đề business có thật → vì sao cách làm truyền thống thất bại → bản chất của lời giải → cách hoạt động → điểm mạnh, điểm yếu, trade-off → cân nhắc production → anti-pattern → khi nào KHÔNG nên dùng. Mỗi kết luận kỹ thuật đều phải trả lời: tại sao? đánh đổi gì? không áp dụng thì sao? áp dụng sai thì hậu quả gì? Và xuyên suốt: DDD không phải một bộ class — nó là phương pháp tư duy để quản lý sự phức tạp của business; tài liệu không thần thánh hóa nó, mà chỉ rõ chỗ nào nó đáng tiền và chỗ nào nó là gánh nặng.

Chương 16: Failure Cases — Phân tích sự cố Production

Sun, 22 Feb 2026 21:00:00 +0700

← Chương trước | Mục lục | Chương sau →

Đây là chương quan trọng nhất của toàn bộ tài liệu. Mọi kiến thức về giao thức, message broker, resilience pattern ở các chương trước chỉ thực sự có giá trị khi bạn đứng trước một dashboard đỏ rực lúc 2 giờ sáng và phải trả lời ba câu hỏi: chuyện gì đang xảy ra, tại sao, và làm gì ngay bây giờ.

Chương 15. Principal Architecture — Multi-Region, Cross-DC và Large Scale

Sun, 22 Feb 2026 20:00:00 +0700

← Chương trước | Mục lục | Chương sau →

15.1. Business problem: khi công ty vượt qua biên giới một region

Hãy bắt đầu từ một tình huống có thật ở hầu hết các công ty tăng trưởng nhanh.

Công ty của bạn khởi đầu với toàn bộ hệ thống đặt tại một region — giả sử us-east-1 (Virginia). Ba năm sau, business mở rộng ra ba châu lục: Bắc Mỹ, châu Âu, và Đông Nam Á. Ngay lập tức, ba loại áp lực xuất hiện cùng lúc, và cả ba đều không giải quyết được bằng cách “tối ưu code”:

Chương 14 — Microservices Communication: API Gateway và Service Mesh

Sun, 22 Feb 2026 19:00:00 +0700

← Chương trước | Mục lục | Chương sau →

Mở đầu: Bài toán kinh doanh

Hãy bắt đầu từ một câu chuyện quen thuộc. Công ty của bạn có một monolith, 50 developer, deploy 1 lần/tuần. Mỗi lần deploy là một “sự kiện”: freeze code từ thứ Tư, QA regression 2 ngày, deploy đêm thứ Sáu, và cả team on-call cuối tuần. Feature nhỏ nhất cũng mất 2 tuần để ra production vì phải xếp hàng chung chuyến tàu release. Ban lãnh đạo hỏi: “Đối thủ ship feature mỗi ngày, tại sao chúng ta mất 2 tuần?”

Chương 12: Resilience Patterns — Giao tiếp ổn định trong hệ thống không ổn định

Sun, 22 Feb 2026 18:00:00 +0700

← Chương trước | Mục lục | Chương sau →

12.1. First principles: partial failure là trạng thái bình thường

Trong monolith, một lời gọi hàm hoặc thành công hoặc ném exception — và cả hai đều xảy ra trong cùng một process, cùng một số phận. Khoảnh khắc bạn tách hàm đó ra sau một network call, bạn nhận về một tập kết quả hoàn toàn mới: thành công, thất bại, và mọi trạng thái lửng lơ ở giữa — request đến nơi nhưng response thất lạc, request đang xếp hàng ở đâu đó và sẽ được xử lý sau 30 giây nữa, downstream đã xử lý xong nhưng bạn đã bỏ đi.

Chương 11: API Design — Thiết kế API cho tuổi thọ 10 năm

Sun, 22 Feb 2026 17:00:00 +0700

← Chương trước | Mục lục | Chương sau →

11.1. Vì sao API design là quyết định khó đảo ngược nhất

Bắt đầu từ một sự thật mà mọi engineer đều học được theo cách đau đớn: code là tài sản riêng của bạn, còn API là hợp đồng công khai với người khác. Bạn có thể refactor toàn bộ internal implementation vào thứ Ba tuần sau mà không ai hay biết. Nhưng một field đã xuất hiện trong response, một URI đã có người gọi, một status code đã có người viết if để bắt — những thứ đó không còn thuộc về bạn nữa. Chúng thuộc về mọi consumer đang phụ thuộc vào chúng.

Chương 10: So sánh Communication Pattern và Framework quyết định

Sun, 22 Feb 2026 16:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Chín chương vừa qua đã mổ xẻ từng công nghệ. Bây giờ là câu hỏi mà mọi architect phải trả lời hàng tuần, và là câu hỏi bị trả lời sai nhiều nhất:

“Service A cần nói chuyện với Service B / với client. Dùng cái gì?”

Cách câu hỏi này thường bị trả lời sai trong thực tế:

Chương 9: Event Streaming — Log phân tán và xử lý sự kiện quy mô lớn

Sun, 22 Feb 2026 15:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Hãy bắt đầu bằng một bài toán thật, không phải định nghĩa sách giáo khoa.

Bạn vận hành một nền tảng thương mại điện tử. Mỗi hành động của người dùng — xem sản phẩm, thêm vào giỏ, tìm kiếm, click banner — sinh ra một event. Ở quy mô 10 triệu người dùng hoạt động, hệ thống của bạn sinh 2–5 triệu event mỗi giây vào giờ cao điểm. Và đây là danh sách những bên muốn tiêu thụ dòng event đó:

Chương 8: Message Queue — Tách rời thời gian giữa các hệ thống

Sun, 22 Feb 2026 14:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Hãy bắt đầu từ một luồng nghiệp vụ mà mọi hệ thống e-commerce đều có: khách hàng đặt hàng thành công.

Khi đơn hàng được tạo, hệ thống phải làm ít nhất bốn việc:

Gửi email xác nhận cho khách.
Cộng điểm tích lũy (loyalty).
Cập nhật tồn kho (inventory).
Đẩy dữ liệu sang hệ thống analytics.

Cách tiếp cận ngây thơ nhất — và cũng là cách hầu hết các hệ thống bắt đầu — là gọi synchronous tất cả trong cùng một request:

Chương 7: Server-Sent Events — Push đơn giản trên HTTP

Sun, 22 Feb 2026 13:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Ba bài toán rất phổ biến có chung một hình dạng:

Dashboard giá / telemetry: server đẩy giá mới, số liệu mới xuống hàng nghìn màn hình. Client chỉ nhìn, không gửi gì (ngoài vài thao tác lọc hiếm hoi qua REST).
Notification feed: “bạn có comment mới” — server phát, client nhận.
LLM token streaming: model sinh token, server đẩy từng token xuống UI ngay khi có. Client gửi đúng một prompt lúc đầu (qua POST), sau đó chỉ nhận.

Điểm chung: dữ liệu chảy một chiều, server → client. Chiều ngược lại hoặc không tồn tại, hoặc thưa thớt tới mức một HTTP request bình thường phục vụ tốt.

Chương 6: WebSocket — Kênh song công cho Realtime

Sun, 22 Feb 2026 12:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Bạn đang xây một collaboration app: chat nhóm, cursor tracking, comment realtime. Yêu cầu nghiệp vụ rất rõ ràng: khi user A gõ một tin nhắn, user B phải thấy nó trong vòng dưới 200ms; đồng thời client của B cũng liên tục gửi trạng thái của chính nó lên server (typing indicator, cursor position). Nghĩa là dữ liệu chảy cả hai chiều, liên tục, với tần suất cao và độ trễ thấp.

Chương 5: gRPC — RPC hiệu năng cao cho Internal Services

Sun, 22 Feb 2026 11:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Hãy bắt đầu từ một hệ thống thật. Bạn đang vận hành một nền tảng thương mại điện tử với khoảng 200 internal service. Mỗi request từ người dùng — ví dụ “đặt hàng” — kích hoạt một chuỗi gọi nội bộ: api-gateway → order-service → inventory-service → pricing-service → promotion-service → payment-service → notification-service. Fan-out trung bình 1 request bên ngoài thành 15–30 lời gọi nội bộ. Ở mức 5.000 request/giây từ phía người dùng, hệ thống nội bộ đang xử lý hơn 100.000 lời gọi service-to-service mỗi giây.

Chương 4: GraphQL — Query Language cho API

Sun, 22 Feb 2026 10:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Hãy bắt đầu bằng một tình huống mà gần như mọi team backend phục vụ mobile app đều gặp phải.

Công ty bạn có một mobile app thương mại điện tử. App có màn hình Home, màn hình Profile, màn hình Order History, màn hình Order Detail. Backend đã có sẵn một bộ REST API được thiết kế “chuẩn resource-oriented”:

Chương 3. REST — Kiến trúc tài nguyên trên HTTP

Sun, 22 Feb 2026 09:00:00 +0700

← Chương trước | Mục lục | Chương sau →

3.1. Problem Statement — bài toán trước khi có giải pháp

Hãy bắt đầu từ một tình huống rất thật. Công ty bạn có một hệ thống quản lý đơn hàng. Ban đầu chỉ có một web app nội bộ gọi thẳng vào database. Sau 18 tháng, bức tranh thay đổi:

Team mobile cần đọc/ghi đơn hàng từ iOS và Android.
Đối tác logistics cần truy vấn trạng thái đơn qua máy chủ của họ.
Team data cần kéo dữ liệu định kỳ để làm báo cáo.
Một team khác xây admin portal, cũng cần cùng dữ liệu nhưng thao tác khác.

Bốn client, bốn ngôn ngữ, bốn vòng đời release khác nhau — tất cả cần truy cập cùng một tập dữ liệu qua HTTP. Câu hỏi kỹ thuật đặt ra:

Chương 2: HTTP — Nền tảng của giao tiếp hiện đại

Sun, 22 Feb 2026 08:00:00 +0700

← Chương trước | Mục lục | Chương sau →

1. Problem Statement

Hãy bắt đầu bằng một tình huống production quen thuộc.

Hệ thống e-commerce của bạn có 40 microservice. Một buổi sáng thứ Hai, sau đợt flash sale, team on-call báo cáo: service checkout gọi service pricing với p99 latency tăng từ 15ms lên 800ms, dù CPU của pricing chỉ 30%. Không có deploy mới. Không có query chậm. Metrics của pricing hoàn toàn bình thường.

Chương 1: Communication Fundamentals — Vì sao hệ thống cần giao tiếp

Sun, 22 Feb 2026 07:00:00 +0700

← Mục lục | Chương sau →

1. Problem Statement: Từ một function call đến một network call

Hãy bắt đầu từ một tình huống kinh doanh có thật, không phải từ định nghĩa.

Công ty của bạn vận hành một hệ thống thương mại điện tử. Ba năm trước, toàn bộ hệ thống là một monolith viết bằng Go: module order gọi module inventory bằng một function call, module payment gọi module notification bằng một method trên struct. Mọi thứ chạy trong cùng một process, cùng một address space, cùng một failure domain. Một lời gọi hàm mất vài chục nanosecond, không bao giờ “mất gói tin”, không bao giờ trả về một nửa kết quả, và hoặc là cả process sống, hoặc là cả process chết — không có trạng thái lưng chừng.