Xây dựng Microservices Event-Driven Hiệu năng Cao trong Go với NATS JetStream và CQRS

Answer-first: Hệ thống Event-Driven hiệu năng cao trên Go kết hợp NATS JetStream, CQRS và Transactional Outbox Pattern xử lý hơn 120.000 event/giây. Thiết kế phân tách Command-Query triệt để, đảm bảo ngữ nghĩa At-Least-Once Delivery và duy trì tính nhất quán cuối cùng giữa các bounded context.

🇬🇧 Read the English version of this article on tanhdev.com

1. Lý do Kiến trúc: Tại sao chọn Go + NATS JetStream cho Microservices Event-Driven

Trong các kiến trúc Cloud-Native hiện đại, việc mở rộng quy mô hệ thống phân tán vượt ngưỡng hàng chục nghìn giao dịch mỗi giây (TPS) bộc lộ những nút thắt cổ chai nghiêm trọng trong mô hình request-response truyền thống. Các microservices truyền thống được xây dựng xoay quanh giao thức đồng bộ HTTP/REST hoặc gRPC thường xuyên đối mặt với hiện tượng tranh chấp ghi cơ sở dữ liệu (database write contention), cạn kiệt connection pool, và hiệu ứng tuyết lở (cascading latency spikes) mỗi khi có các đợt bùng nổ lưu lượng truy cập dội xuống tầng lưu trữ. Khi một cơ sở dữ liệu duy nhất phải gánh vác đồng thời cả các transaction cập nhật dữ liệu phức tạp (commands) lẫn các truy vấn đọc phân tích nặng nề (reads), hiện tượng khóa cấp dòng (row-level locks) và chi phí duy trì index sẽ làm nghẽn thông lượng, đẩy độ trễ p99 từ vài mili-giây vọt lên hàng giây.

Để vượt qua những ranh giới kiến trúc cố hữu này, các tổ chức kỹ thuật quy mô lớn lựa chọn áp dụng mô hình Command Query Responsibility Segregation (CQRS) kết hợp cùng Kiến trúc Hướng Sự Kiện (Event-Driven Architecture - EDA). Bằng việc phân tách triệt để luồng ghi (Commands) khỏi luồng đọc (Queries), CQRS cho phép mỗi bên mở rộng quy mô một cách hoàn toàn độc lập theo đặc thù truy cập của mình. Phía Command chỉ tập trung thực thi các biến đổi trạng thái nhẹ nhàng trên cơ sở dữ liệu tối ưu cho ghi, sau đó phát ra các sự kiện nghiệp vụ bất biến (immutable domain events) vào một message broker hiệu năng cao. Các consumer worker tách rời sẽ bất đồng bộ tiêu thụ những sự kiện này để cập nhật dữ liệu vào các kho đọc chuyên biệt (chẳng hạn như Redis key-value, Elasticsearch documents, hoặc các bảng materialized views trong PostgreSQL).

                      +-----------------------------+
                      |   Client API Gateway        |
                      +--------------+--------------+
                                     |
               +---------------------+---------------------+
               | (Write Path)                              | (Read Path)
               v                                           v
    +----------------------+                    +----------------------+
    | Order Command Service|                    | Order Query Service  |
    +----------+-----------+                    +----------+-----------+
               |                                           |
               v                                           v
    +----------------------+                    +----------------------+
    | PostgreSQL Write DB  |                    | Redis Read Store     |
    +----------------------+                    +----------------------+
               |                                           ^
               v (Publish Event)                           | (Async Projection)
    +------------------------------------------------------+
    |             NATS JetStream Event Broker              |
    +------------------------------------------------------+

So sánh Hiệu năng: NATS JetStream vs. Apache Kafka

Việc lựa chọn đúng nền tảng event streaming đóng vai trò quyết định khi thiết kế microservices hiệu năng cao bằng Golang. Dù Apache Kafka trong lịch sử là tiêu chuẩn công nghiệp cho hệ thống nhật ký sự kiện phân tán, gánh nặng vận hành và tài nguyên runtime khổng lồ của nó tạo ra lực cản đáng kể cho các môi trường Go-Native:

1. Dung Lượng Bộ Nhớ & Chi Phí Hạ Tầng: Apache Kafka yêu cầu cấp phát bộ nhớ JVM Heap rất lớn (thường từ 3GB đến 8GB cho mỗi broker node) và phụ thuộc vào cụm ZooKeeper hoặc chế độ KRaft phức tạp. Ngược lại, NATS JetStream được biên dịch dưới dạng một tệp nhị phân đơn nhất siêu nhẹ với mức tiêu thụ RAM cơ bản chỉ vỏn vẹn ~22MB trên mỗi node. JetStream tích hợp sẵn thuật toán đồng thuận Raft nhúng trực tiếp để quản lý metadata và sao chép stream, loại bỏ hoàn toàn mọi phụ thuộc điều phối bên ngoài.
2. Tương Thích Tuyệt Đối Với Go (Zero Cgo): Thư viện Go chính thức cho Kafka (confluent-kafka-go) phụ thuộc chặt chẽ vào thư viện C librdkafka thông qua cầu nối Cgo. Việc biên dịch chéo Cgo làm tăng độ phức tạp của quy trình CI/CD build, gây ra các điểm dừng Garbage Collector ngoài tầm kiểm soát khi vượt qua ranh giới FFI (Foreign Function Interface) và phát sinh rò rỉ bộ nhớ khó chẩn đoán. Trong khi đó, NATS JetStream được viết 100% bằng Go thuần túy (nats.go), chia sẻ chung cơ chế cấp phát bộ nhớ và bộ lập lịch runtime của Go với ứng dụng của bạn.
3. Độ Trễ Sub-Millisecond Ở Phân Vị Cao (P99 Tail Latency): Nhờ động cơ mạng multiplexing epoll trực tiếp và các bộ đệm vòng không khóa (lock-free ring buffers), NATS JetStream liên tục đạt độ trễ xuất/nhận p99 dưới 0.8 mili-giây dưới tải lớn liên tục, trong khi độ trễ tail latency của Kafka thường dao động từ 10ms đến 20ms do các chu kỳ dọn rác JVM GC sweeps và cơ chế flush page cache của hệ điều hành.
4. Tích Hợp Sẵn Key-Value & Object Store: JetStream nhúng sẵn các kho lưu trữ Key-Value (KV) và Object Store trực tiếp ngay trong tầng messaging, cho phép các microservice quản lý cờ trạng thái, cửa sổ lọc trùng (deduplication windows), và schema cấu hình động mà không cần phải triển khai thêm các dịch vụ ngoại vi như Redis.

For a deeper dive into foundational microservices patterns, explore our kiến trúc Go microservices tổng quan and review our chuỗi bài kiến trúc hệ thống high concurrency.

2. Kiến trúc Hệ thống Event-Driven CQRS & Luồng Dữ liệu

Sự tách rời lỏng (loose coupling) mà CQRS mang lại phụ thuộc hoàn toàn vào cam kết chuyển giao sự kiện nghiêm ngặt giữa các worker xử lý ghi và các worker cập nhật chiếu đọc (read projection). Khi một API client gửi một thao tác thay đổi trạng thái (chẳng hạn như CreateOrderCommand), Command Service sẽ thẩm định yêu cầu, thực thi một local transaction trong cơ sở dữ liệu ghi quan hệ, và phát ra một OrderCreatedEvent vào NATS JetStream.

NATS JetStream lưu trữ bền vững sự kiện vào nhật ký stream được sao chép theo chuẩn Raft trên ổ đĩa SSD và tức thì trả về phản hồi xác nhận PubAck cho Command Service, cho phép dịch vụ phản hồi người dùng với mã HTTP 202 Accepted. Ở chế độ nền, các durable pull consumer độc lập sẽ kéo từng lô sự kiện (batches) từ JetStream về xử lý. Read Projection Worker sẽ cập nhật mô hình đọc trong Redis hoặc Elasticsearch, trong khi các worker phụ trợ khác (như Dịch vụ Tồn kho, Thanh toán và Vận chuyển) sẽ tự động thực thi nghiệp vụ miền tương ứng.

Sơ đồ Tuần tự CQRS End-to-End

Sơ đồ tuần tự dưới đây mô tả chính xác luồng điều khiển, quy trình ghi nhật ký Raft, cơ chế lọc trùng thông điệp phía server (server-side deduplication), và tiến trình chiếu đọc bất đồng bộ trong kiến trúc Go microservices của chúng ta:

sequenceDiagram
    autonumber
    actor Client as Client / API Gateway
    participant CmdService as Order Command Service (Go)
    participant WriteDB as PostgreSQL Write DB
    participant JetStream as NATS JetStream Broker
    participant ReadWorker as Read Projection Worker (Go)
    participant ReadDB as Redis Read Store (Cache/JSON)
    participant InvWorker as Inventory Service (Go)

    Client->>CmdService: POST /api/v1/orders (CreateOrderCommand)
    Note over CmdService: Validate Command & Payload
    CmdService->>WriteDB: BEGIN TX -> INSERT INTO orders -> COMMIT TX
    WriteDB-->>CmdService: TX Committed (OrderID: ORD-9921)
    
    Note over CmdService: Construct OrderCreatedEvent<br/>Set Header: Nats-Msg-Id = evt_uuid
    CmdService->>JetStream: js.PublishMsg("orders.created", payload, Nats-Msg-Id)
    
    alt Duplicate Event Retry (Within 5-min Window)
        JetStream->>JetStream: Detect existing Nats-Msg-Id in Raft window
        JetStream-->>CmdService: PubAck (Existing Stream Seq, Duplicate=true)
    else Novel Event
        JetStream->>JetStream: Append to Stream Log & Replicate via Raft
        JetStream-->>CmdService: PubAck (New Stream Seq: 10452)
    end
    
    CmdService-->>Client: 202 Accepted { order_id: "ORD-9921", status: "PENDING" }

    par Async Read Projection Update
        JetStream->>ReadWorker: sub.Fetch(10) -> Deliver OrderCreatedEvent
        Note over ReadWorker: Idempotency Check via Redis SETNX
        ReadWorker->>ReadDB: SETNX event_lock:evt_uuid EX 86400
        alt Novel Event Key
            ReadWorker->>ReadDB: HSET order_view:ORD-9921 payload
            ReadWorker->>JetStream: msg.Ack()
        else Duplicate Event Key
            ReadWorker->>JetStream: msg.Ack() (Skip Redundant Processing)
        end
    and Async Inventory Processing
        JetStream->>InvWorker: sub.Fetch(10) -> Deliver OrderCreatedEvent
        InvWorker->>InvWorker: Reserve Warehouse Inventory
        InvWorker->>JetStream: msg.Ack()
    end

By guaranteeing that event publication and storage are decoupled from projection maintenance, the system eliminates write lock contention on read views. Even if read storage experiences a temporary network partition, event publishing continues unhindered because JetStream buffers incoming messages durably on disk.

3. Khởi Tạo Cấu Hình NATS JetStream Streams và KV Stores Trong Go

To establish a production-grade NATS JetStream environment in Go, microservices must initialize a resilient connection, configure automatic reconnect policies, and provision streams with strict retention policies and deduplication windows using the github.com/nats-io/nats.go SDK.

The following production-ready code demonstrates how to connect to a NATS cluster, initialize the JetStream context, and execute stream provisioning using js.AddStream().

package main

import (
	"fmt"
	"log"
	"time"

	"github.com/nats-io/nats.go"
)

// NatsClient encapsulates the underlying NATS connection and JetStream context.
type NatsClient struct {
	NC *nats.Conn
	JS nats.JetStreamContext
}

// NewNatsClient initializes a resilient connection to the NATS cluster and configures JetStream.
func NewNatsClient(url string) (*NatsClient, error) {
	opts := []nats.Option{
		nats.Name("order-command-service"),
		nats.ReconnectWait(2 * time.Second),
		nats.MaxReconnects(10),
		nats.DisconnectErrHandler(func(nc *nats.Conn, err error) {
			log.Printf("[WARN] NATS disconnected: %v", err)
		}),
		nats.ReconnectHandler(func(nc *nats.Conn) {
			log.Printf("[INFO] NATS reconnected to: %s", nc.ConnectedUrl())
		}),
		nats.ErrorHandler(func(nc *nats.Conn, sub *nats.Subscription, err error) {
			log.Printf("[ERROR] NATS async error on sub %s: %v", sub.Subject, err)
		}),
	}

	nc, err := nats.Connect(url, opts...)
	if err != nil {
		return nil, fmt.Errorf("failed to connect to NATS cluster at %s: %w", url, err)
	}

	// Enable async publish pending limit to prevent memory bloat under backpressure
	js, err := nc.JetStream(nats.PublishAsyncMaxPending(256))
	if err != nil {
		nc.Close()
		return nil, fmt.Errorf("failed to obtain JetStream context: %w", err)
	}

	client := &NatsClient{NC: nc, JS: js}
	if err := client.initStreams(); err != nil {
		nc.Close()
		return nil, err
	}

	return client, nil
}

// initStreams ensures the ORDERS stream exists with strict deduplication and retention limits.
func (c *NatsClient) initStreams() error {
	cfg := &nats.StreamConfig{
		Name:        "ORDERS",
		Description: "Order lifecycle domain events for CQRS write path",
		Subjects:    []string{"orders.>"},
		Storage:     nats.FileStorage,
		Replicas:    3,
		Duplicates:  5 * time.Minute,           // 5-minute server-side deduplication window
		MaxAge:      24 * time.Hour,            // Retain events for 24 hours
		MaxBytes:    100 * 1024 * 1024 * 1024,  // 100 GB storage cap
		Retention:   nats.LimitsPolicy,         // Drop oldest messages when limits are reached
		Discard:     nats.DiscardOld,
	}

	info, err := c.JS.AddStream(cfg)
	if err != nil {
		// If stream already exists, attempt to update configuration cleanly
		info, err = c.JS.UpdateStream(cfg)
		if err != nil {
			return fmt.Errorf("failed to create or update ORDERS stream: %w", err)
		}
	}

	log.Printf("[INFO] JetStream stream 'ORDERS' provisioned. State: %d msgs, %d bytes",
		info.State.Msgs, info.State.Bytes)
	return nil
}

Các Thông Số Cấu Hình Trọng Yếu Của JetStream Stream

• Duplicates: 5 * time.Minute: Thiết lập cửa sổ thời gian trượt (sliding time window) mà trong đó JetStream Server theo dõi các mã định danh thông điệp duy nhất (Nats-Msg-Id). Các thông điệp gửi lặp lại có ID giống hệt nhau trong cửa sổ này sẽ được nhận diện và không bị ghi lặp vào nhật ký stream.
• Storage: nats.FileStorage: Đảm bảo các sự kiện trong stream được ghi bền vững xuống ổ đĩa NVMe/SSD phục vụ khả năng khôi phục khi gặp sự cố, thay vì lưu tạm trên RAM (MemoryStorage).
• Replicas: 3: Phân tán nhật ký thông điệp qua ba node NATS độc lập sử dụng cơ chế đồng thuận Raft để đảm bảo khả năng chịu lỗi và tính sẵn sàng cao tuyệt đối.

4. Xây Dựng Phía Command: Thực Thi Biến Đổi Dữ Liệu & Xuất Bản Sự Kiện

Phía ghi (Write Side) của microservice CQRS tiếp nhận các lệnh thao tác miền (domain commands), thực thi các điều kiện ràng buộc nghiệp vụ, cập nhật cơ sở dữ liệu quan hệ cục bộ, và phát tán các sự kiện nghiệp vụ lên luồng stream.

Để ngăn chặn hoàn toàn nguy cơ trùng lặp thông điệp khi xảy ra cơ chế retry do chập chờn mạng giữa Command Service và NATS JetStream, chúng ta gắn tiêu đề Nats-Msg-Id vào từng thông điệp gửi đi. Khi JetStream phát hiện một Nats-Msg-Id trùng lặp trong cửa sổ lọc trùng, nó sẽ gửi xác nhận PubAck ngay với số thứ tự sequence hiện hành mà không tạo thêm bản ghi mới trong nhật ký stream.

Đoạn mã dưới đây hiện thực hóa handler xử lý CreateOrderCommand hoàn chỉnh trong Go, tích hợp commit transaction cơ sở dữ liệu kết hợp xuất bản sự kiện JetStream có lọc trùng:

package main

import (
	"context"
	"database/sql"
	"encoding/json"
	"fmt"
	"log"
	"time"

	"github.com/google/uuid"
	"github.com/nats-io/nats.go"
)

type CreateOrderCommand struct {
	CustomerID string   `json:"customer_id"`
	Amount     float64  `json:"amount"`
	Items      []string `json:"items"`
}

type OrderCreatedEvent struct {
	EventID    string    `json:"event_id"`
	OrderID    string    `json:"order_id"`
	CustomerID string    `json:"customer_id"`
	Amount     float64   `json:"amount"`
	OccurredAt time.Time `json:"occurred_at"`
}

type OrderCommandHandler struct {
	db *sql.DB
	js nats.JetStreamContext
}

func NewOrderCommandHandler(db *sql.DB, js nats.JetStreamContext) *OrderCommandHandler {
	return &OrderCommandHandler{db: db, js: js}
}

// HandleCreateOrder executes write-side DB transaction and publishes event to JetStream with deduplication.
func (h *OrderCommandHandler) HandleCreateOrder(ctx context.Context, cmd CreateOrderCommand) (string, error) {
	orderID := fmt.Sprintf("ORD-%s", uuid.New().String())
	eventID := fmt.Sprintf("evt_%s", uuid.New().String())

	// 1. Transactional Write to PostgreSQL Write Model
	tx, err := h.db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})
	if err != nil {
		return "", fmt.Errorf("failed to begin transaction: %w", err)
	}
	defer tx.Rollback()

	query := `INSERT INTO orders (id, customer_id, amount, status, created_at) VALUES ($1, $2, $3, $4, $5)`
	if _, err := tx.ExecContext(ctx, query, orderID, cmd.CustomerID, cmd.Amount, "PENDING", time.Now().UTC()); err != nil {
		return "", fmt.Errorf("failed to persist order to write DB: %w", err)
	}

	if err := tx.Commit(); err != nil {
		return "", fmt.Errorf("failed to commit order transaction: %w", err)
	}

	// 2. Build Domain Event Payload
	event := OrderCreatedEvent{
		EventID:    eventID,
		OrderID:    orderID,
		CustomerID: cmd.CustomerID,
		Amount:     cmd.Amount,
		OccurredAt: time.Now().UTC(),
	}

	payload, err := json.Marshal(event)
	if err != nil {
		return "", fmt.Errorf("failed to marshal order event: %w", err)
	}

	// 3. Publish to NATS JetStream with Nats-Msg-Id Header for Server-Side Deduplication
	msg := &nats.Msg{
		Subject: "orders.created",
		Data:    payload,
		Header:  make(nats.Header),
	}
	// Nats-Msg-Id header instructs JetStream broker to execute deduplication check
	msg.Header.Set("Nats-Msg-Id", eventID)

	pubAck, err := h.js.PublishMsg(msg, nats.Context(ctx))
	if err != nil {
		return "", fmt.Errorf("failed to publish OrderCreatedEvent to JetStream: %w", err)
	}

	if pubAck.Duplicate {
		log.Printf("[WARN] Duplicate event publish detected by JetStream for EventID: %s", eventID)
	} else {
		log.Printf("[INFO] Published OrderCreatedEvent to stream %s (Seq: %d, EventID: %s)",
			pubAck.Stream, pubAck.Sequence, eventID)
	}

	return orderID, nil
}

Transactional Outbox Pattern vs. Direct JetStream Publishing

In critical enterprise domains, such as a hệ thống Core Banking hiện đại, directly publishing events after database transaction commits introduces a subtle race condition: if the process crashes immediately after tx.Commit() but before js.PublishMsg(), the database record is updated, but no event is emitted to JetStream.

To achieve 100% atomicity between database updates and event publishing, teams implement the Transactional Outbox Pattern: domain events are written to an outbox table within the same database transaction. A separate Outbox CDC (Change Data Capture) publisher service reads outbox entries and relays them to NATS JetStream with Nats-Msg-Id deduplication headers.

5. Xây Dựng Event Consumer Lũy Nghiệm & Cập Nhật Mô Hình Chiếu Đọc

While JetStream enforces deduplication on the publishing side, distributed systems can still experience redeliveries due to network disruptions during consumer ACKs. To maintain strict consistency in read projections, consumer workers must implement at-least-once idempotency guards.

Durable pull subscribers offer significant operational advantages over push consumers by allowing Go worker pools to explicitly request batches of messages via sub.Fetch(batchSize). This prevents worker pods from being overwhelmed during unexpected load spikes and ensures natural backpressure management.

The Go implementation below features a durable pull subscriber worker that consumes OrderCreatedEvent messages, checks idempotency using an atomic Redis SETNX lock, updates the Redis read projection, and executes explicit message acknowledgments:

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"time"

	"github.com/go-redis/redis/v8"
	"github.com/nats-io/nats.go"
)

type ReadProjectionWorker struct {
	js   nats.JetStreamContext
	rdb  *redis.Client
	sub  *nats.Subscription
	stop chan struct{}
}

func NewReadProjectionWorker(js nats.JetStreamContext, rdb *redis.Client) (*ReadProjectionWorker, error) {
	// Create durable pull subscriber on subject "orders.created"
	sub, err := js.PullSubscribe("orders.created", "read-projection-cqrs",
		nats.ManualAck(),
		nats.AckWait(10*time.Second),
		nats.MaxDeliver(5),
	)
	if err != nil {
		return nil, fmt.Errorf("failed to create durable pull subscription: %w", err)
	}

	return &ReadProjectionWorker{
		js:   js,
		rdb:  rdb,
		sub:  sub,
		stop: make(chan struct{}),
	}, nil
}

func (w *ReadProjectionWorker) Start(ctx context.Context, batchSize int) {
	log.Printf("[INFO] Starting Read Projection Worker (Batch Size: %d)...", batchSize)

	for {
		select {
		case <-ctx.Done():
			log.Println("[INFO] Shutting down read projection worker context")
			return
		case <-w.stop:
			return
		default:
			// Fetch batch of messages with strict wait timeout
			msgs, err := w.sub.Fetch(batchSize, nats.MaxWait(2*time.Second))
			if err != nil {
				if err == nats.ErrTimeout {
					continue
				}
				log.Printf("[ERROR] Pull fetch error: %v", err)
				time.Sleep(500 * time.Millisecond)
				continue
			}

			for _, msg := range msgs {
				w.processMessage(ctx, msg)
			}
		}
	}
}

func (w *ReadProjectionWorker) processMessage(ctx context.Context, msg *nats.Msg) {
	var event OrderCreatedEvent
	if err := json.Unmarshal(msg.Data, &event); err != nil {
		log.Printf("[ERROR] Malformed event payload: %v. Sending Term (no redelivery)", err)
		msg.Term() // Do not attempt redelivery for malformed payloads
		return
	}

	// 1. Consumer-Side Idempotency Guard using Atomic Redis SETNX
	lockKey := fmt.Sprintf("event_lock:%s", event.EventID)
	acquired, err := w.rdb.SetNX(ctx, lockKey, "1", 24*time.Hour).Result()
	if err != nil {
		log.Printf("[ERROR] Redis connection error during SETNX check: %v", err)
		msg.NakWithDelay(1 * time.Second) // Request redelivery with backoff
		return
	}

	if !acquired {
		log.Printf("[INFO] Duplicate event skipped by consumer guard: %s", event.EventID)
		msg.Ack()
		return
	}

	// 2. Update Read-Optimized Model in Redis (Query Projection)
	viewKey := fmt.Sprintf("order_view:%s", event.OrderID)
	viewData := map[string]interface{}{
		"order_id":    event.OrderID,
		"customer_id": event.CustomerID,
		"amount":      event.Amount,
		"status":      "CREATED",
		"updated_at":  event.OccurredAt.Format(time.RFC3339),
	}

	if err := w.rdb.HSet(ctx, viewKey, viewData).Err(); err != nil {
		log.Printf("[ERROR] Failed to update Redis read projection: %v", err)
		// Release lock key so message retry can re-attempt processing
		w.rdb.Del(ctx, lockKey)
		msg.NakWithDelay(1 * time.Second)
		return
	}

	// 3. Acknowledge JetStream Message upon successful read model update
	if err := msg.Ack(); err != nil {
		log.Printf("[ERROR] Failed to ACK message: %v", err)
	}
}

For alternative event bus abstractions and sidecar deployment models, compare this approach with our analysis of phương pháp Event-Driven Architecture với Dapr.

6. Tinh Chỉnh Production & Đo Lường Benchmark Hiệu Năng Thực Tế

To quantify the performance advantages of NATS JetStream against Apache Kafka in a Go microservices environment, we executed benchmark tests under sustained workloads.

Benchmark Setup & Methodology

• Workload Target: 100,000 events/second steady throughput, 1 KB message payload size.
• Cluster Environment: 3-node Kubernetes cluster (v1.30), 8 vCPUs, 16 GB RAM per node, NVMe block storage.
• SDK Benchmarks: Pure Go nats.go (v1.34) versus confluent-kafka-go (v2.3.0 with librdkafka C-bindings).

NATS JetStream vs. Apache Kafka Benchmark Comparison

High-Throughput Optimization: Zero-Allocation Buffer Recycling with sync.Pool

Under heavy transaction volume (>100,000 TPS), frequent allocations of temporary byte buffers for JSON serialization trigger Go garbage collection pause spikes. By recycling bytes.Buffer objects using sync.Pool, high-throughput Go microservices achieve zero-allocation serialization in hot execution paths:

package main

import (
	"bytes"
	"encoding/json"
	"sync"
)

// bufPool recycles bytes.Buffer instances to eliminate heap allocations under high TPS.
var bufPool = sync.Pool{
	New: func() any {
		return new(bytes.Buffer)
	},
}

func getBuffer() *bytes.Buffer {
	buf := bufPool.Get().(*bytes.Buffer)
	buf.Reset()
	return buf
}

func putBuffer(buf *bytes.Buffer) {
	bufPool.Put(buf)
}

// FastMarshal encodes structs into recycled buffers, bypassing heap allocations.
func FastMarshal(v any) ([]byte, error) {
	buf := getBuffer()
	defer putBuffer(buf)

	if err := json.NewEncoder(buf).Encode(v); err != nil {
		return nil, err
	}
	
	// Copy buffer bytes to return slice
	res := make([]byte, buf.Len())
	copy(res, buf.Bytes())
	return res, nil
}

Section 7: So Sánh Hiệu Năng & Tài Nguyên: NATS JetStream vs. Apache Kafka vs. RabbitMQ Streams

Dưới đây là bảng đo lường hiệu năng và tiêu thụ tài nguyên thực tế giữa các hệ thống truyền thông điệp phân tán trong môi trường Golang Microservices:

❓ Câu Hỏi Thường Gặp (FAQ)

🔗 Đọc Thêm Các Chuyên Đề & Series Liên Quan

• Làm Chủ Kiến Trúc Hướng Sự Kiện với Dapr
• Kiến Trúc Microservices Ngân Hàng: Go, Saga & Event Sourcing
• Kiến trúc Phân tán Tracing Go Microservices (2026)
• High-Throughput Go Framework Benchmarks: Gin, Fiber, Kratos
• Building High-Throughput Event-Driven Microservices in Go (English)