The strongest reason to adopt event-driven architecture is not that it sounds modern. It is that it lets systems react to the same change without being tightly coupled to the same request path.
That is useful when:
- multiple services care about the same domain event
- near-real-time reactions matter
- consumers should evolve independently
Kafka is one way to do that because it gives you a durable log of events rather than a point-to-point call.
What Changes
Instead of one service directly calling every dependent system, it publishes an event and moves on. Downstream systems decide how to consume it.
A simple event contract might look like this:
{
"type": "order.created",
"orderId": "ord_123",
"customerId": "cus_456",
"occurredAt": "2024-07-20T10:00:00Z"
}
That buys you decoupling. It also buys you more operational complexity:
- ordering questions
- idempotency
- replay behavior
- lag and consumer health
So the real argument for Kafka is not "real time is better than cron jobs" as a slogan. It is that some domains benefit from expressing business changes as an event stream instead of a set of tightly linked synchronous calls.
When It Is Worth It
Use event-driven architecture when multiple independent reactions matter.
Do not use Kafka just to avoid writing straightforward application code for a simple CRUD system.
Further Reading