Đã đăng vào Thứ Bảy, 7:31 SA 20 phút đọc

Kafka: Những bài học chỉ Production mới dạy bạn

Lời mở đầu

Không có tutorial Kafka nào chuẩn bị cho bạn cảm giác 2 giờ sáng bị gọi dậy vì consumer lag tăng không kiểm soát. Bạn mở Grafana, thấy offset đứng im như tượng đồng. Bạn restart pod - lag tụt một chút rồi lại bám chặt. Bạn scale thêm consumer - năm phút sau, cả group rebalance liên tục, throughput rơi về 0. Cả hệ thống chết lâm sàng vì một vài message lỗi.

Kafka trên slide lúc nào cũng sạch sẽ hoàn hảo: at-least-once, offset, partition, consumer group, retry. Mọi ví dụ đều gọn gàng, mọi flow đều "happy path", mọi lỗi đều được xử lý trong 3 dòng code.

Kafka trong production thì khác. Nó không quan tâm bạn đọc documentation kỹ đến đâu. Nó chỉ quan tâm bạn commit offset sai chỗ nào, block poll thread bao lâu, và retry thiếu kiểm soát ra sao. Nó là chiến trường nơi lý thuyết gặp thực tế, nơi "it works on my machine" bị đập tan thành từng mảnh.

Bài này không dạy bạn Kafka API - đã có hàng trăm tutorial làm việc đó. Bài này ghi lại những bài học xương máu chỉ có được sau vài incident thật sự, khi dữ liệu bị duplicate vô tội vạ, message biến mất không dấu vết, và cả hệ thống đứng hình chỉ vì một message tưởng chừng rất nhỏ. Đây là những thứ không có trong documentation chính thức, nhưng lại quyết định sự sống còn của hệ thống của bạn.

1. Một message lỗi có thể làm nghẽn cả hệ thống

Hầu hết tutorial đều dạy bạn viết consumer handler theo một công thức rất đẹp mắt: deserialize message, gọi service xử lý business, nếu lỗi thì throw exception. Code nhìn gọn gàng, chạy local mượt mà, QA test cũng không phát hiện vấn đề gì.

Production sẽ tặng bạn một bài học đắt giá: chỉ cần một message có payload "bẩn" — JSON sai schema, field null bất ngờ, enum value không map được — handler của bạn throw exception. Spring Kafka retry message đó (nếu được cấu hình). Handler lại throw. Vòng lặp này tiếp tục cho đến khi... bạn phải can thiệp thủ công.

Phân biệt lỗi là kỹ năng sống còn:

Lỗi permanent (không thể retry): Lỗi parse JSON, schema violation, validation error, business logic error. Retry 1.000 lần cũng không làm JSON đó hợp lệ hơn. Đây là những lỗi cần được xử lý ngay và đưa vào Dead Letter Queue.
Lỗi transient (có thể retry): Lỗi mạng tạm thời, database connection timeout, deadlock ngắn, service dependency tạm thời unavailable. Có khả năng thành công sau một số lần retry có kiểm soát.

Lưu ý quan trọng: Kafka core không có cơ chế retry. Retry là do client libraries như Spring Kafka cung cấp thông qua cơ chế DefaultErrorHandler với RetryTemplate. Nếu không cấu hình đúng, exception sẽ làm consumer loop bị block.

Schema Registry là lá chắn đầu tiên: Sử dụng Schema Registry với compatibility mode STRONG sẽ bắt lỗi schema ngay từ producer side. Message không hợp lệ sẽ bị reject trước khi vào topic, không bao giờ đến được consumer của bạn. Đây là phòng thủ chủ động thay vì xử lý phản ứng.

Xử lý đúng cách ngay từ đầu: Message lỗi permanent phải được đưa ngay vào DLQ kèm đầy đủ metadata - lỗi gì, thời điểm, số lần retry, và quan trọng nhất: có thể replay được không. Đừng để một message lỗi block cả partition, commit offset của nó sau khi đã xử lý thích hợp để consumer có thể tiếp tục.

2. Rebalance có thể phá nát throughput

Rebalance là cơ chế Kafka phân phối lại partition cho các consumer khi có sự thay đổi trong group. Trong production, rebalance xảy ra thường xuyên hơn bạn nghĩ: deploy mới, pod restart, network blip nhẹ, consumer chậm xử lý.

Sai lầm chết người: Bạn block xử lý message quá lâu trong poll thread, vượt quá max.poll.interval.ms (thường là 5 phút). Broker không thấy heartbeat, nghĩ consumer "chết", kick khỏi group → trigger rebalance toàn bộ. Trong thời gian rebalance (có thể vài chục giây đến vài phút), không có message nào được xử lý, throughput về 0.

Static Membership - cứu tinh của stability: Từ Kafka 2.3, bạn có thể cấu hình group.instance.id. Khi consumer restart với cùng instance ID, broker nhận diện được là "bạn cũ" và cho phép rejoining mà không gây rebalance toàn bộ group, miễn là assignment vẫn hợp lệ. Điều này đặc biệt quan trọng trong môi trường container-based deployment nơi pod thường xuyên restart.

Giữ cho poll thread luôn nhẹ nhàng: Poll thread chỉ nên làm một việc - fetch message và gửi heartbeat. Đừng bao giờ xử lý business logic nặng trong thread này. Spring Kafka có ConcurrentKafkaListenerContainerFactory cho phép xử lý song song, nhưng cần hiểu cách nó quản lý offset và thread.

Tối ưu cấu hình động: Giảm max.poll.records khi thấy xử lý chậm, tăng lên khi hệ thống rảnh rỗi. Điều chỉnh fetch.min.bytes và fetch.max.wait.ms để cân bằng giữa latency và throughput theo pattern load thực tế.

3. Retry sai cách sẽ giết downstream

Tutorial thường nói: "Dùng exponential backoff, retry 5 lần là được." Nghe có vẻ hợp lý, cho đến khi bạn đối mặt với thực tế.

Production scenario kinh điển: Downstream service có timeout 2 giây. Có 1.000 message cùng gọi endpoint đó. Mỗi message retry 5 lần = 5.000 request dồn dập trong vài phút. Downstream service chết hẳn → tất cả message fail → retry tiếp → tạo thành retry storm phá hủy hoàn toàn downstream service.

Retry trong Spring Kafka là client-side: Spring Kafka cung cấp RetryTemplate với ExponentialBackOffPolicy hoặc FixedBackOffPolicy. Nhưng retry ngay lập tức trong cùng consumer thread có thể gây blocking và rebalance.

Retry pipeline độc lập - giải pháp trưởng thành:

Main consumer chỉ xử lý message thành công ngay lần đầu
Khi gặp lỗi transient → produce vào Retry Topic với timestamp delay (5s, 30s, 2 phút, 10 phút...)
Retry consumer riêng biệt xử lý message từ Retry Topic sau khoảng delay định trước
Sau N lần retry thất bại → đẩy vào DLQ để manual inspection

Spring Kafka có sẵn retry với backoff: Có thể cấu hình DefaultErrorHandler với FixedBackOff hoặc ExponentialBackOff. Nhưng cẩn thận: retry quá nhiều lần trong cùng thread sẽ block processing các message khác.

Circuit breaker - không phải luxury mà là necessity: Theo dõi tỷ lệ lỗi real-time. Khi tỷ lệ lỗi vượt ngưỡng (ví dụ: 50% trong 1 phút), tự động tạm ngừng retry, chuyển thẳng message vào DLQ. Đừng đánh bầm dập một service đang chết.

Jitter trong backoff: Thêm randomness vào retry interval để tránh hiện tượng "thundering herd" - tất cả retry cùng xảy ra một lúc sau mỗi chu kỳ.

4. Consumer không thread-safe - commit offset thế nào cho an toàn?

Câu này cần được khắc vào tâm trí: Kafka consumer client KHÔNG thread-safe.

Sai lầm phổ biến nhất: Xử lý message trong thread pool, rồi commit offset từ worker thread → race condition → commit sai offset → mất message hoặc duplicate message hàng loạt. Bạn sẽ không biết điều này xảy ra cho đến khi khách hàng phàn nàn về dữ liệu bị thiếu hoặc trùng lặp.

Spring Kafka quản lý offset tự động nhưng...: Với @KafkaListener và AckMode mặc định (BATCH), Spring tự động commit offset sau khi xử lý xong batch. Nhưng nếu bạn xử lý async với @Async hoặc thread pool mà không quản lý offset thủ công, sẽ gặp vấn đề.

Mô hình commit an toàn trong production với Spring Kafka:

AckMode thông minh:

RECORD: commit sau mỗi message → overhead cao, nhưng an toàn nhất
BATCH: commit sau mỗi batch → cân bằng tốt, nhưng nếu có lỗi trong batch, cả batch sẽ bị retry
MANUAL/MANUAL_IMMEDIATE: commit thủ công khi bạn ready → linh hoạt nhất, nhưng cần code cẩn thận

Quản lý offset theo thứ tự trong partition: Kafka chỉ đảm bảo ordering trong một partition. Offset phải được commit theo thứ tự tăng dần. Nếu xử lý song song nhiều message từ cùng partition, cần đảm bảo commit đúng thứ tự.

Chỉ một luồng được commit: Khi dùng ConcurrentMessageListenerContainer, mỗi partition được xử lý bởi một thread riêng. Spring quản lý điều này tốt, nhưng nếu bạn tự tạo thread pool, phải đảm bảo mỗi partition chỉ có một thread xử lý.

5. Producer: Idempotence, Transaction và Outbox Pattern

producer.send(record) trong tutorial khác xa producer.send(record) trong production.

Ba lớp phòng thủ cho producer:

Idempotence - lớp cơ bản: Luôn bật enable.idempotence=true. Tính năng này gán mỗi producer một ID và đánh số sequence cho mỗi message, giúp broker phát hiện và loại bỏ duplicate do producer retry (trong cùng một producer session). Đây là tính năng "phải có" chứ không phải "nên có".

Transaction - cho cross-partition atomicity: Spring Kafka hỗ trợ transaction thông qua KafkaTransactionManager. Khi bạn cần atomicity across multiple partitions/topics - ví dụ: consume một message từ input topic và produce message sang output topic trong cùng một transaction. Transaction đảm bảo all-or-nothing semantics. Nhưng nhớ: transaction có overhead, chỉ dùng khi thật sự cần.

Outbox Pattern - giải quyết bài toán kinh điển: Đây là mô hình quan trọng nhất cho hệ thống distributed transaction. "Commit database trước hay send Kafka message trước?" - Outbox Pattern trả lời: cả hai, nhưng theo thứ tự đúng.

Trong cùng một database transaction với business logic, write event vào bảng outbox
Commit transaction (business data + outbox record)
Background process (CDC hoặc scheduled job) đọc từ outbox và produce sang Kafka
Mark outbox record là đã published

Đảm bảo: nếu business transaction success → event sẽ được gửi sang Kafka (ít nhất một lần). Pattern này giải quyết vấn đề dual-write mà không cần distributed transaction phức tạp.

6. Race condition mà tutorial không bao giờ nói

Kafka chỉ đảm bảo ordering trong một partition, không đảm bảo ordering theo logic business của bạn.

Scenario kinh điển gây đau đầu: Message A (update order status = "PROCESSING") và message B (update order status = "COMPLETED") cho cùng order_id=123. Nếu chúng vào hai partition khác nhau do hash key khác nhau, consumer xử lý song song → message B có thể được xử lý trước message A → order status nhảy từ "PENDING" thẳng sang "COMPLETED" rồi mới về "PROCESSING".

Partition key strategy - chìa khóa của ordering: Luôn sử dụng entity_id làm partition key cho tất cả message liên quan đến cùng entity. Điều này đảm bảo tất cả event cho cùng entity đến cùng partition, được xử lý tuần tự.

Idempotent processing - phòng thủ cuối cùng: Ngay cả với ordering trong partition, vẫn có thể có duplicate do retry. Sử dụng version number hoặc conditional update trong database:

UPDATE orders 
SET status = 'COMPLETED', version = 2
WHERE order_id = 123 AND version = 1;

Nếu update này fail (version không khớp), bạn biết đã có concurrent update và cần xử lý conflict.

Debezium/CDC khi cần strong ordering: Đôi khi, thay vì produce event từ application code, hãy xem xét dùng Change Data Capture (Debezium) để stream database change event. CDC đảm bảo ordering theo thứ tự commit trong database, thường là giải pháp mạnh mẽ nhất cho event ordering.

7. Observability: Bạn không thể debug cái bạn không measure

Lag metric từ Kafka (consumer lag) là cần thiết nhưng không đủ. Nó giống như chỉ nhìn đồng hồ tốc độ mà không biết xe đang ở đâu, xăng còn bao nhiêu, hay động cơ có quá nóng không.

Production observability checklist:

Distributed Tracing là bắt buộc: Inject trace-id vào message header ở producer, truyền qua tất cả consumer, service call, database query. Spring Cloud Sleuth hoặc Micrometer Tracing làm điều này tốt.

Business Metrics - đo lường điều quan trọng thật sự:

Số message xử lý thành công/thất bại mỗi phút, phân loại theo error type
Thời gian xử lý trung bình, p95, p99 (để phát hiện outlier)
Tỷ lệ message vào DLQ, Retry Topic
End-to-end latency: từ lúc produce đến lúc consume hoàn tất

Kafka Client Metrics: Spring Kafka tích hợp với Micrometer, expose metrics:

spring.kafka.consumer.records.consumed
spring.kafka.consumer.fetch.manager.records.lag
spring.kafka.producer.record.send.total

Health Check có ý nghĩa: Spring Actuator với HealthContributor cho Kafka. Health check endpoint của consumer không nên chỉ trả về "UP". Nó nên cho biết: consumer có assigned partition không? Có đang rebalance không? Lag có trong ngưỡng cho phép không?

8. DLQ không phải thùng rác

Ngày đầu lên Kafka, team nào cũng rất tự tin: "Có lỗi thì quăng vào DLQ, khỏi block consumer." Thế là mọi exception không xử lý được đều được produce sang một topic tên rất đẹp: order-dlq, payment-dlq.

Ban đầu DLQ trông rất sạch sẽ: mỗi ngày vài chục message. Ba tháng sau: DLQ có vài triệu message. Không ai dám đọc. Không ai dám replay. Không ai dám xóa. DLQ trở thành nghĩa địa message - tốn tài nguyên, tốn tiền storage, và hoàn toàn vô dụng.

Sai lầm nằm ở chỗ: mọi loại lỗi đều bị quăng chung vào một chỗ. Lỗi permanent, lỗi transient, bug trong code, data quality issue - tất cả thành một đống hỗn độn.

Spring Kafka DLQ support: DefaultErrorHandler có thể cấu hình để gửi failed message sang DLQ tự động. Nhưng cần cấu hình đúng:

@Bean
public DefaultErrorHandler errorHandler(KafkaTemplate<String, Object> template) {
    DefaultErrorHandler handler = new DefaultErrorHandler(
        new DeadLetterPublishingRecoverer(template),
        new FixedBackOff(1000L, 3) // retry 3 lần, mỗi lần cách 1 giây
    );
    handler.addNotRetryableExceptions(JsonParseException.class);
    handler.addRetryableExceptions(TimeoutException.class);
    return handler;
}

DLQ chỉ có giá trị khi nó có semantics: Mỗi message trong DLQ phải trả lời được ba câu hỏi:

Vì sao fail? (error category, error message, stack trace)
Fail thuộc loại gì? (permanent/transient, retryable/non-retryable)
Có nên replay không? Và replay thế nào?

Thiết kế DLQ cho production:

Chỉ đẩy permanent error vào DLQ: Transient error đi Retry Topic với backoff strategy. Bug trong code? Fix code rồi replay từ offset cũ, không cần DLQ.

DLQ payload phải giàu metadata: Sử dụng DeadLetterPublishingRecoverer của Spring Kafka, nó tự động thêm headers: kafka_dlt-exception-fqcn, kafka_dlt-exception-message, kafka_dlt-exception-stack-trace, kafka_dlt-original-topic, kafka_dlt-original-partition, kafka_dlt-original-offset.

9. Cấu hình không chỉ là default values

Tutorial nào cũng dùng default config. Production cần tuning dựa trên workload pattern, SLA, và infrastructure.

Những config cần tuning cẩn thận:

max.poll.records - con dao hai lưỡi:

Quá cao: xử lý lâu, dễ vượt max.poll.interval.ms → rebalance
Quá thấp: throughput thấp, network overhead cao
Cách tiếp cận: start với giá trị nhỏ (10-100), monitoring, tăng dần nếu system ổn

fetch.min.bytes vs fetch.max.wait.ms - latency-throughput tradeoff:

fetch.min.bytes=1, fetch.max.wait.ms=500: low latency, high CPU/network
fetch.min.bytes=524288 (512KB), fetch.max.wait.ms=500: batch lớn hơn, throughput cao hơn, latency tăng nhẹ
Tuning dựa trên SLA: real-time system cần low latency, batch processing cần high throughput

session.timeout.ms vs heartbeat.interval.ms - giữ connection sống:

Rule của ngón tay cái: session.timeout.ms = 3 × heartbeat.interval.ms
Môi trường network không ổn định: tăng session.timeout.ms (ví dụ: 30s thay vì 10s)
Nhưng cẩn thận: timeout quá cao → phát hiện consumer chết chậm, partition không được reassign kịp

acks - durability vs latency:

acks=0: fire-and-forget, throughput cao nhất, có thể mất message
acks=1: leader viết xong là reply, cân bằng tốt cho nhiều use case
acks=all: đảm bảo replica viết xong, an toàn nhất, latency cao nhất
Production recommendation: acks=all cho critical data (financial transaction), acks=1 cho phần còn lại

Auto Offset Reset - chỉ dùng trong development:

auto.offset.reset=earliest: development - muốn đọc tất cả data
auto.offset.reset=latest: development - chỉ quan tâm message mới
Production: KHÔNG dùng auto.offset.reset! Luôn quản lý offset thủ công hoặc dùng Spring Kafka's ConsumerSeekAware để điều khiển offset chính xác.

Kết

Kafka không khó. Cách con người dùng Kafka mới khó.

Tutorial dạy bạn API, dạy bạn concept, dạy bạn happy path. Production dạy bạn:

Offset là tiền, rebalance là bão, commit sai là mất tất cả
Retry không phải feature của Kafka core, mà là của client libraries - và là con dao cần được cầm bằng cả hai tay
DLQ không phải thùng rác, mà là phòng cấp cứu cần doctor có chuyên môn
Observability không phải luxury feature, mà là survival skill
Monitoring không phải để ngắm chart đẹp, mà là để ngăn cơn ác mộng lúc 2 giờ sáng

Sửa đổi quan trọng về retry: Cần nhớ rõ - Kafka broker không có cơ chế retry. Retry là do client libraries (Spring Kafka, kafka-python, etc.) cung cấp. Spring Kafka retry là client-side retry: ném exception → Spring catch → retry theo cấu hình → nếu vẫn lỗi thì gửi DLQ hoặc bỏ qua.

Nếu bạn chưa từng mất message, chưa từng duplicate dữ liệu, chưa từng ăn một đợt rebalance storm, thì bạn chưa thật sự dùng Kafka production. Nhưng khi đã trải qua những điều đó - khi đã debug cả đêm, khi đã học cách đọc metric thay vì log, khi đã thiết kế hệ thống với failure là first-class citizen - bạn sẽ hiểu: Kafka production-ready không phải là checklist feature, mà là một mindset.

Mindset của sự khiêm tốn trước độ phức tạp của distributed system. Mindset của phòng thủ nhiều lớp thay vì tin tưởng mù quáng. Mindset của observability-driven development thay vì "it works on my machine".

Kafka cho bạn sức mạnh xử lý hàng triệu message mỗi giây. Nhưng với sức mạnh lớn đến trách nhiệm lớn. Trách nhiệm hiểu hệ thống của mình thật sâu, trách nhiệm thiết kế cho failure, và trách nhiệm không để một message lỗi nhỏ đánh sập cả hệ thống.

Chào mừng đến với thế giới Kafka production - nơi mọi thứ đều có thể fail, và công việc của bạn là đảm bảo khi nó fail, nó fail một cách duyên dáng.