Trong các hệ thống microservices hiện đại, Kafka đóng vai trò trung tâm trong việc truyền tải sự kiện, đồng bộ dữ liệu, và xử lý bất đồng bộ (async workflow).
Một trong những quyết định quan trọng khi thiết kế kiến trúc streaming là chọn định dạng message: dùng Text/JSONhay Binary (Avro/Protobuf/MessagePack/byte array)?

Bài viết này phân tích sâu mục đích, ưu – nhược điểm của từng loại, và gợi ý cách chọn phù hợp cho từng loại hệ thống.

1. Message Text/JSON – Khi nào và tại sao nên dùng?

Message dạng text hoặc JSON là lựa chọn phổ biến nhất hiện nay trong microservices, không chỉ vì dễ đọc mà còn vì độ linh hoạt cao.

Mục đích chính

• Dễ debug
• Dễ tích hợp với nhiều công nghệ
• Không cần schema registry
• Dễ dàng mở rộng và thay đổi payload

 Ưu điểm

1) Human-readable

Bạn có thể mở log Kafka, copy JSON event ra và hiểu ngay nội dung.
Điều này đặc biệt hữu ích cho team vận hành, QA và developer mới.

2) Linh hoạt, thay đổi dễ dàng

Không cần build lại toàn bộ hệ thống nếu payload thay đổi.

Ví dụ: thêm "source" hoặc "metadata" vào event → service khác vẫn có thể bỏ qua nếu không cần.

3) Tương thích tốt giữa nhiều ngôn ngữ

JSON là “ngôn ngữ chung” của hệ thống phân tán.
Python, Java, Go, Node.js… đều hỗ trợ native.

4) Dễ test & replay

Bạn chỉ cần một file .json là có thể replay event vào Kafka.

Nhược điểm

1) Tốn dung lượng hơn

Vì là text nên JSON thường lớn hơn 30–60% so với binary.

2) Parse chậm hơn

Mất thêm CPU khi convert từ text → object.

3) Không có schema strict

Dễ bị lỗi kiểu dữ liệu: string, number, null không đúng format.

4) Không phù hợp high-throughput rất lớn

Khi hệ thống đẩy hàng trăm nghìn message/giây, JSON bắt đầu trở nên đắt đỏ.

2. Message Binary – Tại sao nhiều hệ thống lớn dùng Avro/Protobuf?

Binary serialization như Protobuf, Avro, Thrift, MessagePack nhắm đến hiệu năng và tính nhất quán dữ liệu.

Mục đích chính

• Giảm kích thước event
• Tăng tốc độ serialize/deserialize
• Bắt lỗi dữ liệu từ sớm (schema validation)
• Tối ưu hệ thống throughput rất lớn

Ưu điểm

1) Hiệu năng vượt trội

Binary format nhanh hơn JSON từ 2–10 lần tuỳ use-case.

2) Payload nhỏ hơn đáng kể

• JSON: { "id": "12345", "status": "OK" } → ~40 bytes
• Protobuf: chỉ khoảng ~12 bytes

Giảm cost cho:

• Kafka disk (log retention)
• Network bandwidth
• Consumer throughput

3) Schema strict & versioning mạnh mẽ

Protobuf / Avro hỗ trợ:

• Backward compatibility
• Forward compatibility
• Kiểm tra kiểu từ producer → tránh event rác

4) Phù hợp high-volume real-time

Những hệ thống đẩy hàng trăm nghìn message/giây như:

• Payment real-time
• Market data feed
• Fraud detection
• IoT stream ingest
• Logs/metrics pipeline

… gần như đều dùng binary.

Nhược điểm

1) Không đọc trực tiếp được

Message hiển thị dạng byte → khó debug nếu không decode.

2) Yêu cầu thêm tooling

• Schema Registry
• Plugin build (Avro plugin, Protobuf compiler)
• Tool decode binary

3) Tích hợp khó hơn JSON

Các ngôn ngữ cần lib tương ứng.

4) Tăng độ phức tạp vận hành

Team mới sẽ gặp khó khăn trong troubleshooting.

3. Bảng so sánh tổng hợp Text/JSON vs Binary

Tiêu chí	JSON	Binary (Protobuf/Avro)
Khả năng đọc (debug)	⭐⭐⭐⭐⭐	⭐
Hiệu năng	⭐⭐	⭐⭐⭐⭐⭐
Kích thước message	Lớn	Nhỏ
Linh hoạt thay đổi	Rất linh hoạt	Phụ thuộc schema
Dễ tích hợp hệ thống	⭐⭐⭐⭐⭐	⭐⭐
Yêu cầu schema registry	Không	Có
Độ phức tạp	Thấp	Cao
Phù hợp cho	Microservices thông thường	High-throughput systems

4. Khi nào nên chọn JSON?

JSON phù hợp khi:

• Payload phức tạp và thay đổi thường xuyên
• Đội ngũ cần xem log dễ dàng
• Tốc độ không quá lớn (< 50K msg/s)
• Hệ thống phong phú ngôn ngữ (Java, Node.js, Go…)

Use-case điển hình:

• Notification service (email, push, SMS)
• User activity tracking
• Order events của business
• Audit logs
• Workflow orchestration

5. Khi nào nên chọn Binary?

Nên dùng binary khi:

• Cần hiệu năng cao
• Cần schema strict
• Dữ liệu lớn, event nhiều
• Throughput cực cao
• Chi phí Kafka quan trọng

Use-case điển hình:

• Payment processing event
• Banking transaction pipeline
• Market tick data
• Fraud detection (real-time ML features)
• Ad clickstream
• IoT device event stream

6. Lời khuyên thực chiến: Định dạng nào cho hệ thống Notification Retry?

Trong hệ thống notification gồm:

• Producer gửi event async
• Consumer xử lý → retry scheduler nếu failed

👉 JSON gần như là lựa chọn tốt nhất, vì:

• Payload linh hoạt (SMS/email/push template khác nhau)
• Dễ debug khi xử lý lỗi
• Dễ phân tích log retry
• Không cần schema cứng

Bạn chỉ nên dùng Binary nếu:

• Notification volume > 100k msg/s
• Nội dung tương đối chuẩn hoá (template-based)
• Hệ thống đa phần nằm trong nhà (internal microservices)

Kết luận

Không có lựa chọn “tốt nhất cho mọi trường hợp”.
Bạn nên chọn dựa trên đặc tính hệ thống, mục tiêu vận hành, và độ phức tạp chấp nhận được.

✔ JSON = dễ dùng, linh hoạt, debug đơn giản

✔ Binary = hiệu năng, tối ưu, quy mô lớn

Nếu system của bạn ưu tiên tốc độ phát triển & dễ bảo trì → JSON
Nếu system của bạn ưu tiên performance & throughput → Binary