Skip to content
← Back to AWS SQS, SNS & Event-Driven Architecture

You are viewing a free preview of this lesson.

Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.

View PricingCreate Account

Event-Driven Architecture Fundamentals

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.

Subscribe to continue