We’ve all seen it happen. A engineering team wants to feel like they belong in the "cool kids" club, so they grab Apache Kafka or a massive event b...
For further actions, you may consider blocking this person and/or reporting abuse
The speed framing causes a lot of bad event-driven designs. The real value is usually decoupling ownership and making state changes observable across boundaries. But that only works if the team is ready to own schema evolution, replay, ordering assumptions, and operational visibility.
well said Alex :)
speaking of speed and EDD; If well designed, I can see the decrease in development friction in cross cutting concerns across domains which eventually will result in faster development.
Yes, that is the part teams usually feel later rather than during the design review. EDA can reduce local coupling, but it also creates new coordination surfaces: event contracts, replay behavior, ownership of failures, and debugging across domains. The speed win is real only when those surfaces are deliberately owned.
I can see your point , you may realize/feel/taste those benefits later but I think the benefits must be clearly perceivable from the beginning even in the design meetings.
you should be able to clearly even in the design meeting say how specifically EDA is going to benefit the project. (despite of its cost) specifically being the key word , not things like decoupling and blabla :) but concretely stating that for example:
when the user purchases an item , EDA provide the ability for the billing to issue invoice even though shipping service is down and as soon as the shipping service is up the user will get notified of when they are getting their item. and two domains can release independently but off course we will have more complicated debugging and tracing and higher cost of infra and story goes on ...
one should be able to make such sentences even in the design meetings and in the architectural documentation.
I agree with that. If the benefits cannot be explained during design, the team is probably using EDA as architecture theater.
The value should be concrete enough to name early: which domains stop blocking each other, which cross-cutting concern becomes easier, what failure mode becomes less coupled, and what trade-off the team is accepting in return.
The later benefits are real, but the design meeting should still have a crisp reason for choosing the model.
I could not agree more :)
I wish one day we can design something together 😊
Great breakdown. EDA is often misunderstood as a performance upgrade, when its real value is decoupling, scalability of ownership, and handling complex business workflows. The “use it when the domain demands it, not because it’s trendy” point is especially important — architecture should solve constraints, not create them. Great insights.
Thank you Luis for your comment , I am very glad to see you see it that way too :)
The decoupling-not-speed framing is the one people skip, so good on you for leading with it. One cost I'd add to your list: the day you go event-driven, you trade a stack trace for a distributed-tracing problem. A sync call that fails hands you a line number. A dropped event hands you "it's somewhere between the producer and four consumers," and "where did this event go" becomes the new 2am question. Your litmus test is great for deciding to adopt. Did you find a similar signal for when a team is ready to operate it, i.e. tracing and dead-letter handling in place before the first OrderPlaced fans out?
Thank you Arun for your comment :)
precisely , that is one of the complexity axis that I was trying to mentioned.
put smile on my face when I hear the out of the box thinking and not following trends.