Messaging & Event Driven design
Source: Dev.to
Event‑Driven Architecture (EDA)
Event‑driven architecture is a modern pattern built from small, decoupled services that publish, consume, or route events.
- Event: Represents a change in state or an update (e.g., an item placed in a shopping cart, a file uploaded, an order ready to ship).
- Events may carry the full state (item name, price, quantity) or only identifiers (e.g., “order #8942 was shipped”) that can be used to look up related information.
Unlike traditional request‑driven models, EDA promotes loose coupling between producer and consumer services, making it easier to scale, update, and independently deploy components.
Amazon SQS (Simple Queue Service)
- Fully managed message queue
- Used for decoupling application components
Queue Types
| Type | Delivery Guarantees | Ordering |
|---|---|---|
| Standard | At‑least‑once delivery | Best‑effort ordering |
| FIFO | Exactly‑once processing | Strict ordering |
Amazon SNS (Simple Notification Service)
- Pub/Sub messaging service
- One message can be delivered to multiple subscribers
Common Subscribers
- SQS
- Lambda
- Email / HTTP endpoints
SNS vs. SQS
- SNS pushes messages to subscribers.
- SQS polls for messages.
Fan‑out pattern: SNS → multiple SQS queues.
Amazon EventBridge
Amazon EventBridge is a serverless event bus that facilitates event‑driven architectures. It connects different services and applications by routing events from sources (AWS services, custom applications, third‑party software) to targets such as AWS Lambda, Amazon SNS, Amazon SQS, and more.
EventBridge enables decoupled systems where components operate independently and react to events in real time, enhancing scalability, flexibility, and resilience.
When to Use Which Service
| Service | Typical Use Cases |
|---|---|
| SQS | Asynchronous processing, buffering |
| SNS | Fan‑out notifications |
| EventBridge | Event routing across services |
Lab 7: Messaging with Amazon SQS
Objective
- Decouple application components using SQS.
- Process messages asynchronously with Lambda.
- Configure a Dead‑Letter Queue (DLQ) for failure handling.
Architecture Overview
Producer (Lambda / CLI) → Amazon SQS → Consumer (Lambda)
↳ Dead Letter Queue
Steps
-
Create a Standard Queue
- Navigate to SQS → Create queue.
- Type: Standard
- Visibility timeout: 60 seconds
- Click Create queue.
-
Create a Dead Letter Queue (DLQ)
- Create another SQS queue named
order-processing-dlq. - In the main queue’s settings, configure the DLQ:
- Max receives: 3
- Create another SQS queue named
-
Create a Lambda Consumer
- Navigate to Lambda → Create function.
- Runtime: Python 3.12
- Add an SQS trigger pointing to the queue created in step 1.
- Use the following sample code:
def lambda_handler(event, context): for record in event['Records']: print(record['body']) -
Send a Message to the Queue
aws sqs send-message \ --queue-url <QUEUE_URL> \ --message-body "Test message"
Validation
- Verify that the message is processed by the Lambda function.
- Confirm that messages that fail processing after the maximum receive count are moved to the DLQ.