Kafka-interviewvragen en antwoorden: 22 vragen over partities, consumenten en levering

Kafka-interviews testen of je begrijpt hoe data door een log stroomt: hoe topics in partities worden opgesplitst, op welke volgorde je kunt vertrouwen, hoe consumers werk verdelen en wat er gebeurt als er iets misgaat. Scenariovragen over lag, duplicaten en dataverlies komen vaak voor, omdat dat de problemen zijn die mensen in productie tegenkomen.

Hieronder staan 22 vragen met antwoorden. Details zoals standaardwaarden verschillen per Kafka-versie, dus vermeld dat je de gebruikte versie zou controleren.

Kernconcepten

1. Wat is Kafka, en waarvoor wordt het gebruikt?

Kafka is een gedistribueerd, gerepliceerd commit log. Producers voegen records toe aan topics, en consumers lezen ze in hun eigen tempo. Het wordt gebruikt voor event streaming, log- en metriekpijplijnen, het ontkoppelen van services, het voeden van analysedata en stream processing.

2. Wat zijn topics, partities en offsets?

Een topic is een benoemde stroom van records. Elk topic is opgesplitst in partities, en elke partitie is een geordend, append-only log. Elk record in een partitie heeft een offset, een sequentieel nummer dat de positie aangeeft. Offsets zijn alleen uniek binnen een partitie.

3. Hoe beïnvloeden partities de volgorde?

Kafka garandeert volgorde alleen binnen een partitie. Records met dezelfde key gaan standaard naar dezelfde partitie, zodat ze ten opzichte van elkaar in volgorde blijven. Tussen partities is er geen volgorde. Als je alle events voor één klant in volgorde nodig hebt, gebruik je het klant-ID als key.

4. Wat is een broker, en wat doet de controller?

Een broker is een Kafka-server die partities opslaat en clients bedient. Een cluster heeft meerdere brokers. Eén daarvan fungeert als de controller, die clustermetadata en partitie-leiderschap beheert. Nieuwere Kafka-versies gebruiken KRaft, een ingebouwd consensusmechanisme, in plaats van ZooKeeper voor deze metadata.

5. Hoe werkt replicatie?

Elke partitie heeft een replicatiefactor. Eén replica is de leader, die reads en writes afhandelt, en de andere zijn followers die deze kopiëren. De in-sync replicas (ISR) zijn degenen die bij de leader zijn bijgebleven. Als de leader uitvalt, wordt een nieuwe leader gekozen uit de ISR.

Producers

6. Wat betekenen de acks-instellingen?

Voor duurzame writes gebruik je acks=all met min.insync.replicas ingesteld op minimaal 2 en een replicatiefactor van 3.

7. Hoe voorkom je dubbele berichten van een producer?

Schakel de idempotente producer in (enable.idempotence=true), waardoor de broker duplicaten kan weggooien die door retries binnen een partitie ontstaan. Voor writes die atomair meerdere partities of topics moeten omvatten, gebruik je transacties.

8. Hoe kiest een producer een partitie?

Als je een key meegeeft, hasht de standaard partitioner deze om de partitie te kiezen. Zonder key spreidt de producer records over partities (recente versies gebruiken een sticky aanpak om batches efficiënt te vullen). Je kunt ook een custom partitioner schrijven.

9. Wat beïnvloedt de doorvoer van een producer?

Batching (batch.size, linger.ms), compressie (zoals lz4 of zstd), het aantal partities en acks. Grotere batches en compressie verhogen meestal de doorvoer ten koste van een beetje latency.

Consumers

10. Wat is een consumentengroep?

Een verzameling consumers die samen het werk verdelen om een topic te lezen. Elke partitie wordt op een bepaald moment toegewezen aan één consumer in de groep. Het aantal nuttige consumers in een groep is dus beperkt door het aantal partities, en extra consumers zitten niets te doen.

11. Wat gebeurt er tijdens een rebalance?

Wanneer een consumer toetreedt of vertrekt, of partities veranderen, wijst de groep de partities opnieuw toe. Tijdens een klassieke rebalance pauzeert de consumptie terwijl dit gebeurt. Cooperative rebalancing en static membership beperken de verstoring. Frequente rebalances komen vaak door consumers die te lang doen over het verwerken (max.poll.interval.ms) of heartbeats missen.

12. Hoe worden offsets gecommit?

Consumers committen de offset van het volgende record dat gelezen moet worden, opgeslagen in een intern topic. Auto-commit is eenvoudig, maar kan committen voordat de verwerking klaar is. Handmatige commits na verwerking geven je controle over wat "klaar" betekent.

13. Wat betekenen at-most-once, at-least-once en exactly-once?

• At-most-once: commit de offset vóór de verwerking. Een crash kan records verliezen.
• At-least-once: verwerk, commit daarna. Een crash kan herverwerking veroorzaken, dus duplicaten zijn mogelijk.
• Exactly-once: het effect gebeurt één keer. In Kafka is dit mogelijk binnen Kafka met idempotente producers, transacties en read_committed consumers. Bij het schrijven naar een extern systeem heb je meestal idempotente writes of deduplicatie op een key nodig.

Een goed antwoord zegt dat "exactly once" afhangt van waar de neveneffecten plaatsvinden.

14. Hoe zou je een poison message aanpakken die altijd faalt?

Vang de fout op, probeer het een beperkt aantal keren opnieuw, stuur het record daarna naar een dead-letter topic met details, commit de offset en ga verder. Zet een alert op het dead-letter topic zodat iemand het onderzoekt.

Operations en scenario's

15. De consumer lag groeit. Hoe diagnosticeer je dat?

1. Controleer welke partities lag hebben. Eén hot partition wijst op een scheve key. Lag overal wijst op trage verwerking of te weinig consumers.
2. Controleer de verwerkingstijd per record en downstream-aanroepen zoals een database.
3. Controleer op frequente rebalances.
4. Controleer of het producertempo is gestegen.
5. Los het op met meer consumers (tot het aantal partities), snellere verwerking, batchverwerking of meer partities.

16. Wanneer moet je het aantal partities verhogen?

Wanneer je meer parallellisme nodig hebt dan de huidige consumers kunnen bieden, of wanneer de doorvoer per partitie de limiet is. Wees voorzichtig: het toevoegen van partities verandert de key-naar-partitie-mapping voor nieuwe records, dus de ordening voor een key kan breken over de wijziging heen. Plan het aantal partities vooraf wanneer ordening belangrijk is.

17. Hoe wordt data bewaard, en wat is log compaction?

Standaard verwijdert Kafka oude segmenten op basis van tijd of grootte (retention.ms, retention.bytes). Met log compaction houdt Kafka ten minste de nieuwste waarde per key bij, wat past bij een changelog of een tabelachtig topic. Een null-waarde (een tombstone) markeert een key voor verwijdering.

18. Wat gebeurt er als een broker uitvalt?

Partities met die broker als leader kiezen nieuwe leaders uit de ISR. Clients verversen hun metadata en gaan verder. Als er geen in-sync replica beschikbaar is, is de partitie niet beschikbaar, tenzij je unclean leader election toestaat, wat risico op dataverlies met zich meebrengt.

19. Hoe beveilig je een Kafka-cluster?

TLS voor encryptie tijdens transport, SASL (zoals SCRAM of OAuth) of mutual TLS voor authenticatie, ACLs voor autorisatie op topics en groepen, en netwerkcontroles. Versleutel gevoelige velden op applicatieniveau indien nodig.

20. Hoe monitor je Kafka?

Belangrijke signalen zijn consumer lag, under-replicated partitions, offline partitions, request latency, schijfgebruik en de snelheid waarmee de ISR krimpt en groeit, verzameld via JMX-metrics en tools zoals Prometheus en Grafana.

Ontwerpvragen

21. Wanneer zou je Kafka verkiezen boven een message queue zoals RabbitMQ of SQS?

Kies Kafka wanneer je hoge doorvoer nodig hebt, het opnieuw wilt afspelen van eerdere events, meerdere onafhankelijke consumers van dezelfde stream, of stream processing. Kies een traditionele queue voor routing per bericht, eenvoudige task queues, of wanneer je geen partities wilt beheren.

22. Ontwerp een pipeline voor order-events.

"Orders gaan naar een orders topic met de order-ID als key, zodat events voor een order in volgorde blijven. Ik zou drie of meer brokers gebruiken, een replication factor van 3, acks=all en idempotente producers. Consumers voor facturatie, voorraad en analytics gebruiken elk hun eigen groep. Facturatieschrijfacties zijn idempotent op order-ID, mislukte records gaan naar een dead-letter topic, en ik zou de lag per groep monitoren. Ik zou het aantal partities kiezen op basis van de piekdoorvoer en het verwachte aantal consumers, met ruimte om te groeien."

Hoe je je voorbereidt

Als het kan, draai je een lokale Kafka, schrijf je een producer en een consumer group, stop je een consumer en kijk je naar de rebalance. Breek iets expres, bijvoorbeeld een trage consumer, en bekijk de lag. Bereid één echt verhaal voor over een datapijplijnprobleem dat je hebt opgelost. Voor gerelateerde onderwerpen kun je onze gidsen bekijken over Databricks en system design-interviews.

Oefen met hardop uitleggen van de delivery guarantees, want daar worden antwoorden vaag. Een mock interview en een transcript laten je zien waar. Volg de regels van de werkgever over AI-tools in elk live interview.