Accueil›Blog›Test technique Apache Kafka : topics, partitions, consumers, Kafka Streams

Guide recrutement data

Test technique Apache Kafka : topics, partitions, consumers, Kafka Streams

Kafka est le bus de donnees de reference pour l architecture event-driven. En entretien, on evalue la capacite a concevoir des pipelines de streaming robustes.

Data Builder·Juin 2025·7 min de lecture·Data Engineer

Sommaire

Concepts fondamentaux
Producers et garanties
Consumer groups
Kafka Streams
Schema Registry
Patterns d architecture
Grille

1Topics, partitions et offsets

Question discriminante

Qu'est-ce qu'une partition Kafka ? Pourquoi le nombre de partitions est-il critique ?

Topic — canal de messages nommé, analogue à une table. Un topic peut avoir N partitions et est répliqué sur M brokers
Partition — subdivision d'un topic. Unité de parallélisme : chaque partition n'est lue que par un seul consumer dans un group. L'ordre n'est garanti qu'au sein d'une partition
Offset — identifiant séquentiel d'un message dans une partition. Immuable, croissant. C'est le consumer qui gère sa position
Retention — messages conservés N jours (défaut 7j) ou jusqu'à N GB, indépendamment de la consommation. Configurable par topic
Nombre de partitions — détermine le parallélisme max. Règle : partitions ≥ consumers. Augmenter après coup possible mais casse le partitioning par clé
Clé de message — messages avec la même clé vont toujours dans la même partition (garantie d'ordre par entité). Ex : customer_id comme clé pour les événements commandes

# Créer un topic avec 6 partitions et facteur de réplication 3
kafka-topics.sh --create   --topic orders   --partitions 6   --replication-factor 3   --bootstrap-server kafka:9092

# Vérifier le lag d'un consumer group
kafka-consumer-groups.sh --bootstrap-server kafka:9092   --group order-processor --describe
# → LAG = offset max - offset consommé par partition

2Garanties de livraison des producers

Question discriminante

Quelle est la différence entre at-most-once, at-least-once et exactly-once ? Comment les configurer ?

from kafka import KafkaProducer
import json

# Exactly-once producer
producer = KafkaProducer(
    bootstrap_servers='kafka:9092',
    value_serializer=lambda v: json.dumps(v).encode('utf-8'),
    acks='all',              # confirmation de tous les replicas ISR
    retries=5,               # retry en cas d'erreur réseau
    retry_backoff_ms=300,
    enable_idempotence=True, # exactly-once : déduplique les retries
    max_in_flight_requests_per_connection=5
)

future = producer.send('orders', 
    key=b'customer-123',
    value={'order_id': 456, 'amount': 89.90}
)
record_metadata = future.get(timeout=10)
print(f"Partition: {record_metadata.partition}, Offset: {record_metadata.offset}")

at-most-once — acks=0. Pas de retry. Performance max, tolérance à la perte de messages
at-least-once — acks=all + retries. Peut produire des doublons en cas de retry après timeout. Cas le plus courant
exactly-once — acks=all + enable_idempotence=True. Producer déduplique les retries. Nécessite Kafka ≥ 0.11
acks=all vs acks=1 — acks=1 confirme dès que le leader a écrit. acks=all attend tous les ISR (In-Sync Replicas). Plus lent mais plus sûr

3Consumer groups et rebalancing

Question discriminante

Qu'est-ce qu'un consumer group ? Que se passe-t-il lors d'un rebalancing ?

from kafka import KafkaConsumer
import json

consumer = KafkaConsumer(
    'orders',
    bootstrap_servers='kafka:9092',
    group_id='order-processor',       # consumer group ID
    auto_offset_reset='earliest',     # 'latest' = ignorer le backlog
    enable_auto_commit=False,          # commit manuel = contrôle total
    value_deserializer=lambda x: json.loads(x.decode('utf-8'))
)

for msg in consumer:
    process(msg.value)
    consumer.commit()  # committer après traitement réussi

Consumer group — groupe de processes qui lisent coopérativement un topic. Chaque partition → 1 seul consumer dans le groupe
Rebalancing — redistribution des partitions quand un consumer rejoint/quitte. Les consumers stoppent pendant le rebalancing (stop-the-world)
Lag — offset max produit - offset consommé. Un lag qui croît = consumer trop lent. Monitoring obligatoire
Commit strategy — auto_commit=True est risqué (commit avant traitement). Préférer le commit manuel après traitement réussi
Partition assignment — Range (par défaut), RoundRobin, StickyAssignor (minimise les mouvements de partitions)

4Kafka Streams vs ksqlDB vs Flink

Question discriminante

Quand choisissez-vous Kafka Streams, ksqlDB ou Flink ?

Outil	Paradigme	Cas d'usage	Complexité
Kafka Streams	Librairie Java/Scala	Transformations légères, enrichissement, agrégations	Faible
ksqlDB	SQL sur Kafka	Prototypage, équipes SQL, streams simples	Très faible
Flink	Framework distribué	Streaming complexe, joins multi-sources, exactement-once	Élevée
Spark Streaming	Micro-batch	Équipes Spark existantes, latence >1s acceptable	Moyenne

5Schema Registry

Question discriminante

Pourquoi utiliser un Schema Registry ? Comment gérez-vous l'évolution des schémas ?

Schema Registry — service centralisé qui stocke et valide les schémas Avro/Protobuf/JSON des topics. Empêche les producers d'envoyer des messages incompatibles
Évolution backward-compatible — ajouter un champ avec valeur par défaut. Les anciens consumers continuent de fonctionner
Évolution breaking — renommer ou supprimer un champ. Nécessite une migration coordonnée consumers/producers
Avro vs Protobuf — Avro : standard Confluent, schéma inclus dans les messages. Protobuf : meilleur support multi-langages, plus verbeux

# Schéma Avro pour un event commande
{
  "type": "record",
  "name": "Order",
  "namespace": "io.databuilder",
  "fields": [
    {"name": "order_id", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "currency", "type": "string", "default": "EUR"},
    {"name": "created_at", "type": "long", "logicalType": "timestamp-millis"}
  ]
}

6Patterns d'architecture avec Kafka

Question discriminante

Quels patterns d'architecture utilisez-vous avec Kafka en production ?

Event sourcing — Kafka comme source de vérité. Les états sont reconstruits en rejouant les events depuis le début
CQRS — séparer la lecture (projections materialisées) de l'écriture (events Kafka)
CDC avec Kafka Connect — Debezium capture les changements PostgreSQL/MySQL et les publie dans Kafka. Pont entre OLTP et streaming
Saga pattern — orchestrer des transactions distribuées via des events Kafka entre microservices
Compacted topics — Kafka conserve uniquement le dernier message par clé. Idéal pour les tables de référence (état courant)

7Grille par niveau

Niveau	Maîtrise	Signal GO	NO-GO
Junior	Concepts topics/partitions/offsets, consumer group basique	Explique ce qu'est un offset et un consumer group, sait produire/consommer en Python	Confond topic et partition, ne sait pas ce qu'est un offset
Confirmé	Garanties de livraison, rebalancing, Schema Registry, Kafka Connect	Configure exactly-once, utilise Debezium pour le CDC, a géré des lags en prod	Ne sait pas la différence entre at-least-once et exactly-once
Senior	Architecture event-driven, patterns Saga/CQRS, optimisation throughput, monitoring	A conçu une architecture event-driven complète, sait dimensionner les partitions	Ne sait pas ce qu'est le rebalancing ni son impact

1Topics, partitions and offsets

Key question

What is a Kafka partition? Why is the number of partitions critical?

Topic — named message channel, analogous to a table. A topic can have N partitions and is replicated across M brokers
Partition — subdivision of a topic. Unit of parallelism: each partition is read by only one consumer in a group. Order is only guaranteed within a partition
Offset — sequential identifier of a message within a partition. Immutable, increasing. The consumer manages its own position
Retention — messages kept for N days (default 7d) or up to N GB, regardless of consumption. Configurable per topic
Number of partitions — determines maximum parallelism. Rule: partitions ≥ consumers. Can be increased later but breaks key-based partitioning
Message key — messages with the same key always go to the same partition (order guarantee per entity). E.g.: customer_id as key for order events

# Create a topic with 6 partitions and replication factor 3
kafka-topics.sh --create   --topic orders   --partitions 6   --replication-factor 3   --bootstrap-server kafka:9092

# Check consumer group lag
kafka-consumer-groups.sh --bootstrap-server kafka:9092   --group order-processor --describe
# → LAG = max offset - consumed offset per partition

2Producer delivery guarantees

Key question

What is the difference between at-most-once, at-least-once and exactly-once? How do you configure them?

at-most-once — acks=0. No retry. Maximum performance, tolerates message loss
at-least-once — acks=all + retries. May produce duplicates on retry after timeout. Most common case
exactly-once — acks=all + enable_idempotence=True. Producer deduplicates retries. Requires Kafka ≥ 0.11
acks=all vs acks=1 — acks=1 confirms when leader has written. acks=all waits for all ISR (In-Sync Replicas). Slower but safer

3Consumer groups and rebalancing

Key question

What is a consumer group? What happens during rebalancing?

Consumer group — group of processes cooperatively reading a topic. Each partition → 1 consumer in the group
Rebalancing — redistribution of partitions when a consumer joins/leaves. Consumers stop during rebalancing (stop-the-world)
Lag — max produced offset - consumed offset. Growing lag = consumer too slow. Mandatory monitoring
Commit strategy — auto_commit=True is risky (commit before processing). Prefer manual commit after successful processing
Partition assignment — Range (default), RoundRobin, StickyAssignor (minimizes partition movements)

4Kafka Streams vs ksqlDB vs Flink

Key question

When do you choose Kafka Streams, ksqlDB or Flink?

Tool	Paradigm	Use case	Complexity
Kafka Streams	Java/Scala library	Light transformations, enrichment, aggregations	Low
ksqlDB	SQL on Kafka	Prototyping, SQL teams, simple streams	Very low
Flink	Distributed framework	Complex streaming, multi-source joins, exactly-once	High
Spark Streaming	Micro-batch	Existing Spark teams, latency >1s acceptable	Medium

5Schema Registry

Key question

Why use a Schema Registry? How do you manage schema evolution?

Schema Registry — centralized service that stores and validates Avro/Protobuf/JSON schemas for topics. Prevents producers from sending incompatible messages
Backward-compatible evolution — add a field with a default value. Old consumers continue working
Breaking evolution — rename or delete a field. Requires coordinated migration of consumers/producers
Avro vs Protobuf — Avro: Confluent standard, schema included in messages. Protobuf: better multi-language support, more verbose

6Architecture patterns with Kafka

Key question

What architecture patterns do you use with Kafka in production?

Event sourcing — Kafka as source of truth. States are reconstructed by replaying events from the beginning
CQRS — separate reads (materialized projections) from writes (Kafka events)
CDC with Kafka Connect — Debezium captures PostgreSQL/MySQL changes and publishes to Kafka. Bridge between OLTP and streaming
Saga pattern — orchestrate distributed transactions via Kafka events between microservices
Compacted topics — Kafka keeps only the last message per key. Ideal for reference tables (current state)

7Level assessment grid

Level	Mastery	GO signal	NO-GO
Junior	Topic/partition/offset concepts, basic consumer group	Explains what an offset and consumer group are, can produce/consume in Python	Confuses topic and partition, doesn't know what an offset is
Confirmed	Delivery guarantees, rebalancing, Schema Registry, Kafka Connect	Configures exactly-once, uses Debezium for CDC, has managed lag in prod	Doesn't know difference between at-least-once and exactly-once
Senior	Event-driven architecture, Saga/CQRS patterns, throughput optimization, monitoring	Has designed a complete event-driven architecture, knows how to size partitions	Doesn't know what rebalancing is or its impact

Vous recrutez un Data Engineer Kafka ?

Premier entretien gratuit. Rapport GO/NO-GO sous 48h.

Tester gratuitement Reserver un appel