Event-driven architecture with Kafka: when to use it and when not
By Floppai Engineering
Kafka is a superb tool and a terrible default. Use it for decoupling and scale — not because a diagram looked impressive.
Kafka has become a reflex. Someone says "events" in a meeting and a broker appears in the architecture. Sometimes that is exactly right. Often it adds operational weight a team is not ready to carry.
Good reasons to reach for Kafka
You have multiple consumers that need the same stream at different speeds. You need a durable, replayable log as a source of truth. You are decoupling producers from consumers across team boundaries. You need to absorb spikes that would otherwise overwhelm a synchronous call chain.
When a queue (or a database) is enough
If you have one producer and one consumer, a simple queue is cheaper and easier to reason about. If you mostly need request/response, do not turn it into choreography. And if your team has no one comfortable operating partitions, consumer groups and rebalancing, the maturity cost will outweigh the architectural elegance.
The honest answer is usually "it depends" — and our job is to tell you which it is for your system, not to sell you the most impressive box on the diagram.