When EDA Fits and When It Does Not

Benefits with a bill attached

EDA shines when many independent consumers care about the same business facts, when work can happen later (emails, analytics, search indexing, recommendations), when you need to absorb bursts with a buffer, when teams must evolve services independently, and when you need an audit trail of what happened. It is a poor fit when the user needs an immediate, consistent answer ("is this seat still available?"), when the flow is a simple sequence inside one team's service, or when the team lacks the operational maturity to run brokers, monitor consumer lag and debug asynchronous flows. Most real systems mix styles: synchronous APIs for queries and user-facing decisions that need an answer now, events for propagating facts afterwards.

A quick decision checklist

Score a proposed flow before reaching for a broker.

Use events when most answers are YES:
  [ ] Do several services need to react to this fact?
  [ ] Can the reaction happen seconds later without hurting the user?
  [ ] Should the publisher stay unaware of who reacts?
  [ ] Do we need to replay or audit what happened?
  [ ] Must we absorb traffic spikes without dropping work?

Prefer a direct call when:
  [ ] The caller needs the result to continue (validation, price, availability)
  [ ] Strong consistency is required right now
  [ ] Only one consumer exists and is owned by the same team

Post versus phone call

You post a parcel when it can arrive tomorrow; you phone when you need an answer before you hang up. Using the post for urgent questions, or calling for every parcel, both make life harder.

त्वरित जाँच: A checkout must confirm card authorisation before showing "Order confirmed". What fits that step best?

• Publishing an event and immediately showing success
• A nightly batch job
• A synchronous call (or a flow that waits for the result) before confirming
• An analytics event