Comparatif de 11 solutions Event Sourcing & CQRS pour microservices

Dans les architectures microservices, Event Sourcing et CQRS accélèrent l’évolutivité et l’auditabilité, mais exigent des choix techniques rigoureux. Ce guide compare 11 technologies clés selon leur architecture, throughput/latence, coûts d’exploitation, exigences opérationnelles, sécurité et cas d’implémentation. Deux repères pour les décideurs : « Optez pour l’Event Sourcing si l’historique complet et la reconstitution d’état sont stratégiques » et « Utilisez CQRS isolé si la performance de lecture et la scalabilité sont prioritaires ».

1) EventStoreDB (v21.10)

• Fonction : event store append-only, gRPC, projections, snapshots facultatifs.
• Architecture : clustering multi-nœuds, réplication quorum, snapshots pour accélérer l’hydratation.
• Performance : ≈ 10 000–50 000 appends/s par cluster, latence ≤ 5 ms (disk SSD NVMe). Scalable horizontalement.
• Opérations : sauvegarde via export en JSON/CSV, restore en mode catch-up; haute disponibilité via replica sets. Chiffrement TLS, RBAC, audit logs.
• Cas d’usage : finance, santé, logistique. Nécessite skills en versionnage d’événements.

2) Apache Kafka (v3.5)

• Fonction : log distribué, topics partitionnés, exactly-once, ksqlDB.
• Architecture : partitions, ISR, ZooKeeper/KRaft, tiered storage.
• Performance : 1–3 M msgs/s/cluster, latence 2–10 ms (batch optimal). Scale-out via partitions.
• Opérations : mirror maker pour DR, snapshot de topics, ACL/Kafka Ranger, intégration Vault pour clés.
• Cas d’usage : pipeline de données, Event Sourcing pur avec conventions Idempotence/Keying.

3) Apache Pulsar (v2.10)

• Fonction : streaming multi-locataire, BookKeeper, tiered storage.
• Architecture : brokers + BookKeeper, cursors durables, geo-replication.
• Performance : 500 000–1 M msgs/s/cluster, latence 3–8 ms. Scaling automatique des brokers.
• Opérations : snapshots BookKeeper, backups S3, chiffrement réseau et at-rest, ACL et JWT.
• Cas d’usage : multi-tenant, rétention longue durée, pipeline unifié messaging/streaming.

4) Axon Framework & Axon Server (v4.9)

• Fonction : framework Java DDD, bus commandes/requêtes, sagas, observabilité intégrée.
• Architecture : agrégats event-sourcés, snapshots, tags, back-pressure.
• Performance : 5 000–20 000 commandes/s, latence ~10 ms hors I/O. Scale via cluster Axon Server Enterprise.
• Opérations : backup via export JAR d’événements, metrics via Micrometer, SSL/TLS, contrôle RBAC.
• Cas d’usage : écosystème Java/Spring, besoin d’un socle DDD+ES+CQRS clé en main.

5) Eventuate Tram & Platform (v0.29)

• Fonction : Event Sourcing + CDC/outbox, sagas, support Kafka & RDBMS.
• Architecture : événements persistés en base ou Kafka, CDC pour propager.
• Performance : 2 000–10 000 events/s selon moteur sous-jacent, latence 20–50 ms.
• Opérations : backups DB, retention topics, SSL, schema registry, RBAC via Kubernetes.
• Cas d’usage : microservices polyglottes, fiabilité transactionnelle sans double write.

6) Écosystème Spring (Boot, Cloud, Kafka)

• Fonction : starters pour CQRS, patterns outbox, intégrations Kafka/R2DBC.
• Architecture : handlers, projections, config centralisée, tracing distribué.
• Performance : dépend du store (OLTP/NoSQL), généralement 1 000–30 000 req/s, latence 5–20 ms.
• Opérations : Spring Boot Actuator, backups DB, SSL, OAuth2, compliance PCI/GDPR.
• Cas d’usage : standardisation Java/Spring, industrialisation rapide.

7) Debezium (v2.4)

• Fonction : CDC RDBMS → Kafka, pattern Outbox.
• Architecture : Kafka Connect, WAL tailing, schema registry.
• Performance : 1 000–5 000 changes/s, latence 10–100 ms selon DB.
• Opérations : revert via offsets, maintenance connectors, SSL, ACL Kafka.
• Cas d’usage : exposer flux d’événements depuis legacy CRUD.

8) Kafka Streams & ksqlDB (v0.26 / v0.29)

• Fonction : traitement in-process, state stores, SQL streaming.
• Architecture : RocksDB, changelog topics, exactly-once.
• Performance : 50 000–200 000 ops/s par instance, latence 1–5 ms.
• Opérations : backup state store, rebalancing, ACL, TLS.
• Cas d’usage : vues CQRS, transformations temps réel.

9) NATS JetStream (v2.10)

• Fonction : messaging léger, streaming durable, ack modes, consumers push/pull.
• Architecture : cluster NATS + JetStream, storage tiers (disk/memory).
• Performance : 200 000–500 000 msgs/s/cluster, latence < 2 ms en mémoire, ~5 ms en disque.
• Opérations : snapshots auto-purge, backups via snapshot export, TLS, multi-tenancy via accounts.
• Cas d’usage : microservices ultra-légers, latency-sensitive, IoT et edge.

10) Amazon Kinesis Data Streams (API v1/v2)

• Fonction : streaming managé AWS, shards pour scaling, intégration Lambda/Kinesis Analytics.
• Architecture : shards, retenue 24h–7j renouvelable, chiffrement KMS.
• Performance : 1 000–2 000 rec/s/shard, latence ~50–200 ms.
• Opérations : backup vers S3, CloudWatch metrics, IAM/Roles, encryption at-rest.
• Cas d’usage : absence d’infra on-premise, intégration AWS, charges modérées.

11) Redis Streams (v6+)

• Fonction : structure log append-only, consumer groups, trimming.
• Architecture : master-replica, clustering, persistence AOF/RDB.
• Performance : 50 000–200 000 ops/s par node, latence < 1 ms in-memory.
• Opérations : snapshots RDB/AOF, replication, ACL, TLS, Redis Modules pour sécurité.
• Cas d’usage : low-latency, in-memory, features pub/sub + events léger.

Conclusion comparée

Tous disposent d’écosystèmes matures mais se distinguent sur la granularité fonctionnelle, la latence et l’opérationnel. Kafka et Pulsar excellent en débit et pipeline ; EventStoreDB et Axon Server ciblent l’Event Sourcing pur ; Debezium et Eventuate répondent aux besoins de CDC/outbox ; NATS et Redis Streams misent sur la légèreté et la latence minimale ; Kinesis privilégie le managé. Choisir implique d’évaluer le profil de charge, l’expertise interne, les exigences réglementaires et le budget opérationnel.

Matrice de décision & plan de migration

Contexte	Solution recommandée	Étapes PoC & migration
Auditabilité forte Domaine réglementé	EventStoreDB ou Axon Server	Installer cluster 3 nœuds (v21.10 ou v4.9). Modéliser événements/aggrégats et tests de snapshot. Valider backup/restore et RBAC via snapshots.
Pipelines EDA à gros volume	Apache Kafka ou Pulsar	Déployer cluster Kafka 3.5 (ou Pulsar 2.10). Configurer topics/partitions, ISR, tiered storage. Test throughput/latence et failover.
Legacy CRUD à transformer	Debezium + Kafka Streams	Déployer Debezium 2.4, connecter à la DB. Créer topics Outbox et mirrors tables. Matérialisation de vues via ksqlDB.
Low-latency & edge	NATS JetStream	Installer cluster NATS 2.10. Configurer accounts/permissions, storage tiers. Valider performance (< 2 ms) et snapshots export.
Managé AWS	Amazon Kinesis	Ouvrir flux Kinesis, config shards. Intégrer Lambda ou MSK Connect. Test retention, encryption, scaling automatique.

Références

1. EventStoreDB Docs v21.10 – https://developers.eventstore.com
2. Apache Kafka v3.5 – https://kafka.apache.org
3. Apache Pulsar v2.10 – https://pulsar.apache.org
4. Axon Framework & Server v4.9 – https://docs.axoniq.io
5. Debezium v2.4 – https://debezium.io
6. NATS JetStream v2.10 – https://docs.nats.io/jetstream