Events decouple producers from consumers, and that is genuinely valuable. What is less often said out loud is what you give up.
What gets harder
- Debugging. There is no call stack across a broker, so tracing has to be designed in from the first day rather than added after the first incident.
- Ordering. Anything that assumes two events arrive in the order they were emitted will eventually be wrong.
- Meaning. A published event becomes an API. Changing its shape is a breaking change to consumers you may not know about.
What makes it work
Version events explicitly and treat the schema as a contract with a registry behind it. Make every consumer idempotent, because redelivery is a promise the broker makes, not a failure. And publish facts about what happened rather than instructions about what to do, or you have built remote procedure calls with worse ergonomics.
2 Comments
Leave a comment
Sign in to leave a comment.
Signing in is unavailable right now.







Omar Haddad
July 9, 2024The facts-not-instructions distinction took our team two years to learn. We had events called ProcessRefund and wondered why the consumer felt like a servant.
Muhammed Senussi
AuthorJuly 9, 2024That naming test is a good one. If an event reads like a command, the producer still knows too much about who is listening.