Accueil›Blog›Test technique architecture event-driven pour la data

Guide recrutement data

Test technique architecture event-driven pour la data

L architecture event-driven est devenue centrale dans les systèmes data modernes. En entretien Architect, on évalue la capacité à concevoir des systèmes découplés et résilients.

Data Builder·Juin 2025·6 min de lecture·Data Engineer · Data Architect

Sommaire

Event-Driven Architecture
CQRS
Event Sourcing
Outbox Pattern
Saga Pattern
Quand utiliser EDA
Grille

1Event-Driven Architecture : principes

Question discriminante

Quels sont les avantages d une architecture event-driven pour un système data ?

Découplage — le producteur ne connaît pas les consommateurs. Ajouter un nouveau consommateur ne nécessite pas de modifier le producteur
Résilience — si un consommateur est en panne, les events s accumulent dans le bus (Kafka). Aucune perte de données
Scalabilité — chaque consommateur scale indépendamment selon sa charge
Auditabilité — les events sont immuables et persistés. Historique complet des changements
Complexité — debugging plus difficile, cohérence éventuelle (eventual consistency) à gérer

2CQRS : séparer lecture et écriture

Question discriminante

Qu est-ce que CQRS ? Comment s applique-t-il à une architecture data ?

# CQRS : Command Query Responsibility Segregation
# Séparer les opérations d écriture (Commands) des lectures (Queries)

# COMMAND SIDE : optimisé pour les écritures
# - Base transactionnelle (PostgreSQL)
# - Modèle normalisé
# - Cohérence forte
class CreateOrderCommand:
    def execute(self, order: dict) -> None:
        db.insert('orders', order)
        event_bus.publish('OrderCreated', order)  # publier l event

# QUERY SIDE : optimisé pour les lectures
# - Data warehouse (Snowflake, BigQuery)
# - Modèle dénormalisé, pré-agrégé
# - Cohérence éventuelle (délai de réplication)
class GetRevenueByRegionQuery:
    def execute(self, region: str) -> float:
        return warehouse.query(
            'SELECT SUM(amount) FROM fct_revenue WHERE region = ?', region
        )

3Event Sourcing : Kafka comme source de vérité

Question discriminante

Comment Kafka peut-il servir de source de vérité dans une architecture event sourcing ?

Event Sourcing — stocker l historique des events plutôt que l état courant. L état se reconstruit en rejouant les events
Kafka comme source de vérité — les events sont immuables, partitionnés, réplicés. Rétention longue (années)
Avantages — audit trail complet, possibilité de reconstruire n importe quel état passé, débugging facilité
Matérialisation — les états courants sont des projections calculées depuis les events. Se reconstruisent si corrompus
Compaction — Kafka Log Compaction : garder seulement le dernier event par clé pour les états courants

4Outbox Pattern : garantir la cohérence

Question discriminante

Quel problème l outbox pattern résout-il ?

# Problème sans outbox :
# 1. INSERT en base (succès)
# 2. Publier event Kafka (ÉCHEC)
# -> la base et Kafka sont incohérents

# Outbox Pattern : atomic dual write
# Dans la même transaction :
def create_order(order: dict):
    with transaction():
        db.insert('orders', order)          # 1. Insérer en base
        db.insert('outbox', {               # 2. Insérer dans l outbox
            'event_type': 'OrderCreated',
            'payload': json.dumps(order),
            'status': 'pending'
        })
    # Transaction atomique : les deux réussissent ou échouent ensemble

# Débrayeur (Debezium ou polling) :
# Lire l outbox et publier dans Kafka
# Marquer comme 'published' après succès

5Saga Pattern : transactions distribuées

Question discriminante

Qu est-ce qu un Saga ? Comment gère-t-il l échec d une étape dans un processus multi-services ?

Saga — séquence de transactions locales compensables. Remplace les transactions distribuées (2PC) dans les architectures microservices
Orchestration — un orchestrateur central coordonne les étapes. En cas d échec, déclenche les compensations
Chorégraphie — chaque service écoute les events et réagit. Plus découplé mais plus difficile à debugger
Compensation — chaque étape a une transaction inverse. Si l étape 3 échoue, les étapes 2 et 1 sont compensées

6Quand utiliser l architecture event-driven

Question discriminante

Comment décidez-vous si une architecture event-driven est justifiée ?

Oui si — plusieurs consommateurs indépendants, besoin d auditabilité, pics de charge imprévisibles, couplage faible requis
Non si — système simple avec 1-2 services, cohérence forte requise partout, équipe petite sans expertise messaging
Complexité supplémentaire — eventual consistency, debugging plus difficile, gestion des duplicats (at-least-once delivery)
Start simple — une API REST monolithique bien conçue est souvent préférable à une EDA prématurée

import asyncio
from dataclasses import dataclass
from typing import Callable
import json

# Event-driven pipeline simple avec Kafka
@dataclass
class OrderEvent:
    order_id: str
    customer_id: str
    amount: float
    event_type: str  # order_created, order_paid, order_shipped

class EventBus:
    def __init__(self):
        self.handlers: dict[str, list[Callable]] = {}
    
    def subscribe(self, event_type: str, handler: Callable):
        self.handlers.setdefault(event_type, []).append(handler)
    
    async def publish(self, event: OrderEvent):
        for handler in self.handlers.get(event.event_type, []):
            await handler(event)

# Handlers
async def update_inventory(event: OrderEvent):
    await db.execute("UPDATE inventory SET stock = stock - 1 WHERE product_id = ?", [event.order_id])

async def send_confirmation_email(event: OrderEvent):
    await email_service.send(customer_id=event.customer_id, template="order_confirmation")

bus = EventBus()
bus.subscribe("order_paid", update_inventory)
bus.subscribe("order_paid", send_confirmation_email)

Event Sourcing — l'état du système est reconstitué en rejouant les events depuis le début. Kafka comme log immuable. Permet l'audit complet et le time travel
CQRS (Command Query Responsibility Segregation) — séparer les writes (commands → events) des reads (projections matérialisées). Optimiser chaque chemin indépendamment
Saga pattern — orchestrer des transactions distribuées via des events. Chaque service émet un event de succès ou d'échec. Compensation en cas d'échec partiel
Outbox pattern — écrire dans la DB et dans la queue de façon atomique. Évite les situations où la DB est mise à jour mais l'event n'est pas publié
At-least-once et idempotence — les consumers peuvent recevoir un event plusieurs fois. Toujours rendre les handlers idempotents (check si l'event a déjà été traité)

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	EDA principes, Kafka producer/consumer, découplage	Explique les avantages du découplage via events, a consommé Kafka	Ne sait pas ce qu est l eventual consistency
Senior	CQRS, Event Sourcing, Outbox pattern, Saga	A implémenté l outbox pattern, explique CQRS et ses trade-offs	Ne sait pas ce qu est l outbox pattern

1Event-Driven Architecture: principles

Discriminating question

What are the advantages of an event-driven architecture for a data system?

Decoupling — the producer does not know the consumers. Adding a new consumer does not require modifying the producer
Resilience — if a consumer is down, events accumulate in the bus (Kafka). No data loss
Scalability — each consumer scales independently according to its load
Auditability — events are immutable and persisted. Complete history of changes
Complexity — harder debugging, eventual consistency to manage

2CQRS: separating reads and writes

Discriminating question

What is CQRS? How does it apply to a data architecture?

# CQRS : Command Query Responsibility Segregation
# Separate write operations (Commands) from reads (Queries)

# COMMAND SIDE : optimized for writes
# - Transactional database (PostgreSQL)
# - Normalized model
# - Strong consistency
class CreateOrderCommand:
    def execute(self, order: dict) -> None:
        db.insert('orders', order)
        event_bus.publish('OrderCreated', order)  # publish the event

# QUERY SIDE : optimized for reads
# - Data warehouse (Snowflake, BigQuery)
# - Denormalized, pre-aggregated model
# - Eventual consistency (replication delay)
class GetRevenueByRegionQuery:
    def execute(self, region: str) -> float:
        return warehouse.query(
            'SELECT SUM(amount) FROM fct_revenue WHERE region = ?', region
        )

3Event Sourcing: Kafka as source of truth

Discriminating question

How can Kafka serve as a source of truth in an event sourcing architecture?

Event Sourcing — storing the history of events rather than the current state. State is reconstructed by replaying events
Kafka as source of truth — events are immutable, partitioned, replicated. Long retention (years)
Advantages — complete audit trail, ability to reconstruct any past state, easier debugging
Materialization — current states are projections computed from events. Can be rebuilt if corrupted
Compaction — Kafka Log Compaction: keep only the last event per key for current states

4Outbox Pattern: guaranteeing consistency

Discriminating question

What problem does the outbox pattern solve?

# Problem without outbox:
# 1. INSERT into database (success)
# 2. Publish Kafka event (FAILURE)
# -> the database and Kafka are inconsistent

# Outbox Pattern: atomic dual write
# Within the same transaction:
def create_order(order: dict):
    with transaction():
        db.insert('orders', order)          # 1. Insert into database
        db.insert('outbox', {               # 2. Insert into outbox
            'event_type': 'OrderCreated',
            'payload': json.dumps(order),
            'status': 'pending'
        })
    # Atomic transaction: both succeed or fail together

# Relay (Debezium or polling):
# Read the outbox and publish to Kafka
# Mark as 'published' after success

5Saga Pattern: distributed transactions

Discriminating question

What is a Saga? How does it handle the failure of a step in a multi-service process?

Saga — sequence of compensable local transactions. Replaces distributed transactions (2PC) in microservices architectures
Orchestration — a central orchestrator coordinates the steps. In case of failure, triggers compensations
Choreography — each service listens to events and reacts. More decoupled but harder to debug
Compensation — each step has a reverse transaction. If step 3 fails, steps 2 and 1 are compensated

6When to use event-driven architecture

Discriminating question

How do you decide if an event-driven architecture is justified?

Yes if — multiple independent consumers, need for auditability, unpredictable load spikes, loose coupling required
No if — simple system with 1-2 services, strong consistency required everywhere, small team without messaging expertise
Additional complexity — eventual consistency, harder debugging, duplicate management (at-least-once delivery)
Start simple — a well-designed monolithic REST API is often preferable to premature EDA

import asyncio
from dataclasses import dataclass
from typing import Callable
import json

# Simple event-driven pipeline with Kafka
@dataclass
class OrderEvent:
    order_id: str
    customer_id: str
    amount: float
    event_type: str  # order_created, order_paid, order_shipped

class EventBus:
    def __init__(self):
        self.handlers: dict[str, list[Callable]] = {}
    
    def subscribe(self, event_type: str, handler: Callable):
        self.handlers.setdefault(event_type, []).append(handler)
    
    async def publish(self, event: OrderEvent):
        for handler in self.handlers.get(event.event_type, []):
            await handler(event)

# Handlers
async def update_inventory(event: OrderEvent):
    await db.execute("UPDATE inventory SET stock = stock - 1 WHERE product_id = ?


Vous recrutez un Data Engineer ou Data Architect ?
Premier entretien gratuit. Rapport GO/NO-GO sous 48h.
Tester gratuitementReserver un appel