Kafka richtig aufsetzen: Topic-Design, Partitionierung und Idempotenz

Fehler in Streaming-Systemen fallen selten sofort auf. Doppelt verarbeitete Events, ein einzelner überlasteter Consumer oder eine Verarbeitung, die immer weiter hinterherhinkt, zeigen sich oft erst, wenn nachgelagerte Daten nicht mehr stimmen. Die meisten dieser Probleme lassen sich schon beim Design der Kafka-Topics verhindern.

Das Wichtigste in Kürze

• Jedes Kafka-Topic ist ein Vertrag zwischen Producern und Consumern und verdient bewusste Entscheidungen zu Namen, Schema und Retention.
• Der Partition-Key steuert Ordering und Lastverteilung zugleich, und ein falsch gewählter Key erzeugt heiße Partitionen.
• Bei At-least-once-Zustellung sind Duplikate auf Dauer unvermeidlich, deshalb müssen Consumer idempotent sein.
• Idempotente Consumer machen das Replay eines Topics zum Nicht-Ereignis statt zum Risiko für Datenkorruption.
• Consumer-Lag ist das früheste Warnsignal für einen Engpass in der gesamten Pipeline.

Kafka-Topics als Verträge behandeln

Ich behandle jedes Kafka-Topic als Vertrag zwischen dem, der darauf produziert, und dem, der davon konsumiert. Ein Name in einer Config-Datei ist es erst in zweiter Linie. Für jedes Topic treffe ich deshalb drei Entscheidungen bewusst.

Namenskonventionen

Der Name eines Topics sollte verraten, welches Domain-Event es trägt und wem es gehört. Welcher Service heute zufällig darauf schreibt, spielt dafür keine Rolle.

Schema-Evolution mit einer Schema-Registry

Schema-Evolution muss eine explizite, versionierte Entscheidung sein. Sie darf nicht implizit passieren, weil ein Producer ein Feld hinzugefügt hat. Eine Schema-Registry mit Kompatibilitätsregeln, die zur Schreibzeit durchgesetzt werden, fängt solche Änderungen ab, bevor sie zur Laufzeit-Exception eines Consumers werden.

Retention

Die dritte Entscheidung betrifft die Retention: wie lange Events leben müssen und ob ein Topic ein transienter Message-Bus ist oder ein dauerhaftes Log, das nachgelagerte Systeme von Anfang an replayen könnten.

Keine dieser drei Fragen beantworte ich mit einem Default. Ich entscheide sie einmal im Voraus, denn eine spätere Änderung bedeutet, jeden Producer und Consumer gleichzeitig zu koordinieren.

Partitionierung: Ordering und Lastverteilung

Partitionsanzahl und Partition-Key sind der Kern der Design-Arbeit. Sie bestimmen die Ordering-Garantien und wie gleichmäßig sich die Last auf die Consumer verteilt.

Den richtigen Partition-Key wählen

Kafka garantiert Ordering nur innerhalb einer Partition. Events, die relativ zueinander in Reihenfolge verarbeitet werden müssen, brauchen deshalb denselben Partition-Key, typischerweise eine Entity-ID.

Ist der Key falsch gewählt, verliert man entweder benötigtes Ordering oder, häufiger, erzeugt eine heiße Partition. Das Volumen eines einzelnen Keys überschattet dann den Rest, und ein einzelner Consumer wird zum Flaschenhals für das gesamte Topic.

Consumer-Groups passend dimensionieren

Ich dimensioniere Consumer-Groups bewusst nach der Partitionsanzahl. Eine Group kann nie mehr aktive Consumer haben als Partitionen, und zusätzliche Consumer sitzen untätig herum.

Idempotente Consumer statt Duplikate

At-least-once-Zustellung ist der praktische Standard für Kafka. Über einen ausreichend langen Zeitraum sind Duplikate damit eine Gewissheit, sei es durch Producer-Retries oder durch Consumer-Rebalances.

Statt Exactly-once-Zustellung auf Broker-Ebene garantieren zu wollen, entwerfe ich Consumer idempotent. Jeder Handler erzeugt denselben Endzustand, egal ob ein Event einmal oder zweimal verarbeitet wird. Üblicherweise geschieht das über einen Idempotenz-Key, der vor einem Seiteneffekt gegen einen Store geprüft wird.

Replay ohne Risiko

Genau diese Eigenschaft macht auch Replay sicher. Muss ich ein Topic von einem früheren Offset neu verarbeiten, um einen Bug zu beheben, machen idempotente Consumer daraus ein Nicht-Ereignis statt eines Risikos für Datenkorruption.

Kafka im Betrieb: Retention und Consumer-Lag

Im Tagesgeschäft beobachte ich zwei Hebel. Der erste ist die Retention-Strategie: zeitbasiert, größenbasiert oder komprimiert für Topics, die aktuellen Zustand statt eines Event-Logs repräsentieren. Sie wirkt sich direkt auf die Speicherkosten aus und darauf, wie weit ein Replay zurückreichen kann.

Der zweite ist Consumer-Lag, das mit Abstand nützlichste Gesundheitssignal eines Streaming-Systems. Fällt eine Consumer-Group hinter ihre produzierten Offsets zurück, ist das die früheste Warnung vor einem nachgelagerten Engpass, lange bevor von außen irgendetwas kaputt aussieht.

Was das für Ihr Unternehmen heißt

Wenn Ihre Systeme über Kafka Daten austauschen, haben diese Design-Entscheidungen greifbare Folgen. Ein doppelt verarbeitetes Event kann eine doppelte Buchung oder eine falsche Auswertung bedeuten. Ein Engpass in der Pipeline zeigt sich irgendwann als verspätete Daten in Systemen, auf die sich Fachabteilungen verlassen. Consumer-Lag ist für die IT-Leitung deshalb eine Kennzahl, die regelmäßig auf dem Dashboard stehen sollte, weil sie solche Probleme meldet, bevor sie jemandem in der Fachabteilung auffallen.

Diese Fehler lassen sich weitgehend vermeiden, wenn Topics, Keys und Consumer von Anfang an bewusst entworfen werden. Nachträglich wird es teuer, weil dann alle beteiligten Teams gleichzeitig umstellen müssen. Wie ich ereignisgetriebene Systeme plane und für wachsende Last auslege, beschreibe ich auf der Seite zu AWS-Kosten und Skalierung.