What is Event-Driven Architecture (EDA)?

Event-driven architecture is a design style where services announce immutable facts as events, and consumers react independently. The precision the vendor pages skip lives in two words: an event is an immutable, past-tense fact — OrderPlaced, not PlaceOrder — and the producer neither knows nor cares who reacts. That indifference is the architecture: consumers are added, removed, and broken without the producer changing a line, which is decoupling at its most literal. And EDA is a spectrum, not a religion — a single webhook is event-driven; so is a streaming estate; most healthy systems are hybrids.

Key takeaways

One fact, many reactions

// JavaScript — Cloud Code (cloud/main.js)
// Everyday EDA: the write IS the event; consumers react independently
Parse.Cloud.afterSave('Order', async (req) => {
  const order = req.object;
  const becamePlaced = order.get('status') === 'placed' &&
    req.original?.get('status') !== 'placed';
  if (!becamePlaced) return;

  // Consumers of one fact — none knows about the others:
  await Parse.Cloud.httpRequest({          // fulfillment system (webhook)
    method: 'POST', url: process.env.FULFILL_WEBHOOK,
    body: { event: 'order.placed', id: order.id },
  });
  await enqueueConfirmationEmail(order);   // async job queue
  // Live Query pushes the change to every open dashboard automatically
});

// Flutter / Dart — Back4app Flutter SDK
// The client as event consumer: subscribe to facts, react on arrival
final orders = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'placed');
final sub = await LiveQuery().client.subscribe(orders);
sub.on(LiveQueryEvent.create, (order) => showNewOrder(order));
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// iOS / Swift — Back4app Swift SDK
// The client as event consumer: subscribe to facts, react on arrival
let orders = Order.query("status" == "placed")
let sub = try await orders.subscribe()
sub.handleEvent { _, event in
    if case .created(let order) = event { showNewOrder(order) }
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// Android / Kotlin — Back4app Android SDK
// The client as event consumer: subscribe to facts, react on arrival
val orders = ParseQuery.getQuery<ParseObject>("Order")
orders.whereEqualTo("status", "placed")
val sub = ParseLiveQueryClient.Factory.getClient().subscribe(orders)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, order ->
    showNewOrder(order)
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

One fact — an order became placed — and four consumers, none aware of the others: a fulfillment system notified by webhook, an email job enqueued, analytics counting, dashboards updating over a live subscription. Adding a fifth consumer changes nothing upstream. That is the whole pitch, in one save.

The vocabulary, untangled

The SERP’s terminology chaos, resolved in one table — three message kinds by intention, not transport:

Fowler’s warning deserves its quote: beware the passive-aggressive command — an “event” the producer emits while secretly requiring one specific consumer to act. If the flow breaks when that consumer doesn’t respond, it was a command all along, and naming it an event just hid the coupling. (The infrastructure words — broker, router, bus, channel, topic — are near-synonyms for the middle box; the pub/sub entry covers that machinery, of which EDA is the generalizing architecture.)

Event-driven vs. request-response

The one-sentence rule: if the caller needs the result to continue, request-response; if the producer’s job is complete before any reaction begins, events. Placing the order needs a synchronous answer (“did it succeed?”); everything after — email, fulfillment, analytics — is reactions to a fact, which is why real systems are hybrids by design rather than by compromise.

Fowler’s three flavors — and where event sourcing actually fits

The disambiguation that saves meetings: event sourcing is how one system stores data; EDA is how systems talk. They compose but neither requires the other. One more line the vendors blur: pub/sub delivery forgets — late subscribers miss what fired before they arrived — while streaming (the Kafka-style ordered log) remembers, letting consumers replay from any point; choose by whether history is part of the product.

Choreography vs. orchestration

The mirror-image rule shared with the orchestration entry: orchestrate when someone must own the outcome of a workflow; choreograph when producers genuinely don’t care what happens next. Long business transactions across services take the saga shape either way — local transactions chained by events or by an orchestrator, undone by compensations rather than rollback.

Everyday EDA — no broker required

The section the architecture centers never write: most app developers already run event-driven patterns without a message broker in sight. A beforeSave/afterSave trigger is a consumer of data-change events. A webhook is an event crossing company boundaries over plain HTTP. A live query is pub/sub with clients as subscribers. A background job enqueued by a trigger is an event spawning async work. The code tabs above are exactly this stack — the write is the event, the trigger is the router, and the consumers are a webhook, a queue, and a subscription. Dedicated brokers (Kafka, RabbitMQ, NATS — with CloudEvents as the standard envelope) earn their operational weight when event volume, replay, and cross-team contracts demand it; the architecture starts much earlier, and “do I need a broker?” usually answers itself: not yet.

Common use cases

• Order and payment flows — one fact, many departments: the canonical e-commerce pipeline.
• Cross-system integration — services owned by different teams reacting without direct calls or shared deploys.
• Real-time features — dashboards, feeds, and presence as client-facing event consumption.
• Spiky workloads — queues buffering bursts so consumers drain at their own pace.
• Audit and replay — streaming logs where “what happened, in order” is itself the product.

Should you go event-driven? A decision matrix

Limitations and trade-offs

• Debugging loses the call stack. A request that fans into five async hops is traceable only by correlation IDs carried from the first event — retrofit is miserable; wire them from day one.
• Eventual consistency reaches the UI. The user updates a profile and the next screen shows the old name; either design the UX for it or keep that path synchronous.
• Duplicates are contractual. At-least-once delivery makes idempotent consumers mandatory — the same contract queues impose, because it is the same machinery.
• Schemas evolve under consumers’ feet. Events are contracts with unknown subscribers: additive changes only, versioned topics for breaks, and tolerant readers everywhere.
• Emergent workflows hide. Pure choreography means nobody can point at the business process; when auditors or on-call engineers need to, add the orchestrator.

Event-driven patterns on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The everyday-EDA section is its feature list read as architecture: every save is an event, afterSave triggers are server-side consumers with the full JavaScript ecosystem, Live Queries fan facts out to clients over managed WebSockets, webhooks carry them to external systems, and background jobs absorb the slow reactions — the code tabs show the whole loop from one order save. The disciplines this article insists on remain yours (idempotent after-hooks, past-tense thinking, sync where the caller needs answers), while the broker-shaped infrastructure — fan-out, delivery, connection fleets — arrives as platform behavior, and graduating to a dedicated streaming broker later is an addition to this architecture, not a rewrite of it.