Patterns
Kafka vs RabbitMQ for event-driven invoicing
Choosing the right broker for downstream consumers (ERP, CRM, BI)
When multiple internal consumers must react to a Scell.io event (`invoice.paid`, `signature.completed`), a broker between webhook receiver and consumers avoids coupling. Kafka: partitioned distributed log, long retention (7-30 days), trivial replay via offset, ideal for BI / data lake / fiscal audit. Throughput > 1M msg/s. High operational cost (ZooKeeper/KRaft cluster, ops). RabbitMQ: AMQP broker with queues, flexible routing patterns (topic, fanout, direct), native DLQ, ideal for business orchestration (ERP sync, CRM update, email). No replay beyond queue. Throughput ~50k msg/s per node. Choice: Kafka if > 100k events/day AND need replay > 24h AND dedicated ops team. RabbitMQ by default for classic e-invoicing workloads (< 100k events/day, replay limited to queue TTL). Recommended Scell.io pattern: webhook receiver → RabbitMQ topic exchange → N consumers (ERP, accounting, CRM, audit log).
Key facts
- Kafka: > 1M msg/s, long replay, heavy cluster ops, ideal for BI/audit
- RabbitMQ: ~50k msg/s, rich AMQP routing, native DLQ, simple ops
- Threshold: > 100k events/day + replay > 24h → Kafka
- Default e-invoicing: RabbitMQ topic exchange + N consumers
- Anti-pattern: sending webhook directly to consumers (coupling)
Code example
# 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)