Kafka vs RabbitMQ: Architecture Decision for Event-Driven Systems

Take a typical fleet-telemetry platform: roughly 4,000 vehicles sending a sustained 2,000 events per second, read by consumers ranging from a real-time dashboard to a nightly analytics batch job. It's a common shape, and a good one for comparing the two brokers.

The candidates

Kafka and RabbitMQ both entered the shortlist. RabbitMQ is a natural fit for task queues and routing-heavy workloads; Kafka is built around durable, replayable logs.

What decided it

Three requirements point to Kafka:

1. Replay. When the analytics team fixes a bug in an aggregation job, they need to reprocess the last 7 days of telemetry. With Kafka's log retention, that's a configuration change, not a data-recovery exercise.
2. Multiple independent consumers at different speeds. The real-time dashboard and the nightly batch job read the same stream without coordinating with each other, which consumer groups handle naturally.
3. Partition-level ordering per vehicle. Keying by vehicle ID guarantees each vehicle's event order within a partition, which downstream state-machine logic depends on.

Where RabbitMQ would have won

If the workload had been command/task dispatch with complex routing (topic exchanges, per-consumer acknowledgment, priority queues) rather than a durable event stream, RabbitMQ would be the better choice. The two aren't substitutes — the decision comes down to whether you're modeling a log or a queue.