Patterns
Kafka vs RabbitMQ pour l'event-driven invoicing
Choisir le bon broker pour les consumers downstream (ERP, CRM, BI)
Quand plusieurs consumers internes doivent réagir à un événement Scell.io (`invoice.paid`, `signature.completed`), un broker entre le webhook receiver et les consumers évite le couplage. Kafka : log distribué partitionné, rétention longue (7-30 jours), replay trivial via offset, idéal pour BI / data lake / audit fiscal. Throughput > 1M msg/s. Coût opérationnel élevé (cluster ZooKeeper/KRaft, ops). RabbitMQ : broker AMQP avec queues, routing patterns flexibles (topic, fanout, direct), DLQ native, idéal pour orchestration métier (ERP sync, CRM update, email). Pas de replay au-delà de la queue. Throughput ~50k msg/s par node. Choix : Kafka si > 100k events/jour ET besoin de replay > 24h ET équipe ops dédiée. RabbitMQ par défaut pour les workloads e-invoicing classiques (< 100k events/jour, replay limité au TTL queue). Pattern Scell.io recommandé : webhook receiver → RabbitMQ topic exchange → N consumers (ERP, accounting, CRM, audit log).
À retenir
- Kafka : > 1M msg/s, replay long, ops cluster lourd, idéal BI/audit
- RabbitMQ : ~50k msg/s, routing AMQP riche, DLQ native, ops simple
- Threshold : > 100k events/jour + replay > 24h → Kafka
- Default e-invoicing : RabbitMQ topic exchange + N consumers
- Anti-pattern : envoyer le webhook directement aux consumers (couplage)
Exemple de code
# docker-compose.yml — RabbitMQ topic exchange pour Scell events
services:
rabbitmq:
image: rabbitmq:3-management-alpine
ports: ['5672:5672', '15672:15672']
# Consumer config (pseudocode)
# exchange: scell.events (type: topic)
# binding patterns:
# erp-sync → invoice.paid, invoice.cancelled
# accounting → invoice.*
# crm-update → signature.completed, signature.declined
# audit-log → # (catch-all, persist to S3 + Athena)
# DLQ: scell.events.dlq (3 retries puis park)