Event-Driven Architecture Explained: Pub/Sub, Event Streams, Choreography, and Trade-Offs

Event-Driven Architecture Explained: Pub/Sub, Event Streams, Choreography, and Trade-Offs

Event-driven architecture connects components through events—facts that something happened—rather than requiring every producer to call every consumer directly.

Why Use Events?

A producer can publish OrderPlaced without knowing whether email, analytics, fulfillment, or fraud systems care about it. This reduces runtime coupling and lets consumers process at their own pace.

AWS's current guidance describes event buses and pub/sub as ways to decouple producers from consumers and move routing/delivery responsibility into messaging infrastructure.

Pub/Sub vs Event Streams

Pub/sub is ideal when an event should fan out to current subscribers.

Event streams retain ordered records for some period so consumers can process independently and potentially replay them. Kafka/Kinesis-style systems fit this model.

Choose based on retention, replay, ordering, and throughput needs—not just terminology.

Choreography vs Orchestration

In choreography, services react to events without one central workflow coordinator:

OrderPlaced → Inventory reserves → Payment reacts → Fulfillment reacts

This keeps services loosely coupled but can become difficult to reason about when workflows contain many branches, compensations, and timeouts.

Use an explicit orchestrator/workflow engine when business process state needs one clear owner.

Eventual Consistency Is Part of the Model

An event consumer may process a change milliseconds or seconds after the producer commits it. Decide which product flows tolerate that lag and which require an immediate synchronous response.

Event Contracts Need Ownership

Define event names, schemas, meaning, identifiers, and compatibility rules. Prefer events that describe business facts rather than leaking internal database rows.

Consumers should be idempotent because duplicate/redelivered events are normal in many messaging systems.

When EDA Is a Good Fit

Use it when:

• several independent consumers react to one business event
• work can happen asynchronously
• bursts should be buffered
• replay/history is valuable
• producer and consumer release cycles should stay independent

Avoid it when one service simply needs an immediate response from another and asynchronous state would add complexity without value.

Final Takeaway

Event-driven architecture trades immediate coupling for asynchronous coordination. Use pub/sub for fan-out, streams when durable replay/order matters, choreography for simple reactions, and explicit orchestration when workflow state becomes complex.

References

• AWS Publish-Subscribe Pattern
• AWS EventBridge Guidance
• Azure Event-Driven Architecture Style