Event-Driven Architecture

Definition

A software design paradigm where components communicate through events, promoting loose coupling and enabling responsive, scalable applications.

Use Cases

Provider Equivalents

Frequently Asked Questions

What's the difference between Event-Driven Architecture and microservices?
Microservices is a way to split an application into small services with clear boundaries. Event-Driven Architecture (EDA) is a communication style where services react to events instead of calling each other directly. You can build microservices without EDA (using synchronous REST calls), and you can also use EDA in non-microservice systems. Many modern systems combine both: microservices that publish and subscribe to events.
When should I use Event-Driven Architecture?
Use EDA when you need loose coupling (multiple systems react to the same business event), asynchronous processing (don’t block the user while work happens), and scalability (many consumers can process events independently). Common fits include order processing, notifications, audit trails, data pipelines, IoT telemetry, and workflow automation. Avoid or limit EDA when you need strict, immediate consistency across steps or when your team isn’t ready to operate distributed systems (observability, retries, and idempotency).
How much does Event-Driven Architecture cost?
EDA cost depends on event volume, payload size, retention, and delivery guarantees. With managed routers/buses (e.g., EventBridge/Event Grid/Eventarc/OCI Events), you typically pay per event operation and sometimes for advanced features (schema registry, archive/replay, cross-region). If you add queues/streams (SQS, Service Bus, Pub/Sub, Kafka), costs include throughput, storage/retention, and consumer compute. Also budget for operational costs: logging/metrics/tracing, dead-letter queues, retries, and engineering time to handle failures and idempotency.

Category: software

Difficulty: advanced

Related Terms

See Also