Event-Driven Architecture Fundamentals

Event-driven architecture (EDA) is a software design pattern where the flow of the application is determined by events — significant changes in state that the system needs to react to. Instead of services calling each other directly and waiting for responses, they communicate through events, creating loosely coupled, highly scalable systems.

---

What Is an Event?

An event is a record of something that happened. It is an immutable fact. Events describe a change in state, not a command to do something.

Examples of events:

Domain	Event
E-commerce	OrderPlaced, PaymentProcessed, ItemShipped
IoT	TemperatureReadingReceived, MotionDetected
User activity	UserSignedUp, ProfileUpdated, PasswordChanged
Infrastructure	InstanceLaunched, DeploymentCompleted, AlarmTriggered

An event typically contains:

• Event type — what happened (e.g. OrderPlaced)
• Timestamp — when it happened
• Source — what system produced it
• Payload — the data associated with the event (e.g. order details)

{
  "eventType": "OrderPlaced",
  "timestamp": "2025-03-15T10:30:00Z",
  "source": "order-service",
  "payload": {
    "orderId": "ORD-12345",
    "customerId": "CUST-789",
    "total": 49.99,
    "items": ["SKU-001", "SKU-042"]
  }
}

---

Synchronous vs Asynchronous Communication

Before diving deeper into EDA, it is important to understand the two fundamental communication styles in distributed systems.

Synchronous (Request-Response)

Service A calls Service B and waits for a response before continuing. This is the traditional approach — think REST API calls or gRPC.

Service A  ——request——>  Service B
Service A  <——response——  Service B

Characteristics:

• Simple to understand and debug
• Tight coupling — A must know about B
• A is blocked while B processes the request
• If B is slow or down, A is affected directly

Asynchronous (Event-Driven)

Service A emits an event. Service B (and potentially Services C, D, and E) consume the event independently. Service A does not wait for any response.

Service A  ——event——>  [Event Channel]  ——>  Service B
                                         ——>  Service C
                                         ——>  Service D

Characteristics:

• Loose coupling — A does not know who consumes the event
• Non-blocking — A continues immediately after emitting
• Multiple consumers can react to the same event
• More resilient — consumers can process events at their own pace

---

Core Concepts of Event-Driven Architecture

1. Producers

Producers are the services or components that detect a change in state and publish an event. A producer does not know (or care) who will consume the event.

2. Event Channel (Broker / Bus)

The event channel is the intermediary that receives events from producers and delivers them to consumers. On AWS, this role is fulfilled by services like SQS, SNS, and EventBridge.

3. Consumers

Consumers are the services that subscribe to events and react to them. A consumer processes the event and performs its own logic — sending an email, updating a database, triggering a workflow.

4. Event Router

An event router evaluates incoming events against rules and directs them to the correct consumers. Amazon EventBridge is a prime example of an event router.

---

Key Patterns in Event-Driven Architecture

Point-to-Point (Queue-Based)

A single producer sends a message to a queue, and a single consumer processes it. Each message is processed exactly once by one consumer. This is the pattern behind Amazon SQS.

Producer  ——>  [Queue]  ——>  Consumer

Use cases: order processing, task distribution, work queues.

Publish-Subscribe (Pub/Sub)

A producer publishes an event to a topic. Multiple subscribers receive a copy of the event independently. This is the pattern behind Amazon SNS.

Producer  ——>  [Topic]  ——>  Subscriber A
                        ——>  Subscriber B
                        ——>  Subscriber C

Use cases: notifications, fan-out processing, broadcasting updates.

Event Streaming

Events are written to an ordered, durable log. Consumers read from the log at their own pace and can replay events. This is the pattern behind Amazon Kinesis and Apache Kafka.

Producer  ——>  [Stream / Log]  ——>  Consumer A (real-time)
                                ——>  Consumer B (batch, 5 mins behind)

Use cases: analytics, audit trails, change data capture.

Event Sourcing

Instead of storing the current state, you store every event that led to the current state. The state is reconstructed by replaying events.

Use cases: financial transactions, audit-critical systems, undo/redo functionality.

---

Benefits of Event-Driven Architecture

Benefit	Description
Loose coupling	Services communicate through events, not direct calls — they can evolve independently
Scalability	Producers and consumers scale independently based on their own load
Resilience	If a consumer is temporarily unavailable, events are buffered and processed later
Extensibility	Adding new functionality means adding a new consumer — no changes to existing services
Real-time responsiveness	Systems react to events as they happen rather than polling for changes

---

Challenges of Event-Driven Architecture

Challenge	Description
Eventual consistency	Data across services may be temporarily out of sync
Debugging complexity	Tracing an event through multiple services is harder than following a synchronous call stack
Ordering guarantees	Ensuring events are processed in the correct order requires careful design
Idempotency	Consumers must handle duplicate events gracefully
Schema evolution	Changing the structure of events without breaking consumers requires versioning

---

Event-Driven Architecture on AWS

AWS provides a rich set of managed services for building event-driven systems:

Service	Role	Pattern
Amazon SQS	Message queue	Point-to-point
Amazon SNS	Notification service	Pub/Sub
Amazon EventBridge	Event bus and router	Event routing with rules
AWS Step Functions	Workflow orchestration	Stateful coordination
Amazon Kinesis	Data streaming	Event streaming
AWS Lambda	Serverless compute	Event consumer

Throughout this course, we will explore each of these services in depth, learn when to use each one, and build patterns that combine them for robust, production-ready architectures.

---

Summary

Event-driven architecture decouples producers from consumers, enabling systems that are scalable, resilient, and easy to extend. Events are immutable facts describing state changes, and they flow through channels (queues, topics, buses) to reach interested consumers. AWS offers a comprehensive suite of services for building event-driven systems — SQS, SNS, EventBridge, Step Functions, and more. In the next lesson, we will begin with Amazon SQS, the foundational queue service.