Partitioned log, storage và retention

Kafka lưu records trong ordered partitions và tách consumer progress khỏi data retention. Nhiều consumer applications có thể đọc/replay cùng log mà không làm broker xóa record sau lần đọc đầu tiên.

1. Cluster, metadata và partition ownership

Cluster gồm brokers lưu partition replicas và KRaft controller quorum quản metadata/leadership. Topic chia thành partitions; mỗi partition là append-only ordered log với offsets tăng đơn điệu. Một replica làm leader và producers/consumers giao tiếp theo leadership metadata.

2. Producer write và consumer fetch path

record + key
  -> serializer
  -> partitioner / explicit partition
  -> producer batch + compression
  -> partition leader append
  -> follower replication
  -> consumer fetch(offset, max bytes)
  -> deserialize + process + commit progress

Producer batching và compression amortize network/storage overhead. Consumer pull/fetch cho phép batch size và pace theo capacity. Broker retention độc lập với committed consumer offset; consumer chậm có thể đọc lại nếu data vẫn còn, hoặc gặp out-of-range nếu retention đã xóa segment cần thiết.

3. Segments, indexes và page cache

Partition log được chia thành segment files và sparse indexes để lookup offset/time rồi scan tuần tự. Sequential append, batch I/O, compression và OS page cache tạo throughput; Kafka không “chỉ giữ data trong memory”. Kernel quản cache và dirty pages, còn durable guarantee phụ thuộc replication/acks/configuration.

Fetch có thể tận dụng efficient file-to-network paths tùy platform/encryption. Record quá lớn phá batching, chiếm network/buffer/page cache và kéo tail latency; giới hạn producer, broker, topic và consumer fetch phải tương thích.

4. Retention và log compaction

Delete retention xóa whole segments theo time/size policy, nên record không biến mất chính xác ở TTL từng record. Consumer SLA phải nhỏ hơn retention với headroom cho outage/recovery. Tăng retention làm tăng disk, rebalance/recovery và restore cost.

Log compaction giữ ít nhất latest value theo key trong retained head/tail theo asynchronous cleanup, không phải unique constraint hay snapshot tức thời. Tombstone biểu diễn delete và cũng có retention semantics. Topic có thể dùng delete, compact hoặc cả hai tùy use case.

5. Partition count và key design

Nhiều partitions tăng producer/consumer parallelism nhưng cũng tăng metadata, open files, leader elections, replication traffic và rebalance cost. Consumer group có tối đa một active consumer cho mỗi partition tại một thời điểm; partitions ít có thể giới hạn concurrency.

Key giữ records cùng entity vào cùng partition theo partitioner hiện tại, bảo toàn per-entity ordering. Hot key hoặc skew làm một leader/storage path nóng. Tăng partition count có thể đổi mapping hash→partition cho records mới, nên ordering assumption xuyên thời điểm scale cần strategy riêng.

• Chọn partition count từ throughput, consumer parallelism và growth horizon.
• Đo key distribution, bytes/rate per partition và leader balance.
• Không dùng random key nếu business cần per-entity order.
• Không dùng một constant key nếu không chủ đích serialize toàn workload.

6. Failure modes và evidence

Red flags: retention ngắn hơn maximum recovery lag, partition count thấp, key skew, record quá lớn, compaction key sai, disk không có headroom và assumption global ordering. Theo dõi bytes/records in, request latency, partition size/rate, under-replication, disk utilization, consumer lag và oldest required offset.