Kafka Interview Fragen und Antworten: 22 Fragen zu Partitionen, Consumern und Zustellung

Kafka-Interviews prüfen, ob du verstehst, wie Daten durch ein Log wandern: wie Topics in Partitionen aufgeteilt werden, auf welche Reihenfolge du dich verlassen kannst, wie Consumer sich die Arbeit teilen und was passiert, wenn etwas ausfällt. Szenariofragen zu Lag, Duplikaten und Datenverlust sind häufig, weil genau das die Probleme sind, auf die man im Produktivbetrieb stößt.

Unten findest du 22 Fragen mit Antworten. Details wie Standardwerte unterscheiden sich je nach Kafka-Version, also erwähne, dass du die eingesetzte Version prüfen würdest.

Grundkonzepte

1. Was ist Kafka, und wofür wird es verwendet?

Kafka ist ein verteiltes, repliziertes Commit-Log. Producer hängen Records an Topics an, und Consumer lesen sie in ihrem eigenen Tempo. Es wird für Event-Streaming, Log- und Metrik-Pipelines, die Entkopplung von Services, die Versorgung von Analysesystemen mit Daten und Stream-Processing eingesetzt.

2. Was sind Topics, Partitionen und Offsets?

Ein Topic ist ein benannter Strom von Records. Jedes Topic ist in Partitionen aufgeteilt, und jede Partition ist ein geordnetes, nur anhängbares Log. Jeder Record in einer Partition hat ein Offset, eine fortlaufende Nummer, die seine Position angibt. Offsets sind nur innerhalb einer Partition eindeutig.

3. Wie wirken sich Partitionen auf die Reihenfolge aus?

Kafka garantiert die Reihenfolge nur innerhalb einer Partition. Records mit demselben Key landen standardmäßig in derselben Partition, bleiben also zueinander in der richtigen Reihenfolge. Über Partitionen hinweg gibt es keine Reihenfolge. Wenn du alle Events für einen Kunden in der richtigen Reihenfolge brauchst, verwende die Kunden-ID als Key.

4. Was ist ein Broker, und was macht der Controller?

Ein Broker ist ein Kafka-Server, der Partitionen speichert und Clients bedient. Ein Cluster hat mehrere Broker. Einer fungiert als Controller, der die Cluster-Metadaten und die Partition-Leadership verwaltet. Neuere Kafka-Versionen verwenden für diese Metadaten KRaft, einen eingebauten Konsensmechanismus, statt ZooKeeper.

5. Wie funktioniert die Replikation?

Jede Partition hat einen Replikationsfaktor. Ein Replica ist der Leader, der Lese- und Schreibvorgänge abwickelt, und die anderen sind Follower, die ihn kopieren. Die In-Sync-Replicas (ISR) sind diejenigen, die mit dem Leader auf dem gleichen Stand sind. Fällt der Leader aus, wird ein neuer Leader aus der ISR gewählt.

Producer

6. Was bedeuten die acks-Einstellungen?

Für haltbare Schreibvorgänge verwende acks=all mit min.insync.replicas auf mindestens 2 und einem Replikationsfaktor von 3.

7. Wie vermeidest du doppelte Nachrichten von einem Producer?

Aktiviere den idempotenten Producer (enable.idempotence=true), der es dem Broker ermöglicht, Duplikate zu verwerfen, die durch Wiederholungsversuche innerhalb einer Partition entstehen. Für Schreibvorgänge, die mehrere Partitionen oder Topics atomar umfassen müssen, verwende Transaktionen.

8. Wie wählt ein Producer eine Partition aus?

Wenn du einen Key angibst, hasht der Standard-Partitioner ihn, um die Partition auszuwählen. Ohne Key verteilt der Producer die Records über die Partitionen (neuere Versionen verwenden einen Sticky-Ansatz, um Batches effizient zu füllen). Du kannst auch einen benutzerdefinierten Partitioner schreiben.

9. Was beeinflusst den Durchsatz eines Producers?

Batching (batch.size, linger.ms), Komprimierung (etwa lz4 oder zstd), die Anzahl der Partitionen und acks. Größere Batches und Komprimierung erhöhen in der Regel den Durchsatz auf Kosten einer etwas höheren Latenz.

Consumer

10. Was ist eine Consumer Group?

Eine Gruppe von Consumern, die sich die Arbeit des Lesens eines Topics teilen. Jede Partition wird jeweils einem Consumer der Gruppe zugewiesen. Die Anzahl der sinnvoll einsetzbaren Consumer in einer Gruppe ist also durch die Anzahl der Partitionen begrenzt, und zusätzliche Consumer bleiben ungenutzt.

11. Was passiert während eines Rebalance?

Wenn ein Consumer beitritt oder die Gruppe verlässt oder sich Partitionen ändern, verteilt die Gruppe die Partitionen neu. Bei einem klassischen Rebalance pausiert die Konsumierung, während dies geschieht. Kooperatives Rebalancing und statische Mitgliedschaft reduzieren die Störung. Häufige Rebalances entstehen oft durch Consumer, die zu lange für die Verarbeitung brauchen (max.poll.interval.ms) oder Heartbeats verpassen.

12. Wie werden Offsets committed?

Consumer committen den Offset des nächsten zu lesenden Records, der in einem internen Topic gespeichert wird. Auto-Commit ist einfach, kann aber committen, bevor die Verarbeitung abgeschlossen ist. Manuelle Commits nach der Verarbeitung geben dir die Kontrolle darüber, was „erledigt" bedeutet.

13. Was bedeuten At-Most-Once, At-Least-Once und Exactly-Once?

• At-Most-Once: Den Offset vor der Verarbeitung committen. Ein Absturz kann Records verlieren.
• At-Least-Once: Verarbeiten, dann committen. Ein Absturz kann eine erneute Verarbeitung verursachen, Duplikate sind also möglich.
• Exactly-Once: Der Effekt tritt genau einmal auf. In Kafka ist das innerhalb von Kafka mit idempotenten Producern, Transaktionen und read_committed-Consumern möglich. Beim Schreiben in ein externes System brauchst du in der Regel idempotente Schreibvorgänge oder Deduplizierung über einen Schlüssel.

Eine gute Antwort sagt, dass „Exactly Once" davon abhängt, wo die Seiteneffekte auftreten.

14. Wie würdest du eine Poison Message behandeln, die immer fehlschlägt?

Den Fehler abfangen, eine begrenzte Anzahl von Malen wiederholen, den Record dann mit Details an ein Dead-Letter-Topic senden, den Offset committen und weitermachen. Das Dead-Letter-Topic überwachen, damit jemand die Ursache untersucht.

Betrieb und Szenarien

15. Der Consumer Lag wächst. Wie diagnostizierst du das?

1. Prüfe, welche Partitionen Lag haben. Eine einzelne Hot Partition deutet auf einen schiefen Schlüssel hin. Lag überall deutet auf langsame Verarbeitung oder zu wenige Consumer hin.
2. Prüfe die Verarbeitungszeit pro Record und nachgelagerte Aufrufe wie eine Datenbank.
3. Prüfe auf häufige Rebalances.
4. Prüfe, ob die Producer-Rate gestiegen ist.
5. Behebe das Problem mit mehr Consumern (bis zur Anzahl der Partitionen), schnellerer Verarbeitung, Batch-Verarbeitung oder mehr Partitionen.

16. Wann solltest du die Anzahl der Partitionen erhöhen?

Wenn du mehr Parallelität brauchst, als die aktuellen Consumer bieten können, oder wenn der Durchsatz pro Partition der limitierende Faktor ist. Vorsicht: Das Hinzufügen von Partitionen ändert das Mapping von Schlüssel zu Partition für neue Records, sodass die Reihenfolge für einen Schlüssel über die Änderung hinweg brechen kann. Plane die Anzahl der Partitionen von vornherein, wenn die Reihenfolge wichtig ist.

17. Wie werden Daten aufbewahrt, und was ist Log Compaction?

Standardmäßig löscht Kafka alte Segmente nach Zeit oder Größe (retention.ms, retention.bytes). Bei der Log Compaction behält Kafka mindestens den neuesten Wert für jeden Schlüssel, was zu einem Changelog oder einem tabellenartigen Topic passt. Ein Nullwert (ein Tombstone) markiert einen Schlüssel zum Löschen.

18. Was passiert, wenn ein Broker ausfällt?

Partitionen, die von diesem Broker angeführt werden, wählen neue Leader aus dem ISR. Clients aktualisieren ihre Metadaten und machen weiter. Wenn kein In-Sync-Replica verfügbar ist, ist die Partition nicht verfügbar, es sei denn, du erlaubst eine Unclean Leader Election, was Datenverlust riskiert.

19. Wie sicherst du einen Kafka-Cluster ab?

TLS zur Verschlüsselung während der Übertragung, SASL (etwa SCRAM oder OAuth) oder Mutual TLS zur Authentifizierung, ACLs zur Autorisierung für Topics und Gruppen sowie Netzwerkkontrollen. Verschlüssele sensible Felder bei Bedarf auf Anwendungsebene.

20. Wie überwachst du Kafka?

Die wichtigsten Signale sind Consumer Lag, unterreplizierte Partitionen, Offline-Partitionen, Request-Latenz, Festplattennutzung sowie ISR-Shrink- und -Expand-Raten, die über JMX-Metriken und Tools wie Prometheus und Grafana erfasst werden.

Design-Fragen

21. Wann würdest du Kafka einer Message Queue wie RabbitMQ oder SQS vorziehen?

Wähle Kafka, wenn du hohen Durchsatz, das erneute Abspielen vergangener Events, mehrere unabhängige Consumer desselben Streams oder Stream Processing brauchst. Wähle eine traditionelle Queue für Routing pro Nachricht, einfache Task Queues oder wenn du keine Partitionen verwalten möchtest.

22. Entwirf eine Pipeline für Order-Events.

„Bestellungen gehen an ein orders-Topic, verschlüsselt nach Order-ID, damit Events für eine Bestellung in der richtigen Reihenfolge bleiben. Ich würde drei oder mehr Broker verwenden, einen Replication Factor von 3, acks=all und idempotente Producer. Consumer für Billing, Inventory und Analytics nutzen jeweils ihre eigene Gruppe. Billing-Schreibvorgänge sind idempotent über die Order-ID, fehlgeschlagene Records gehen an ein Dead-Letter-Topic, und ich würde den Lag pro Gruppe überwachen. Die Anzahl der Partitionen würde ich anhand des Spitzendurchsatzes und der erwarteten Anzahl an Consumern wählen, mit Spielraum nach oben."

Wie man sich vorbereitet

Wenn möglich, betreibe einen lokalen Kafka, schreibe einen Producer und eine Consumer Group, stoppe einen Consumer und beobachte den Rebalance. Zerbrich absichtlich etwas, zum Beispiel einen langsamen Consumer, und sieh dir den Lag an. Bereite eine echte Geschichte über ein Datenpipeline-Problem vor, das du gelöst hast. Für verwandte Themen siehe unsere Leitfäden zu Databricks und System-Design-Interviews.

Übe, die Delivery-Guarantees laut zu erklären, denn genau dort werden Antworten vage. Ein Mock-Interview und ein Transkript zeigen dir, wo. Befolge die Regeln des Arbeitgebers zu KI-Tools in jedem Live-Interview.