Lesson 16 · Senior Kafka practice

Reviewing Kafka designs like a senior engineer

How to judge whether a Kafka design is truthful about durability, liveness, ordering, and operational trade-offs.

Your win: review Kafka designs for hidden trade-offs, weak assumptions, and false confidence instead of stopping at “it uses Kafka.”

In plain English Plain English: a senior review asks what this Kafka design really guarantees, what it does not guarantee, and where it may fail under pressure.

Why Kafka review is its own skill

A design can use all the right words — partitions, retries, idempotency, DLQ, exactly-once — and still be misleading. Senior review is the skill of checking whether those words connect to real guarantees.

That is why this page matters. Many weak Kafka designs do not fail because the author forgot terminology. They fail because the claimed guarantee is stronger than the implementation actually supports.

The review question What does this design really guarantee about durability, ordering, replay, and liveness — and what is it quietly trading away?

What strong review comments usually target

ordering claims that do not match the key or partition strategy
durability claims that ignore acks reality
retry flows that never explain poison-message handling
idempotency assumptions with no concrete dedupe boundary
consumer-scaling claims that ignore partition count or hotspot risk

The best review comments make the hidden contract explicit. They turn “Kafka will handle it” into “which exact behavior are we relying on, and where is that behavior enforced?”

Backend use case This lesson helps you review repo Kafka changes with sharper questions about RequireOne, AlwaysCommit(), lane design, retry loops, and missing DLQ behavior.

Common mistake Letting a Kafka design sound stronger than it is because the terminology sounds advanced and the happy path feels plausible.

Use the repo map as a review anchor

The strongest Kafka reviews in this repo start by checking claims against the actual wrapper behavior and service usage captured in the map.

→ Repo Kafka map
→ docs/kafka/lessons/0011-failure-modes.html

Check yourself (from memory)

Q1. What is the most senior review question for a Kafka design?

Senior review is about truthfulness of guarantees, not vocabulary coverage.

What should a senior engineer ask when reviewing a Kafka design?

recall, then click to reveal

What does this design really guarantee about durability, ordering, replay, and liveness, and where are the important trade-offs or failure gaps still unresolved?

Want a compact PR-review checklist for Kafka-backed designs in this repo? Ask me.

Sources. Repo Kafka map; existing Kafka lessons; curated design resources.