Bài 30 — Message Brokers — Tổng quan — Architecture Decision-Making

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn đang là kiến trúc sư của một sàn thương mại điện tử Việt Nam. Vào lúc 0h ngày sinh nhật sàn, có một chiến dịch flash sale. Trong vòng 30 giây đầu tiên, hàng chục nghìn đơn hàng ập vào. Mỗi đơn hàng cần: trừ tồn kho, tạo hoá đơn, gửi email xác nhận, cộng điểm loyalty, thông báo cho nhà bán hàng, ghi log phân tích. Nếu bạn để service đặt hàng gọi trực tiếp (đồng bộ) sang cả sáu service kia rồi mới trả kết quả về cho khách, thì chỉ cần service gửi email chậm 5 giây là toàn bộ nút "Đặt hàng" của khách bị treo. Tệ hơn, nếu service tính điểm loyalty sập, khách sẽ không đặt được hàng — dù việc cộng điểm chẳng liên quan gì đến việc bán được hàng hay không.

Đây chính là bài toán mà message broker ra đời để giải quyết. Message broker là một thành phần hạ tầng đứng giữa các service, nhận thông điệp (message) từ bên gửi và chuyển đến bên nhận. Nghe qua thì đơn giản, nhưng nó là một trong những quyết định kiến trúc có sức ảnh hưởng sâu rộng nhất đến độ bền, khả năng mở rộng và độ phức tạp của hệ thống. Rất nhiều kiến trúc sư trẻ vội vàng "cắm" Kafka hay RabbitMQ vào hệ thống chỉ vì thấy công ty khác dùng, mà không hiểu rõ message broker thực sự giải quyết vấn đề gì và đánh đổi những gì.

Bài này là bài mở màn cho cả nhóm bài về messaging. Ở đây chúng ta chưa so sánh Kafka với RabbitMQ (đó là Bài 31), cũng chưa bàn về managed options như SQS (Bài 32). Nhiệm vụ của bài này là giúp bạn nắm vững bức tranh tổng thể: message broker đóng vai trò gì, các mô hình giao tiếp cốt lõi nào tồn tại, và những khái niệm nền tảng bạn bắt buộc phải hiểu trước khi lao vào chọn công cụ cụ thể.

Khái niệm cốt lõi

Message broker là gì và giải quyết điều gì

Về bản chất, message broker làm hai việc: buffer (đệm) và route (định tuyến) message giữa bên gửi (producer) và bên nhận (consumer). Producer đẩy message vào broker rồi "quên đi" — nó không cần biết ai sẽ xử lý, khi nào xử lý, hay có bao nhiêu consumer. Broker giữ message lại, rồi giao cho consumer phù hợp khi consumer sẵn sàng.

Giá trị lớn nhất của mô hình này nằm ở ba loại decoupling (tách rời):

Decouple in time (tách rời về thời gian). Producer và consumer không cần cùng online tại một thời điểm. Producer đẩy message lúc 0h, consumer có thể xử lý lúc 0h01, hoặc thậm chí sau khi nó vừa được khởi động lại vì sập lúc 0h. Message vẫn nằm an toàn trong broker chờ được xử lý.

Decouple in throughput (tách rời về tốc độ). Đây chính là vai trò "buffer" — hấp thụ đỉnh tải. Producer có thể bắn 10.000 message/giây trong lúc consumer chỉ xử lý được 2.000 message/giây. Broker giữ 8.000 message dư mỗi giây trong hàng đợi, và consumer sẽ "tiêu hóa" dần khi đỉnh tải qua đi. Không có broker, service consumer sẽ bị quá tải và sập.

Decouple in failure domain (tách rời về vùng lỗi). Nếu service gửi email sập, message xác nhận vẫn nằm trong broker. Khi service email sống lại, nó xử lý tiếp phần tồn đọng. Lỗi ở một consumer không lan sang producer, và không làm hỏng luồng nghiệp vụ chính. Đây là điều mà lời gọi đồng bộ trực tiếp (synchronous call) không bao giờ làm được.

Một cách hình dung dễ nhớ: giao tiếp đồng bộ giống như gọi điện thoại — cả hai đầu phải cùng nhấc máy, nếu đầu kia bận thì bạn phải chờ. Message broker giống như gửi tin nhắn — bạn gửi đi rồi làm việc khác, người nhận đọc và trả lời khi rảnh.

Các thành phần và thuật ngữ nền tảng

Trước khi đi sâu, cần thống nhất từ vựng vì mỗi broker gọi tên hơi khác nhau:

Producer / Publisher: bên tạo và gửi message.
Consumer / Subscriber: bên nhận và xử lý message.
Message: đơn vị dữ liệu được truyền, thường gồm payload (nội dung) và metadata (header, timestamp, khóa định tuyến).
Queue (hàng đợi): nơi message xếp hàng chờ được xử lý, thường theo mô hình một message → một consumer xử lý.
Topic (chủ đề): một kênh logic mà nhiều consumer có thể cùng đăng ký nhận.
Broker: bản thân hệ thống trung gian giữ và định tuyến message.

Hai mô hình giao tiếp cốt lõi

Đây là phần quan trọng nhất của bài. Gần như mọi hệ thống messaging đều xoay quanh hai mô hình nền tảng:

1. Point-to-Point (Queue / Work Queue). Một message được đưa vào queue và chỉ một consumer xử lý nó. Nếu có nhiều consumer cùng lắng nghe một queue, broker sẽ phân phối message giữa chúng (load balancing), mỗi message đến đúng một consumer. Đây là mô hình lý tưởng cho việc phân tán khối lượng công việc (work distribution): xử lý ảnh, gửi email, encode video. Bạn thêm consumer là tự động tăng tốc độ xử lý. Ví dụ điển hình: một queue chứa các "job xử lý ảnh sản phẩm", 5 worker cùng rút job ra làm — mỗi ảnh chỉ được xử lý một lần.

2. Publish-Subscribe (Pub/Sub, Topic). Một message được publish lên một topic và tất cả subscriber quan tâm đều nhận được bản sao của nó. Đây là mô hình cho phát tán sự kiện (event broadcasting): khi một đơn hàng được tạo, sự kiện "OrderCreated" được publish, và cả service tồn kho, service loyalty, service phân tích đều nhận được, mỗi bên tự làm phần việc của mình. Producer không cần biết có bao nhiêu bên đang lắng nghe — bạn thêm một service mới muốn phản ứng với đơn hàng, chỉ cần cho nó subscribe topic, không đụng gì đến service đặt hàng.

Sự khác biệt cốt lõi: Point-to-Point là "một việc, một người làm"; Pub/Sub là "một tin, nhiều người nghe". Nắm chắc phân biệt này là bạn đã nắm được 80% tư duy về message broker.

Consumer group — điểm giao thoa của hai mô hình

Nhiều broker hiện đại kết hợp cả hai qua khái niệm consumer group. Một topic được nhiều group đăng ký (đó là Pub/Sub: mỗi group nhận đầy đủ luồng sự kiện), nhưng bên trong mỗi group, các instance chia nhau message (đó là Point-to-Point: mỗi message chỉ một instance trong group xử lý). Nhờ đó, service loyalty có thể chạy 3 instance để chịu tải, nhưng vẫn nhận đủ mọi sự kiện đơn hàng như một khối thống nhất.

Delivery guarantees — cam kết giao message

Đây là khái niệm sống còn mà nhiều người bỏ qua. Có ba mức cam kết:

At-most-once (nhiều nhất một lần): message có thể bị mất nhưng không bao giờ trùng. Phù hợp dữ liệu ít quan trọng như log metric.
At-least-once (ít nhất một lần): message không bao giờ mất, nhưng có thể bị giao trùng. Đây là mức phổ biến nhất trong thực tế. Hệ quả trực tiếp: consumer của bạn phải idempotent (xử lý cùng message hai lần cho kết quả như một lần) — chủ đề này sẽ được đào sâu ở Bài 39.
Exactly-once (đúng một lần): đắt đỏ, phức tạp, và trong nhiều trường hợp là ảo tưởng nếu không kết hợp với idempotency ở tầng nghiệp vụ.

Các khái niệm vận hành không thể thiếu

Hai khái niệm bạn sẽ gặp ngay khi vận hành thật:

Acknowledgement (ack). Consumer báo cho broker biết "tôi đã xử lý xong message này, xóa nó đi". Nếu consumer sập trước khi ack, broker sẽ giao lại message cho consumer khác. Cơ chế này là nền tảng của độ bền, nhưng cũng chính là lý do sinh ra hiện tượng giao trùng.

Dead Letter Queue (DLQ). Khi một message bị xử lý lỗi nhiều lần liên tiếp (ví dụ payload sai định dạng), thay vì thử vô hạn làm nghẽn hàng đợi, broker chuyển nó sang một hàng đợi "thư chết" riêng để con người điều tra sau. Không có DLQ, một message độc (poison message) có thể làm kẹt cả pipeline.

Tình huống thực tế

Tình huống 1: Sàn TMĐT Việt Nam và bài toán flash sale

Quay lại ví dụ mở đầu. Đội kỹ thuật của một sàn TMĐT tại TP.HCM ban đầu để service đặt hàng gọi đồng bộ sang 6 service khác. Trong đợt sale 12/12, thời gian phản hồi của nút "Đặt hàng" trung bình 4,2 giây, và tỷ lệ lỗi lên 18% vì service loyalty bị nghẽn kéo theo toàn bộ.

Họ tái kiến trúc theo hướng event-driven dùng message broker. Service đặt hàng giờ chỉ làm hai việc: ghi đơn vào database và publish sự kiện OrderCreated lên một topic, rồi trả kết quả về cho khách ngay. Sáu service kia subscribe topic đó (mô hình Pub/Sub), mỗi service tự xử lý phần của mình một cách bất đồng bộ.

Kết quả: thời gian phản hồi nút đặt hàng giảm còn khoảng 280ms. Khi service email bị chậm do nhà cung cấp SMTP giới hạn tốc độ, message xác nhận xếp hàng trong broker và được gửi dần trong vài phút sau — khách vẫn đặt hàng bình thường. Bài học: message broker biến luồng nghiệp vụ "tất cả hoặc không gì" thành "cốt lõi trước, phần phụ theo sau", đồng thời hấp thụ đỉnh tải thay vì để nó đánh sập consumer.

Tình huống 2: Grab và pipeline xử lý sự kiện chuyến đi

Một nền tảng gọi xe quy mô Đông Nam Á như Grab tạo ra lượng sự kiện khổng lồ: mỗi chuyến đi phát ra hàng loạt sự kiện vị trí, trạng thái tài xế, thay đổi giá. Giả sử một sự kiện RideCompleted. Sự kiện này cần được nhiều bên tiêu thụ độc lập: bộ phận thanh toán để tính cước, bộ phận phân tích để cập nhật dashboard vận hành, hệ thống chống gian lận để chấm điểm rủi ro, và bộ phận tính hoa hồng tài xế.

Đây là bối cảnh Pub/Sub kinh điển ở quy mô lớn. Mỗi bộ phận là một consumer group riêng, cùng nhận đầy đủ luồng RideCompleted nhưng xử lý cho mục đích khác nhau. Điểm mấu chốt: khi Grab muốn ra mắt một tính năng mới — chẳng hạn "gợi ý khuyến mãi sau chuyến đi" — đội mới chỉ cần tạo consumer group mới subscribe vào luồng sự kiện sẵn có, không cần đội thanh toán hay đội chuyến đi sửa một dòng code nào. Bài học: message broker theo mô hình Pub/Sub biến dữ liệu sự kiện thành một "tài nguyên chung" mà các đội có thể tự phục vụ, giúp tổ chức mở rộng số lượng tính năng mà không tăng tuyến tính độ phức tạp phối hợp giữa các đội.

Tình huống 3: Startup fintech và cái bẫy "dùng broker cho mọi thứ"

Một startup fintech ở Hà Nội, sau khi đọc về event-driven architecture, quyết định đưa mọi giao tiếp qua message broker — kể cả việc màn hình cần lấy số dư tài khoản để hiển thị cho người dùng. Họ biến một truy vấn "đọc số dư" đơn giản thành: gửi message yêu cầu lên queue, service tài khoản đọc, xử lý, rồi gửi message trả lời lên một queue khác, màn hình lắng nghe queue đó.

Hậu quả: một thao tác lẽ ra chỉ mất 20ms qua một lời gọi API đồng bộ giờ mất 300–800ms, code phức tạp gấp nhiều lần, và debug thì cực kỳ khó vì luồng bị "xé" ra thành các mảnh bất đồng bộ. Họ đã dùng sai công cụ: message broker mạnh cho việc fire-and-forget (bắn đi và quên) và phát tán sự kiện, chứ không phải cho request-response cần câu trả lời ngay (query đọc dữ liệu để hiển thị). Bài học: không phải giao tiếp nào cũng nên qua broker. Khi bên gọi cần một câu trả lời ngay lập tức để tiếp tục (đặc biệt là truy vấn đọc), lời gọi đồng bộ thường đơn giản và đúng hơn. Bài 21 sẽ đào sâu chuyện chọn sync hay async.

Hướng dẫn từng bước

Khi đứng trước quyết định "có nên đưa message broker vào, và theo mô hình nào", hãy đi theo trình tự sau:

Xác định bản chất giao tiếp. Hỏi: bên gửi có cần câu trả lời ngay để tiếp tục không? Nếu có (ví dụ đọc dữ liệu để hiển thị), nghiêng về gọi đồng bộ. Nếu không (bắn đi và quên, hoặc thông báo có việc xảy ra), message broker là ứng viên sáng giá.

Phân loại theo mục đích. Đây là "một việc cần một người làm" (work distribution → chọn Point-to-Point / Queue) hay "một sự kiện cần nhiều bên phản ứng" (event broadcasting → chọn Pub/Sub / Topic)?

Xác định yêu cầu về mất mát dữ liệu. Message này mất có sao không? Nếu là tiền, đơn hàng, giao dịch → cần at-least-once trở lên, và bắt buộc thiết kế consumer idempotent. Nếu là metric có thể mất vài mẫu → at-most-once đủ và rẻ hơn.

Thiết kế ack và retry. Quyết định khi nào consumer gửi ack (trước hay sau khi xử lý xong — luôn là sau, để không mất message khi consumer sập), và số lần thử lại trước khi đẩy vào DLQ.

Thiết kế Dead Letter Queue ngay từ đầu. Đừng để đến khi có poison message làm nghẽn hệ thống mới nghĩ đến DLQ. Đây là hạng mục "ngày một".

Ước lượng throughput và độ trễ chấp nhận được. Con số này (message/giây, độ trễ đuôi cho phép) sẽ dẫn dắt việc chọn công cụ cụ thể ở các bài sau.

Ghi lại quyết định. Vì đây là một lựa chọn kiến trúc có sức ảnh hưởng lớn, hãy viết một ADR (xem Bài 4) ghi rõ vì sao chọn messaging, mô hình nào, mức delivery guarantee nào.

Lỗi thường gặp & mẹo

Lỗi 1: Dùng broker cho request-response cần câu trả lời tức thì. Như tình huống fintech ở trên. Broker sinh ra độ trễ và độ phức tạp không đáng có cho các truy vấn đọc. Mẹo: nếu bạn thấy mình phải tạo một "queue trả lời" để chờ kết quả, hãy dừng lại và cân nhắc một lời gọi đồng bộ.

Lỗi 2: Quên rằng at-least-once nghĩa là sẽ có message trùng. Rất nhiều sự cố sản xuất (khách bị trừ tiền hai lần, gửi email nhắc nợ hai lần) đến từ consumer không idempotent. Mẹo: luôn giả định message sẽ đến hai lần, và thiết kế consumer sao cho xử lý lặp lại vô hại (dùng ID nghiệp vụ để chống trùng).

Lỗi 3: Ack trước khi xử lý xong. Nếu bạn ack ngay khi nhận rồi mới xử lý, khi consumer sập giữa chừng message coi như đã xóa — mất vĩnh viễn. Mẹo: chỉ ack sau khi hoàn tất xử lý và ghi kết quả bền vững.

Lỗi 4: Không có Dead Letter Queue. Một message hỏng định dạng bị retry vô hạn có thể chặn đứng cả hàng đợi phía sau. Mẹo: đặt giới hạn số lần retry và luôn có DLQ kèm cảnh báo (alert) khi có message rơi vào đó.

Lỗi 5: Coi broker là "cơ sở dữ liệu". Message broker để truyền message, không phải để lưu trữ dài hạn hay truy vấn linh hoạt. Đừng cố query dữ liệu nghiệp vụ từ trong broker.

Lỗi 6: Bỏ qua thứ tự message khi nó quan trọng. Trong nhiều broker, khi bạn scale nhiều consumer song song, thứ tự xử lý không còn đảm bảo. Nếu thứ tự quan trọng (ví dụ sự kiện của cùng một tài khoản), hãy tìm hiểu cơ chế phân vùng theo khóa (partition key) để các message liên quan đi cùng một luồng.

Mẹo tổng quát: Bắt đầu đơn giản. Nếu hệ thống của bạn chưa có nhu cầu tách rời rõ ràng về thời gian, throughput hay failure domain, có thể bạn chưa cần broker. Đưa broker vào khi đau thực sự xuất hiện, không phải vì nó "hiện đại".

Bài tập thực hành

Phân loại giao tiếp. Liệt kê 6–8 luồng giao tiếp trong một hệ thống bạn biết (hoặc hệ thống đặt vé xem phim giả định). Với mỗi luồng, đánh dấu: nên đồng bộ hay async? Nếu async, thuộc mô hình Point-to-Point hay Pub/Sub? Giải thích lý do trong một câu.

Thiết kế luồng đặt hàng. Vẽ sơ đồ luồng đặt hàng của một sàn TMĐT dùng message broker: đâu là luồng cốt lõi đồng bộ, sự kiện nào được publish, những consumer nào subscribe. Đánh dấu rõ nơi bạn dùng Point-to-Point và nơi dùng Pub/Sub.

Xử lý message trùng. Cho tình huống: service cộng điểm loyalty nhận sự kiện OrderCreated với cam kết at-least-once. Viết (bằng lời hoặc mã giả) cách bạn làm consumer này idempotent để khách không bị cộng điểm hai lần cho cùng một đơn.

Thiết kế DLQ. Đề xuất một chính sách retry và DLQ cho service gửi email xác nhận: retry mấy lần, cách nhau bao lâu, khi nào đẩy vào DLQ, ai sẽ được cảnh báo và xử lý message trong DLQ như thế nào.

Tóm tắt

Message broker là thành phần hạ tầng đứng giữa producer và consumer, làm hai việc cốt lõi: buffer (đệm, hấp thụ đỉnh tải) và route (định tuyến) message. Giá trị lớn nhất của nó là decoupling trên ba mặt: thời gian, throughput và vùng lỗi — cho phép các service không phụ thuộc vào nhau về thời điểm hoạt động, tốc độ, hay tình trạng sống-chết.

Có hai mô hình giao tiếp nền tảng cần nắm vững: Point-to-Point (một message, một consumer xử lý — dùng cho phân tán công việc) và Publish-Subscribe (một message, nhiều subscriber nhận — dùng cho phát tán sự kiện). Khái niệm consumer group kết hợp cả hai, và các cam kết giao message (at-most-once, at-least-once, exactly-once) quyết định trực tiếp việc consumer của bạn có cần idempotent hay không. Đừng quên hai công cụ vận hành: acknowledgement (chỉ ack sau khi xử lý xong) và Dead Letter Queue (chặn poison message).

Cuối cùng, hãy nhớ message broker không phải viên đạn bạc. Nó tuyệt vời cho fire-and-forget và phát tán sự kiện, nhưng sai chỗ cho các truy vấn đọc cần câu trả lời ngay. Với nền tảng tổng quan này, bạn đã sẵn sàng đi vào các bài tiếp theo: so sánh Kafka với RabbitMQ (Bài 31) và các lựa chọn managed như SQS, Cloud Pub/Sub (Bài 32).