Everyone draws event-driven architecture the same way. Three boxes: producer, broker, consumer.
That drawing hides almost every decision that comes back to bite you.
Start with the producer. Is it publishing an event or a command? Both end up in the same broker, so a lot of teams treat them the same.
An event is a fact that already happened. "VideoUploaded." The producer has no idea who's listening, and it shouldn't.
A command is a request. "TranscodeVideo." It has one intended handler, and that handler is allowed to say no.
Blur the two and you get a system that looks decoupled on the diagram while every service quietly depends on the others.
Then the broker. "We'll use Kafka" isn't a design decision. That middle box can be three different things:
A queue hands each message to one worker, and once it's processed it's gone. Great for spreading work out.
A log keeps events in order and keeps them around, so each consumer reads at its own pace and can replay the past.
A router checks each event against rules and pushes it to whoever subscribed.
Pick the wrong one and you end up bolting replay onto a queue, or fighting a log to do basic job distribution.
The consumer side has its own trap. A producer renames one field, and a consumer nobody remembered breaks in production.
And the one people mix up most: event-driven and async are different things.
You can throw work onto a background job queue and still have a tightly coupled system. Async is about when the work runs. Event-driven is about who needs to know about whom.
So EDA won't fix your scaling problem on its own. It hands you trade-offs, and you want to pick them on purpose.
I just published a free course that opens all three boxes, whether you are new to EDA or you have worked with it before. This video is going to change how you think and use EDA in your projects.
Top comments (0)