Vấn đề mà Kafka sinh ra để giải quyết

Hãy tưởng tượng một hệ thống e-commerce. Khi user đặt hàng, cùng lúc bạn cần:

• Gửi email xác nhận đơn hàng
• Trừ tồn kho trong warehouse service
• Tạo shipment trong logistics service
• Ghi nhận doanh thu trong analytics
• Gửi notification đến app

Cách thông thường: Order Service gọi thẳng API đến từng service. Đây là synchronous coupling — nếu Notification Service chậm 2 giây, cả order flow chậm 2 giây. Nếu Analytics Service down, order fail.

Kafka giải quyết tất cả bằng một ý tưởng đơn giản: thay vì gọi trực tiếp, producer ghi event vào log — consumer tự đọc khi ready. Decoupled hoàn toàn.

Kafka là gì — định nghĩa đúng nhất

Apache Kafka là một distributed event streaming platform — không phải message queue truyền thống (như RabbitMQ), không phải database, không phải cache. Cách gọi chính xác nhất: distributed commit log.

Điểm khác biệt lớn nhất với message queue: consumer tự quản lý vị trí đọc (offset). Kafka không biết và không quan tâm consumer đã đọc đến đâu — đó là trách nhiệm của consumer. Điều này cho phép replay event, thêm consumer mới đọc lại lịch sử, hoặc nhiều consumer group độc lập đọc cùng một topic.

Core concepts

Architecture tổng quan

Flow dữ liệu trong Kafka:

ZooKeeper vs KRaft

Kafka cổ điển dùng ZooKeeper để quản lý metadata và leader election. Từ Kafka 3.3+, mode KRaft (Kafka Raft) cho phép chạy không cần ZooKeeper — đơn giản hơn cho việc setup và vận hành. Từ Kafka 4.0, ZooKeeper bị deprecated hoàn toàn.

Partition — bí mật sau scalability

Partition là khái niệm quan trọng nhất để hiểu Kafka. Mỗi topic order-events với 3 partitions trông như sau:

Ordering guarantee: Thứ tự chỉ được đảm bảo trong cùng một partition. Nếu bạn cần tất cả event của một order theo đúng thứ tự, dùng order_id làm key — Kafka sẽ hash key và route tất cả event có cùng key về một partition.

Parallelism: Consumer group với 3 consumer + topic với 3 partition = mỗi consumer đọc đúng 1 partition song song. Thêm consumer thứ 4 → consumer thứ 4 idle (số consumer không thể vượt số partition).

Kafka vs RabbitMQ vs Redis Pub/Sub

Tiêu chí	Kafka	RabbitMQ	Redis Pub/Sub
Mô hình	Distributed log (pull)	Message queue (push/pull)	Pub/Sub (push, fire-and-forget)
Retention	Lâu dài (7 ngày mặc định)	Đến khi consumer ack	Không lưu — mất nếu consumer offline
Replay	Có — seek đến bất kỳ offset	Không	Không
Throughput	Rất cao (triệu msg/s)	Cao (100K msg/s)	Cao nhưng không bền
Ordering	Trong mỗi partition	Trong queue (single consumer)	Không đảm bảo
Multiple consumers	Nhiều group độc lập	Competing consumers (chia nhau)	Nhiều subscriber nhận cùng msg
Độ phức tạp	Cao — cần hiểu partition, offset	Thấp — AMQP đơn giản	Rất thấp
Best for	Event streaming, audit log, CDC	Task queue, RPC, routing phức tạp	Realtime notification, simple fanout

Use cases thực tế

Khi nào KHÔNG nên dùng Kafka

• Team nhỏ, cần ship nhanh — Kafka có operational overhead cao. RabbitMQ hoặc SQS đơn giản hơn nhiều.
• Request-response / RPC — Kafka không phù hợp cho pattern "gửi rồi chờ response". Dùng HTTP/gRPC.
• Dataset nhỏ, ít message — Setup Kafka cho vài nghìn message/ngày là over-engineering. PostgreSQL LISTEN/NOTIFY hoặc Redis đủ dùng.
• Cần message routing phức tạp — Routing theo header, priority queue, dead-letter queue — RabbitMQ làm tốt hơn.
• Latency cực thấp (< 1ms) — Kafka batch-oriented, latency thường 5-15ms. Nếu cần sub-ms thì cần giải pháp khác.