Thiết kế Event-Driven Architecture với Apache Kafka (KRaft) và RabbitMQ 4.0 trên Production (Chuẩn 2026)

1. Tại sao Giao tiếp Đồng bộ Chuỗi (Synchronous Request-Response Chains) Làm Sụp đổ Hệ thống Microservices?

Khi một hệ thống doanh nghiệp chuyển đổi từ ứng dụng nguyên khối sang kiến trúc Microservices với Docker và Kubernetes thực chiến, sai lầm kiến trúc đắt giá nhất là nối trực tiếp các dịch vụ bằng một chuỗi lời gọi REST hoặc gRPC Microservices đồng bộ kéo dài qua 5–6 chặng (Order Service -> Payment Service -> Inventory Service -> Loyalty Service -> Notification Service). Mô hình khớp nối chặt theo thời gian (Temporal Coupling) này gây ra ba hệ lụy nghiêm trọng trên Production:

1. Suy giảm Độ sẵn sàng theo Cấp số Nhân: Nếu mỗi dịch vụ đơn lẻ đạt SLA độ sẵn sàng 99.9%, thì một giao dịch yêu cầu cả 5 dịch vụ phải trực tuyến đồng thời sẽ có độ sẵn sàng tổng thể giảm xuống chỉ còn $0.999^5 approx 99.5%$ (tương đương gần 44 giờ lỗi mỗi năm). Chỉ cần dịch vụ gửi email/SMS ở cuối chuỗi bị chậm, toàn bộ luồng đặt hàng phía trước bị treo theo.
2. Hiệu ứng Khuếch đại Độ trễ Đuôi (Tail-Latency Amplification) và Bão Retry: Khi một dịch vụ hạ nguồn bị nghẽn I/O tạm thời, các dịch vụ thượng nguồn giữ chặt luồng (Threads/Goroutines) và kích hoạt cơ chế thử lại (Retry), làm cạn kiệt tài nguyên trên toàn bộ cụm.
3. Mất Nhất quán Dữ liệu do Lỗi Ghi Kép (Dual-Write Anti-Pattern): Khi lập trình viên thực hiện COMMIT đơn hàng vào cơ sở dữ liệu rồi mới gọi lệnh Publish() lên Message Broker, nếu tiến trình bị sập hoặc mạng đứt đúng vào khoảng giữa hai lệnh đó, đơn hàng đã nằm trong Database nhưng không có bất kỳ sự kiện nào được phát đi cho kho hàng và kế toán.

Bài viết chuyên sâu này cung cấp cẩm nang kiến trúc và triển khai thực chiến Event-Driven Architecture (EDA) theo tiêu chuẩn năm 2026: phân tích chiều sâu Apache Kafka 3.9+ / 4.0 (chế độ KRaft không ZooKeeper & giao thức KIP-848) so với RabbitMQ 4.0 (Quorum Queues dựa trên Raft), đồng thời giải quyết triệt để bài toán Transactional Outbox với PostgreSQL 17+ (UUIDv7) và Idempotent Consumers.

2. Đối chiếu Kiến trúc Cốt lõi: Apache Kafka (KRaft Commit Log) so với RabbitMQ 4.0 (Exchange & Quorum Queue)

Mặc dù cả hai đều được sử dụng để truyền tải thông điệp bất đồng bộ, Apache Kafka và RabbitMQ được xây dựng trên hai triết lý cấu trúc dữ liệu hoàn toàn trái ngược nhau:

• Apache Kafka (Dumb Broker / Smart Consumer — Nhật ký Bất biến Phân mảnh): Kafka lưu trữ mọi sự kiện vào các tệp nhật ký chỉ ghi nối tiếp (Append-only Partitioned Commit Log) trên đĩa kết hợp kỹ thuật truyền tải Zero-Copy (sendfile syscall) trực tiếp từ Linux Page Cache sang card mạng mà không đi qua bộ nhớ ứng dụng JVM. Tin nhắn không bị xóa khi Consumer đọc xong; mỗi Consumer Group tự quản lý con trỏ vị trí đọc (Offset), cho phép phát lại (Replay) lịch sử sự kiện từ nhiều ngày trước. Từ phiên bản Kafka 3.9+ / 4.0, ZooKeeper đã bị loại bỏ hoàn toàn và thay thế bằng giao thức đồng thuận nội tại KRaft (Kafka Raft Metadata Mode) cùng bộ điều phối KIP-848 Consumer Rebalance Protocol loại bỏ hiện tượng "Stop-the-World" khi thêm/bớt Consumer.
• RabbitMQ 4.0 (Smart Broker / Simple Consumer — Bộ Định tuyến & Hàng đợi Tác vụ): RabbitMQ nhận tin nhắn tại Exchange, đánh giá quy tắc định tuyến phức tạp (Direct, Topic với ký tự đại diện * / #, Headers, Fanout) rồi đẩy bản sao vào các Queue. Trên chuẩn RabbitMQ 4.0, cơ chế Classic Mirrored Queues cũ đã bị khai tử và thay thế hoàn toàn bởi Quorum Queues (x-queue-type: quorum sử dụng thuật toán đồng thuận Raft bảo toàn dữ liệu) và RabbitMQ Streams. Ngay khi Consumer xử lý xong và gửi tín hiệu xác nhận (basic.ack), tin nhắn sẽ được xóa khỏi Quorum Queue.

flowchart TD
    subgraph KafkaArch["Mô hình 1: Apache Kafka 3.9+/4.0 (KRaft Partitioned Event Streaming)"]
        K_PROD["Order Service Producer<br/>(acks=all, enable.idempotence=true)"]
        K_PART["Topic: orders.events.v1<br/>Partition 0..N (Append-only Log + Zero-Copy)"]
        K_CG1["Consumer Group A: Inventory Service<br/>(Đọc theo Offset riêng - Real-time)"]
        K_CG2["Consumer Group B: Data Lakehouse / Fraud AI<br/>(Có thể Replay lại từ Offset = 0)"]
    end

    subgraph RabbitArch["Mô hình 2: RabbitMQ 4.0 (Exchange Routing & Raft Quorum Queues)"]
        R_PROD["Billing / Notification Producer<br/>(Publisher Confirms)"]
        R_EX["Topic Exchange: notifications.topic"]
        R_Q1["Quorum Queue: email.high.priority<br/>(x-queue-type: quorum, Raft Replicated)"]
        R_Q2["Quorum Queue: webhook.partner.dispatch<br/>(Kèm Dead-Letter Exchange DLX)"]
        R_WORK["Worker Pool<br/>(basic.qos prefetch=20 + basic.ack)"]
    end

    K_PROD -->|"Hash(aggregate_id) -> Partition"| K_PART
    K_PART --> K_CG1
    K_PART --> K_CG2

    R_PROD -->|"routing_key: notify.email.vip"| R_EX
    R_EX -->|"Binding: notify.email.*"| R_Q1
    R_EX -->|"Binding: notify.webhook.#"| R_Q2
    R_Q1 --> R_WORK
    R_Q2 --> R_WORK

Bảng Ma trận Quyết định Kiến trúc: Khi nào Chọn Kafka, Khi nào Chọn RabbitMQ, Khi nào Kết hợp Cả Hai?

3. Triển khai Cụm Apache Kafka (KRaft Mode) và RabbitMQ 4.0 Chuẩn Production bằng Docker Compose

Tuân thủ tiêu chuẩn đóng gói an toàn trong bài tối ưu hóa Docker Image với Multi-stage Build và Alpine Linux, dưới đây là tệp docker-compose.yml khởi tạo đồng thời Apache Kafka ở chế độ KRaft Combined Mode (không cần ZooKeeper) và RabbitMQ 4.0 Management:

# File: /opt/eda-platform/docker-compose.yml
# Chuẩn Production 2026: Apache Kafka KRaft (KIP-848 enabled) & RabbitMQ 4.0 Quorum Queues
name: infoteck-eda-platform

networks:
  eda_net:
    driver: bridge

volumes:
  kafka_kraft_data:
  rabbitmq_quorum_data:

services:
  kafka-kraft:
    image: apache/kafka:3.9.0
    container_name: kafka-kraft-01
    hostname: kafka-kraft-01
    restart: unless-stopped
    ports:
      - "127.0.0.1:9092:9092"
    environment:
      # Cấu hình KRaft Mode (Loại bỏ hoàn toàn ZooKeeper)
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka-kraft-01:9093"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_LISTENERS: "PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://127.0.0.1:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      # Kích hoạt giao thức Consumer Rebalance thế hệ mới KIP-848
      KAFKA_GROUP_COORDINATOR_REBALANCE_PROTOCOLS: "classic,consumer"
      KAFKA_OFFSETS_TOPIC_replication_factor: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_LOG_RETENTION_HOURS: 168
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka_kraft_data:/var/lib/kafka/data
    security_opt:
      - no-new-privileges:true
    networks:
      - eda_net

  rabbitmq:
    image: rabbitmq:4.0-management-alpine
    container_name: rabbitmq-v4
    hostname: rabbitmq-node-01
    restart: unless-stopped
    ports:
      - "127.0.0.1:5672:5672"
      - "127.0.0.1:15672:15672"
    environment:
      RABBITMQ_DEFAULT_USER: "infoteck_eda"
      RABBITMQ_DEFAULT_PASS: "${RABBITMQ_STRONG_PASSWORD}"
      RABBITMQ_DEFAULT_VHOST: "/production"
    volumes:
      - rabbitmq_quorum_data:/var/lib/rabbitmq
    security_opt:
      - no-new-privileges:true
    networks:
      - eda_net

[!IMPORTANT]
Cấu hình Độ bền Dữ liệu trên Cụm Kafka Đa Nút (3+ Brokers): Khi triển khai cụm Production từ 3 nút trở lên trên hạ tầng triển khai cụm Kubernetes High Availability trên Bare Metal, bắt buộc phải đặt bộ ba tham số chống mất dữ liệu: replication.factor=3, min.insync.replicas=2 trên Topic và acks=all kèm enable.idempotence=true trên Producer.

4. Giải quyết Triệt để Lỗi Ghi Kép (Dual-Write) bằng Mẫu Transactional Outbox trên PostgreSQL 17 (UUIDv7)

4.1. Luồng Thực thi Transactional Outbox và Idempotent Consumer

Để đảm bảo không bao giờ xảy ra tình trạng đơn hàng đã lưu vào cơ sở dữ liệu nhưng sự kiện bị thất lạc (hoặc ngược lại, sự kiện đã phát đi nhưng giao dịch Database bị ROLLBACK), dịch vụ phát sinh sự kiện tuyệt đối không gọi trực tiếp lên Kafka/RabbitMQ bên trong hàm xử lý HTTP/gRPC. Thay vào đó, nó ghi bản ghi nghiệp vụ (orders) và bản ghi sự kiện (outbox_events) vào cùng một giao dịch ACID cục bộ.

sequenceDiagram
    autonumber
    participant API as Order Service (Go 1.24)
    participant PG as PostgreSQL 17 (ACID DB)
    participant RELAY as Outbox Relay / Debezium CDC
    participant KAFKA as Apache Kafka (KRaft)
    participant CONS as Inventory Consumer
    participant DLQ as Dead-Letter Topic / Queue

    API->>PG: BEGIN TRANSACTION
    API->>PG: INSERT INTO orders (...) & INSERT INTO outbox_events (id = uuidv7(), ...)
    API->>PG: COMMIT (Đảm bảo tính nguyên tử 100%)
    RELAY->>PG: SELECT ... FROM outbox_events WHERE published_at IS NULL FOR UPDATE SKIP LOCKED
    RELAY->>KAFKA: Produce Event (Key = aggregate_id, Header = event_id, acks = all)
    KAFKA-->>RELAY: Broker ACK (Offset committed to ISR)
    RELAY->>PG: UPDATE outbox_events SET published_at = NOW()
    KAFKA->>CONS: Poll Batch (KIP-848 Consumer Protocol)
    CONS->>PG: INSERT INTO processed_events (event_id) ON CONFLICT DO NOTHING
    alt Xử lý nghiệp vụ thành công (Lần đầu thấy event_id)
        CONS->>KAFKA: Commit Offset
    else Lỗi tạm thời quá số lần Retry cho phép
        CONS->>DLQ: Chuyển bản tin lỗi kèm Stacktrace vào orders.events.dlq
        CONS->>KAFKA: Commit Offset để không chặn toàn bộ Partition
    end

4.2. Thiết kế Lược đồ Bảng outbox_events và processed_events Chuẩn UUIDv7 (RFC 9562)

Kết hợp các nguyên tắc khóa và tính bất biến đã phân tích trong bài thiết kế kiến trúc Distributed Locking và Idempotency Key với Redis & PostgreSQL, chúng ta sử dụng định danh UUIDv7 (RFC 9562) sắp xếp theo thời gian thực để tránh phân mảnh chỉ mục B-Tree (tương tự cơ chế đã trình bày tại bài tối ưu hóa hiệu năng MySQL 8.0 cho hệ thống triệu người dùng):

-- File: migrations/20261105_01_transactional_outbox_and_inbox.sql
-- Chuẩn PostgreSQL 17+: Bảng Transactional Outbox và Idempotent Consumer Inbox

-- 1. Bảng lưu trữ sự kiện chờ phát đi (Cùng Transaction với bảng nghiệp vụ orders)
CREATE TABLE IF NOT EXISTS outbox_events (
    event_id        UUID PRIMARY KEY, -- Khởi tạo bằng UUIDv7 sắp xếp theo thời gian ở tầng ứng dụng hoặc DB
    aggregate_type   VARCHAR(64)  NOT NULL,
    aggregate_id    VARCHAR(128) NOT NULL, -- Dùng làm Partition Key trên Kafka để giữ đúng thứ tự
    event_type      VARCHAR(128) NOT NULL,
    payload         JSONB        NOT NULL,
    trace_parent    VARCHAR(128),          -- Lưu W3C TraceContext phục vụ Distributed Tracing
    created_at      TIMESTAMPTZ  NOT NULL DEFAULT NOW(),
    published_at    TIMESTAMPTZ  NULL,
    retry_count     INT          NOT NULL DEFAULT 0
);

-- Chỉ mục Partial Index cực nhẹ: Chỉ đánh chỉ mục các bản ghi CHƯA phát đi (published_at IS NULL)
CREATE INDEX IF NOT EXISTS idx_outbox_unpublished
    ON outbox_events (created_at ASC)
    WHERE published_at IS NULL;

-- 2. Bảng chống xử lý trùng lặp tại phía Consumer (Idempotent Consumer Pattern)
-- Do cả Kafka và RabbitMQ đều hoạt động theo cơ chế At-Least-Once Delivery,
-- một sự kiện có thể được gửi tới Consumer >= 2 lần khi mạng chập chờn.
CREATE TABLE IF NOT EXISTS processed_events (
    event_id        UUID          NOT NULL,
    consumer_group  VARCHAR(128) NOT NULL,
    processed_at    TIMESTAMPTZ  NOT NULL DEFAULT NOW(),
    PRIMARY KEY (event_id, consumer_group)
);

5. Triển khai Thực chiến bằng Go 1.24+: Kafka Idempotent Producer & RabbitMQ 4.0 Quorum Queue

5.1. Tiến trình Outbox Relay & Kafka Idempotent Producer bằng Go 1.24+

Đoạn mã dưới đây minh họa cách kết hợp truy vấn SELECT ... FOR UPDATE SKIP LOCKED (cho phép nhiều tiến trình Relay chạy song song mà không bao giờ lấy trùng sự kiện của nhau) với cấu hình Kafka Producer chuẩn Production (acks=all, enable.idempotence=true, nén zstd):

// File: internal/eda/kafka_outbox_relay.go
// Go 1.24+: Đọc lô sự kiện từ PostgreSQL Outbox và gửi lên Apache Kafka KRaft với Idempotent Producer
package eda

import (
    "context"
    "database/sql"
    "fmt"
    "time"

    "github.com/twmb/franz-go/pkg/kgo"
)

type OutboxEvent struct {
    EventID       string
    AggregateType string
    AggregateID   string
    EventType     string
    Payload       []byte
    TraceParent   string
}

func NewProductionKafkaClient(brokers []string) (*kgo.Client, error) {
    return kgo.NewClient(
        kgo.SeedBrokers(brokers...),
        // Bắt buộc chờ toàn bộ In-Sync Replicas (ISR) xác nhận đã ghi xuống Log
        kgo.RequiredAcks(kgo.AllISRAcks()),
        // Bật Idempotent Producer chống nhân bản tin nhắn khi mạng thử lại (Sequence Number + Producer ID)
        kgo.ProducerBatchCompression(kgo.ZstdCompression()),
        kgo.ProducerLinger(5*time.Millisecond),
        kgo.RecordDeliveryTimeout(10*time.Second),
    )
}

func RelayBatchOnce(ctx context.Context, db *sql.DB, kafkaClient *kgo.Client, topic string) (int, error) {
    tx, err := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})
    if err != nil {
        return 0, err
    }
    defer tx.Rollback()

    // Lấy tối đa 100 sự kiện chưa gửi, bỏ qua các dòng đang bị Worker khác khóa (SKIP LOCKED)
    rows, err := tx.QueryContext(ctx, `
        SELECT event_id::text, aggregate_type, aggregate_id, event_type, payload, COALESCE(trace_parent, '')
        FROM outbox_events
        WHERE published_at IS NULL
        ORDER BY created_at ASC
        LIMIT 100
        FOR UPDATE SKIP LOCKED
    `)
    if err != nil {
        return 0, err
    }
    defer rows.Close()

    var records []*kgo.Record
    var eventIDs []string

    for rows.Next() {
        var ev OutboxEvent
        if scanErr := rows.Scan(&ev.EventID, &ev.AggregateType, &ev.AggregateID, &ev.EventType, &ev.Payload, &ev.TraceParent); scanErr != nil {
            return 0, scanErr
        }
        eventIDs = append(eventIDs, ev.EventID)
        records = append(records, &kgo.Record{
            Topic: topic,
            // Dùng AggregateID (ví dụ: order_id) làm Key để mọi sự kiện của cùng 1 đơn hàng vào chung 1 Partition
            Key:   []byte(ev.AggregateID),
            Value: ev.Payload,
            Headers: []kgo.RecordHeader{
                {Key: "event_id", Value: []byte(ev.EventID)},
                {Key: "event_type", Value: []byte(ev.EventType)},
                {Key: "traceparent", Value: []byte(ev.TraceParent)},
            },
        })
    }

    if len(records) == 0 {
        return 0, nil
    }

    // Gửi đồng bộ cả lô lên Kafka và kiểm tra lỗi từng bản ghi
    results := kafkaClient.ProduceSync(ctx, records...)
    if firstErr := results.FirstErr(); firstErr != nil {
        return 0, fmt.Errorf("kafka produce batch failed: %w", firstErr)
    }

    // Đánh dấu đã phát thành công
    for _, id := range eventIDs {
        if _, uErr := tx.ExecContext(ctx, `UPDATE outbox_events SET published_at = NOW() WHERE event_id = $1::uuid`, id); uErr != nil {
            return 0, uErr
        }
    }

    return len(records), tx.Commit()
}

5.2. Khởi tạo RabbitMQ 4.0 Quorum Queue, Dead-Letter Exchange (DLX) và giới hạn Poison Message

Trên RabbitMQ 4.0, khi một tin nhắn gặp lỗi dữ liệu không thể xử lý (Poison Message), nếu Consumer gọi basic.nack(requeue=true) vô điều kiện, tin nhắn đó sẽ quay lại đầu hàng đợi và lặp vô tận với tốc độ hàng nghìn lần mỗi giây.

Cấu hình chuẩn Production sử dụng Quorum Queue (x-queue-type: quorum) kết hợp thuộc tính x-delivery-limit: 5 (tự động đếm số lần giao lại qua header x-delivery-count của giao thức Raft) và đẩy sang Dead-Letter Exchange (DLX) ngay khi vượt ngưỡng:

# File: scripts/provision_rabbitmq4_quorum_topology.py
# Python 3.13+ & pika: Khởi tạo RabbitMQ 4.0 Quorum Queue kèm Dead-Letter Exchange và Delivery Limit
import pika

def provision_production_topology(amqp_url: str) -> None:
    params = pika.URLParameters(amqp_url)
    connection = pika.BlockingConnection(params)
    channel = connection.channel()

    # Bật chế độ xác nhận từ Broker (Publisher Confirms) chống mất tin nhắn khi đẩy vào Exchange
    channel.confirm_delivery()

    # 1. Khai báo Dead-Letter Exchange (DLX) và Quorum Queue lưu trữ các tin nhắn lỗi vượt quá 5 lần thử
    channel.exchange_declare(
        exchange="orders.dlx.exchange",
        exchange_type="direct",
        durable=True,
    )
    channel.queue_declare(
        queue="orders.payment.dlq",
        durable=True,
        arguments={
            "x-queue-type": "quorum",
            "x-quorum-initial-group-size": 3,
        },
    )
    channel.queue_bind(
        queue="orders.payment.dlq",
        exchange="orders.dlx.exchange",
        routing_key="payment.failed.dlq",
    )

    # 2. Khai báo Topic Exchange chính và Quorum Queue xử lý thanh toán
    #    Tự động chuyển sang DLX nếu xử lý thất bại quá 5 lần (x-delivery-limit: 5)
    channel.exchange_declare(
        exchange="orders.events.topic",
        exchange_type="topic",
        durable=True,
    )
    channel.queue_declare(
        queue="orders.payment.quorum",
        durable=True,
        arguments={
            "x-queue-type": "quorum",
            "x-quorum-initial-group-size": 3,
            "x-delivery-limit": 5,
            "x-dead-letter-exchange": "orders.dlx.exchange",
            "x-dead-letter-routing-key": "payment.failed.dlq",
        },
    )
    channel.queue_bind(
        queue="orders.payment.quorum",
        exchange="orders.events.topic",
        routing_key="order.created.*",
    )

    # 3. Giới hạn số lượng tin nhắn chưa xác nhận (Unacknowledged) tối đa trên mỗi Consumer Worker
    channel.basic_qos(prefetch_count=25)
    connection.close()

6. Kiểm tra Độ trễ Consumer Lag (kafka-consumer-groups.sh), Kiểm định Quorum và Xử lý Sự cố

Tích hợp cùng hệ thống giám sát toàn diện với Prometheus và Grafana, chỉ số quan trọng nhất của mọi kiến trúc hướng sự kiện là Consumer Lag (độ lệch giữa LOG-END-OFFSET mới nhất của Partition và CURRENT-OFFSET mà Consumer đã xử lý xong) cũng như trạng thái đồng thuận Raft của các Quorum Queues:

#!/usr/bin/env bash
# File: /usr/local/sbin/verify-eda-brokers.sh
# Mô tả: Kiểm tra trạng thái đồng thuận Kafka KRaft, độ trễ Consumer Lag và sức khỏe RabbitMQ 4.0 Quorum
set -euo pipefail

echo "=== [1/4] Kiểm tra trạng thái Quorum của bộ điều khiển Kafka KRaft (ZooKeeper-less) ==="
docker exec kafka-kraft-01 /opt/kafka/bin/kafka-metadata-quorum.sh 
  --bootstrap-server 127.0.0.1:9092 describe --status

echo "=== [2/4] Tạo Topic chuẩn Production với 6 Partitions và kiểm tra cấu hình ==="
docker exec kafka-kraft-01 /opt/kafka/bin/kafka-topics.sh 
  --bootstrap-server 127.0.0.1:9092 
  --create --if-not-exists 
  --topic orders.events.v1 
  --partitions 6 
  --replication-factor 1 
  --config compression.type=zstd

echo "=== [3/4] Đo lường độ trễ xử lý (Consumer Lag) của từng Partition trong Consumer Group ==="
docker exec kafka-kraft-01 /opt/kafka/bin/kafka-consumer-groups.sh 
  --bootstrap-server 127.0.0.1:9092 
  --describe --all-groups

echo "=== [4/4] Kiểm tra sức khỏe cụm RabbitMQ 4.0 và trạng thái Raft của các Quorum Queues ==="
docker exec rabbitmq-v4 rabbitmq-diagnostics check_running
docker exec rabbitmq-v4 rabbitmq-diagnostics quorum_status "orders.payment.quorum" -p "/production" || true

7. Tài liệu Tham khảo & Nguồn Đối chiếu Chính thống (Primary References)

1. Apache Kafka Official Documentation — KRaft (Kafka Raft Metadata Mode) & Operations: https://kafka.apache.org/documentation/#kraft
2. Apache Kafka KIP-848 — The Next Generation of the Consumer Rebalance Protocol: https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol
3. RabbitMQ 4.0 Official Documentation — Quorum Queues & Poison Message Handling (x-delivery-limit): https://www.rabbitmq.com/docs/quorum-queues
4. IETF RFC 9562 — Universally Unique IDentifiers (UUIDv7 Time-Ordered Specification): https://www.rfc-editor.org/rfc/rfc9562.html
5. Microservices.io Pattern Catalog — Transactional Outbox & Idempotent Consumer Patterns: https://microservices.io/patterns/data/transactional-outbox.html