In the heap data structure, the root node is compared with its children and arranged according to the order. So if a is a root node and b is its child, then the property, key (a)>= key (b) will generate a max heap.

The above relation between the root and the child node is called as “Heap Property”.

Depending on the order of parent-child nodes, the heap is generally of two types:

#1) Max-Heap: In a Max-Heap the root node key is the greatest of all the keys in the heap. It should be ensured that the same property is true for all the subtrees in the heap recursively.

The below diagram shows a Sample Max Heap. Note that the root node is greater than its children.

#2) Min-Heap: In the case of a Min-Heap, the root node key is the smallest or minimum among all the other keys present in the heap. As in the Max heap, this property should be recursively true in all the other subtrees in the heap.

An example, of a Min-heap tree, is shown below. As we can see, the root key is the smallest of all the other keys in the heap.

A heap data structure can be used in the following areas:

• Heaps are mostly used to implement Priority Queues.
• Especially min-heap can be used to determine the shortest paths between the vertices in a Graph.

As already mentioned, the heap data structure is a complete binary tree that satisfies the heap property for the root and the children. This heap is also called a binary heap.

Binary Heap

A binary heap fulfills the below properties:

• A binary heap is a complete binary tree. In a complete binary tree, all the levels except the last level are completely filled. At the last level, the keys are as far as left as possible.
• It satisfies the heap property. The binary heap can be max or min-heap depending on the heap property it satisfies.

A binary heap is normally represented as an Array. As it is a complete binary tree, it can easily be represented as an array. Thus in an array representation of a binary heap, the root element will be A[0] where A is the array used to represent the binary heap.

So in general for any ith node in the binary heap array representation, A[i], we can represent the indices of other nodes as shown below.

Consider the following binary heap:

The array representation of the above min binary heap is as follows:

As shown above, the heap is traversed as per the level order i.e. the elements are traversed from left to right at each level. When the elements at one level are exhausted, we move on to the next level.

1. The Customer Service attempts to reserve credit
2. It then sends back a reply message indicating the outcome
3. The saga orchestrator either approves or rejects the Order

Bối Cảnh Vấn Đề

Hãy tưởng tượng bạn đang sở hữu một hệ thống Microservices với những đặc điểm sau:

• Mỗi service có database riêng và trao đổi với nhau thông qua các sự kiện (Event-Driven Architecture).
• Dòng nghiệp vụ của bạn kéo theo nhiều bước xử lý nằm rải rác ở các services khác nhau.
• Bạn cần một cơ chế bảo đảm toàn bộ chuỗi thao tác đó hoàn thành trọn vẹn, hoặc nếu có lỗi thì hệ thống vẫn hồi phục được.

Đó chính là lúc distributed transactions bước lên sân khấu – và cũng là lúc Saga Pattern thể hiện giá trị.

Câu Chuyện Minh Họa

Để dễ hình dung, hãy cùng nhìn vào hành trình giải ngân một khoản vay. Chuỗi các bước 1, 2, 3, 4 lần lượt được xử lý bởi những services chuyên trách khác nhau. Mỗi bước được gọi là một local transaction: service thực hiện logic của nó, lưu kết quả vào database riêng và phát đi tín hiệu (event/response) để kích hoạt bước kế tiếp. Khi toàn bộ chuỗi hoàn thành, chúng ta có một distributed transaction trọn vẹn.

Bài Toán Đặt Ra

Vậy làm sao để điều phối chuỗi local transactions này? Two-Phase Commit (2PC) là một lựa chọn, nhưng trong phạm vi bài viết chúng ta sẽ tập trung vào phương án được ưa chuộng hơn trong thế giới microservices: Saga Pattern.

Saga Pattern Là Gì?

Saga Pattern là một design pattern dùng để quản lý distributed transactions bằng cách chia chúng thành các local transactions được điều phối tuần tự. Có hai chiến lược chính:

1. Saga Choreography (Điều Phối Phân Tán) – mỗi local transaction phát ra domain event để kích hoạt service kế tiếp.
2. Saga Orchestration (Điều Phối Tập Trung) – một orchestrator đóng vai trò nhạc trưởng, điều khiển các services lần lượt thực hiện local transaction của mình.

Khi Choreography Lên Ngôi

Trong phiên bản choreographed của bài toán cho vay, mọi thứ vận hành theo các sự kiện được phát tán:

1. Khách hàng gửi yêu cầu vay → Eligibility Service nhận request POST /eligibilityCheck, xử lý thông tin pháp lý và phát sự kiện thành công.
2. Affordability Service nhận sự kiện, kiểm tra thu nhập khách hàng, lưu kết quả và tiếp tục phát sự kiện mới.
3. Decision Service tạo khoản vay, ghi nhận dữ liệu và phát sự kiện quyết định giải ngân.
4. Disbursement Service nhận sự kiện cuối cùng, giải ngân khoản vay và ghi sổ kế toán.

Dòng sự kiện khép lại khi tiền được giải ngân – distributed transaction hoàn tất một cách nhẹ nhàng.

Khi Orchestration Dẫn Dắt

Với chiến lược orchestration, chúng ta thêm một nhân vật trung tâm – orchestrator:

1. Khách hàng gửi yêu cầu vay → orchestrator nhận request và chủ động gửi sự kiện đến Eligibility Service.
2. Khi Eligibility Service hoàn tất, orchestrator nhận thông báo và ra lệnh cho Affordability Service tiếp tục.
3. Từng bước lần lượt được orchestrator điều khiển tới Decision Service và Disbursement Service.
4. Khi bước cuối cùng hoàn thành, orchestrator xác nhận distributed transaction đã kết thúc.

Về bản chất, hai chiến lược khác nhau ở cách điều phối, nhưng đều sử dụng các local transactions để xây dựng nên một workflow dài hơi.

Ưu Và Nhược Điểm

Ưu Điểm

1. Khả năng mở rộng & độc lập – Services chỉ cần lo phần việc của mình, không chia sẻ database, dễ dàng scale độc lập và tránh sự phụ thuộc chặt chẽ.
2. Giảm áp lực khóa dữ liệu – Local transaction commit ngay khi xong việc, giảm thời gian giữ lock, phù hợp với quy trình dài hạn và hạn chế deadlock.
3. Khả năng phục hồi – Khi một bước thất bại, Saga có thể chạy compensating transaction để quay ngược các bước trước đó, đảm bảo eventual consistency.
4. Ăn ý với Event-Driven Architecture – Saga phát huy sức mạnh khi kết hợp với message queue như Kafka, RabbitMQ, EventBridge,…

Nhược Điểm (Cons)

• Consistency chỉ là “eventual” – Không có đảm bảo atomic như 2PC. Trong một khoảng thời gian, dữ liệu có thể ở trạng thái trung gian (inconsistent).
• Phức tạp khi định nghĩa compensating transaction – Không phải lúc nào cũng dễ để “undo” một bước (ví dụ: đã gửi email/SMS cho khách thì khó mà rollback).
• Quản lý workflow phức tạp – Với choreography, hệ thống có nguy cơ tạo “event spaghetti” khó đọc và khó maintain; trong khi orchestration tạo dependency vào một orchestrator trung tâm dễ trở thành bottleneck.
• Debug và giám sát khó khăn hơn – Transaction được phân tán qua nhiều service và xử lý bất đồng bộ, khiến việc trace và monitor khó hơn so với giao dịch đơn lẻ.
• Latency cao hơn – Các bước thực hiện nối tiếp thông qua messaging làm độ trễ lớn hơn so với một ACID transaction trong cùng database.

  Lời Kết

Saga Pattern không phải là viên đạn bạc, nhưng là một công cụ hiệu quả để giữ cho distributed transactions trong kiến trúc microservices vận hành an toàn, linh hoạt. Tùy vào bài toán, bạn có thể chọn choreography để tận dụng kiến trúc phân tán, hoặc orchestration nếu muốn sự điều phối tập trung. Điều quan trọng nhất là hiểu rõ bối cảnh hệ thống của bạn để lựa chọn giải pháp phù hợp.