Event-Driven Architecture: Building Reactive Apps with EventBridge & SQS

Why Event-Driven Architecture Is Reshaping Modern Web Development

The web has moved far beyond the days of simple request-response cycles. Today’s users expect real-time updates, instant notifications, and seamless experiences across devices. Behind the scenes, the applications delivering these experiences are processing millions of asynchronous events every second.

This is where event-driven architecture (EDA) comes in.

Instead of tightly coupling services together — where Service A calls Service B, which calls Service C in a fragile chain — EDA lets services communicate through events. A service emits an event (“order placed,” “user signed up,” “inventory updated”), and any interested service can react to it independently.

The result? Applications that are:

• More scalable — each component scales independently
• More resilient — a failure in one service doesn’t cascade
• More flexible — adding new functionality means subscribing to existing events, not rewriting upstream code
• Faster to develop — teams can work on services in parallel

According to a 2024 survey by O’Reilly, 68% of organizations building cloud-native applications now use some form of event-driven architecture, up from 43% in 2021. The shift is not a trend — it’s a fundamental change in how we design systems.

In this guide, we’ll explore how to build reactive web applications using two of AWS’s most powerful services for EDA: Amazon EventBridge and Amazon SQS. We’ll cover architecture patterns, practical code examples, performance considerations, and real-world best practices drawn from production deployments.

Understanding the Core Components

Amazon EventBridge: The Intelligent Event Router

Amazon EventBridge is a serverless event bus that makes it easy to connect applications using events. Think of it as a smart switchboard: events come in, and EventBridge routes them to the right targets based on rules you define.

Key capabilities include:

• Content-based filtering — route events based on their payload, not just their source
• Schema registry — automatically discover and track event schemas
• SaaS integration — natively connect to partners like Shopify, Zendesk, Auth0, and more
• Archive and replay — store events and replay them for debugging or reprocessing
• Cross-account and cross-region delivery — ideal for enterprise-scale architectures

EventBridge can handle over tens of millions of events per second across an AWS account, with a default soft limit of 2,400 puts per second per account (easily raised via service quotas).

Amazon SQS: The Reliable Message Buffer

Amazon SQS is one of the oldest AWS services (launched in 2004) and remains one of the most critical. It’s a fully managed message queuing service designed for decoupling and buffering.

SQS comes in two flavors:

Feature	SQS Standard	SQS FIFO
Throughput	Nearly unlimited	3,000 messages/sec (with batching)
Ordering	Best-effort	Strict FIFO
Delivery	At-least-once	Exactly-once processing
Use case	High-throughput workloads	Order-sensitive workflows
Cost (per million requests)	~$0.40	~$0.50

SQS excels at:

• Buffering traffic spikes — absorb bursts without overwhelming downstream services
• Dead-letter queues (DLQ) — capture failed messages for later analysis
• Visibility timeouts — prevent multiple consumers from processing the same message
• Long polling — reduce empty responses and costs

Why Use Both Together?

EventBridge and SQS are complementary, not competing services. Here’s a practical way to think about it:

• EventBridge decides where events should go (routing logic)
• SQS ensures events get there reliably (delivery guarantee and buffering)

A common pattern is: EventBridge receives an event → applies rules → fans out to multiple SQS queues → individual services consume from their respective queues at their own pace.

This combination gives you intelligent routing and resilient processing — the best of both worlds.

Designing a Reactive Web Application: A Practical Example

Let’s walk through a concrete example. Imagine you’re building an e-commerce platform (a domain we know well at Lueur Externe, having delivered Prestashop and custom e-commerce solutions since 2003).

When a customer places an order, multiple things need to happen:

1. Payment processing — charge the customer
2. Inventory update — decrement stock
3. Notification service — send confirmation email
4. Analytics pipeline — record the event for reporting
5. Fraud detection — analyze the transaction in real time

In a monolithic architecture, all five steps happen synchronously in a single request. If the email service is slow, the entire checkout is slow. If inventory fails, the payment might already be charged.

With EDA, the checkout service simply emits an OrderPlaced event. Each downstream service reacts independently.

Architecture Diagram (Conceptual)

[Web App] → [API Gateway] → [Lambda: CreateOrder]
                                      |
                                      ▼
                              [EventBridge Event Bus]
                              /    |    |    \     \
                             ▼     ▼    ▼     ▼     ▼
                          [SQS]  [SQS] [SQS] [SQS] [Lambda]
                          Pay    Inv   Email  Analyt  Fraud
                           |      |     |      |       |
                           ▼      ▼     ▼      ▼       ▼
                        [Lambda][Lambda][SES] [Kinesis][Step Fn]

Each SQS queue acts as a buffer, ensuring that even if the notification service goes down for 10 minutes, no events are lost. Messages simply accumulate in the queue and get processed once the service recovers.

Implementation: Step-by-Step with Code

Step 1: Define the Event Schema

First, define a clear schema for your event. Consistent schemas are the backbone of any EDA system.

{
  "source": "com.mystore.orders",
  "detail-type": "OrderPlaced",
  "detail": {
    "orderId": "ord-2024-78432",
    "customerId": "cust-9921",
    "totalAmount": 149.99,
    "currency": "EUR",
    "items": [
      { "sku": "WIDGET-001", "quantity": 2, "price": 49.99 },
      { "sku": "GADGET-007", "quantity": 1, "price": 50.01 }
    ],
    "timestamp": "2025-01-15T14:32:00Z"
  }
}

Step 2: Publish the Event to EventBridge

Using the AWS SDK for Node.js (v3):

import { EventBridgeClient, PutEventsCommand } from "@aws-sdk/client-eventbridge";

const client = new EventBridgeClient({ region: "eu-west-1" });

export async function publishOrderEvent(order) {
  const command = new PutEventsCommand({
    Entries: [
      {
        Source: "com.mystore.orders",
        DetailType: "OrderPlaced",
        Detail: JSON.stringify({
          orderId: order.id,
          customerId: order.customerId,
          totalAmount: order.total,
          currency: "EUR",
          items: order.items,
          timestamp: new Date().toISOString(),
        }),
        EventBusName: "mystore-events",
      },
    ],
  });

  const response = await client.send(command);
  console.log(`Event published. FailedEntryCount: ${response.FailedEntryCount}`);
  return response;
}

Step 3: Create EventBridge Rules with Content Filtering

Here’s where EventBridge shines. You can create different rules for different consumers:

# AWS SAM / CloudFormation
HighValueOrderRule:
  Type: AWS::Events::Rule
  Properties:
    EventBusName: mystore-events
    EventPattern:
      source:
        - "com.mystore.orders"
      detail-type:
        - "OrderPlaced"
      detail:
        totalAmount:
          - numeric: [">=", 500]
    Targets:
      - Arn: !GetAtt FraudDetectionQueue.Arn
        Id: "FraudTarget"

AllOrdersRule:
  Type: AWS::Events::Rule
  Properties:
    EventBusName: mystore-events
    EventPattern:
      source:
        - "com.mystore.orders"
      detail-type:
        - "OrderPlaced"]
    Targets:
      - Arn: !GetAtt InventoryQueue.Arn
        Id: "InventoryTarget"
      - Arn: !GetAtt NotificationQueue.Arn
        Id: "NotificationTarget"
      - Arn: !GetAtt AnalyticsQueue.Arn
        Id: "AnalyticsTarget"

Notice the power here: only orders above €500 trigger fraud detection, while all orders flow to inventory, notifications, and analytics. This content-based routing eliminates the need for downstream services to filter irrelevant events.

Step 4: Consume from SQS with Lambda

Each service consumes from its own SQS queue:

// Inventory service Lambda handler
export async function handler(event) {
  for (const record of event.Records) {
    const orderEvent = JSON.parse(record.body);
    const detail = JSON.parse(orderEvent.detail);

    for (const item of detail.items) {
      await decrementStock(item.sku, item.quantity);
      console.log(`Stock decremented: ${item.sku} by ${item.quantity}`);
    }
  }

  return { statusCode: 200 };
}

Step 5: Configure Dead-Letter Queues for Resilience

Always set up a DLQ. If a message fails processing after a configured number of retries, it moves to the DLQ instead of being lost or blocking the queue:

InventoryQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: mystore-inventory-queue
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt InventoryDLQ.Arn
      maxReceiveCount: 3

InventoryDLQ:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: mystore-inventory-dlq
    MessageRetentionPeriod: 1209600  # 14 days

Performance Benchmarks and Cost Analysis

Let’s look at real numbers for a mid-size e-commerce platform processing 50,000 orders per day (a realistic volume for a growing online store).

Event Volume Breakdown

• 50,000 orders → 50,000 EventBridge puts
• Each order fans out to 4 SQS queues → 200,000 SQS messages
• 5% of orders (high value) → 2,500 additional fraud detection events

Monthly Cost Estimate

Service	Volume/Month	Cost
EventBridge events	1.5M custom events	~$1.50
SQS Standard messages	6M messages	~$2.40
Lambda invocations	7.5M (128MB, 200ms avg)	~$3.13
Total		~$7.03/month

That’s remarkably cost-effective for an architecture that can handle massive traffic spikes without any provisioning. During a Black Friday sale where orders spike 10x, costs increase linearly — but there’s no risk of downtime, no servers to scale manually, and no load balancers to reconfigure.

Latency Performance

In production deployments, typical end-to-end latencies look like:

• Event publication to EventBridge: 20-50ms
• EventBridge rule evaluation and delivery to SQS: 50-100ms
• SQS to Lambda trigger: 50-200ms (depending on polling frequency)
• Total event-to-processing time: 120-350ms under normal load

For most web applications, this near-real-time latency is more than sufficient. Users see their order confirmation instantly (synchronous response), while all the downstream processing happens reactively in the background.

Best Practices from Production Deployments

At Lueur Externe, where we architect AWS solutions as certified AWS Solutions Architects, we’ve identified several critical best practices from real-world EDA deployments:

1. Design Events as First-Class Citizens

• Use a schema registry from day one. EventBridge’s built-in schema registry helps, but consider supplementing with custom documentation.
• Follow a naming convention: {domain}.{entity}.{action} (e.g., orders.order.placed)
• Include a correlation ID in every event for distributed tracing

2. Plan for Idempotency

In any distributed system, messages can be delivered more than once. Every consumer must be idempotent — processing the same event twice should produce the same result.

Strategies include:

• Using the orderId as a deduplication key in your database
• Implementing conditional writes (e.g., DynamoDB conditional expressions)
• Using SQS FIFO with deduplication IDs for critical paths

3. Monitor and Alert Aggressively

Key CloudWatch metrics to watch:

• EventBridge: FailedInvocations, ThrottledRules
• SQS: ApproximateAgeOfOldestMessage (critical!), NumberOfMessagesSent, ApproximateNumberOfMessagesVisible
• DLQ: ApproximateNumberOfMessagesVisible (should always be 0 in steady state)

Set an alarm on DLQ depth > 0. Any message in a DLQ represents a processing failure that needs human attention.

4. Use Event Replay for Recovery

EventBridge allows you to archive all events and replay them. This is invaluable when:

• A bug in a consumer caused incorrect processing
• A new service needs to backfill historical data
• You need to reproduce a production issue in staging

Enable archiving on your event bus from day one. The storage cost is minimal compared to the recovery capability it provides.

5. Implement Circuit Breakers

If a downstream service is consistently failing, you don’t want to exhaust your SQS retry budget. Implement circuit breaker patterns using:

• Lambda reserved concurrency (limit the blast radius)
• SQS visibility timeout tuning
• Step Functions for complex retry logic with exponential backoff

Common Pitfalls to Avoid

• Over-engineering events: Not everything needs to be an event. Synchronous calls are fine for simple, low-latency, tightly-coupled operations.
• Missing dead-letter queues: Never deploy an SQS queue without a DLQ in production. Ever.
• Ignoring event ordering: If order matters, use SQS FIFO with message group IDs. Standard SQS does not guarantee order.
• Large event payloads: EventBridge has a 256KB event size limit. For larger payloads, store the data in S3 and include the S3 reference in the event (the “claim check” pattern).
• No schema versioning: Events will evolve. Plan for backward-compatible schema changes using optional fields and versioning headers.

When NOT to Use Event-Driven Architecture

EDA isn’t a silver bullet. It adds complexity. Avoid it when:

• Your application is a simple CRUD with few moving parts
• You need strict synchronous responses (e.g., real-time pricing calculations)
• Your team is small and unfamiliar with distributed systems concepts
• Debugging and tracing distributed events is beyond your current observability maturity

Start simple. Adopt EDA incrementally for the parts of your system that genuinely benefit from decoupling and asynchronous processing.

Conclusion: Build for the Future, Start Today

Event-driven architecture with AWS EventBridge and SQS is no longer an advanced pattern reserved for tech giants. It’s an accessible, cost-effective, and battle-tested approach to building web applications that are reactive, resilient, and ready to scale.

The combination of EventBridge’s intelligent routing and SQS’s reliable buffering gives you a powerful foundation for everything from e-commerce platforms to real-time dashboards, IoT systems, and beyond.

The key is to start with a clear understanding of your events, invest in schemas and observability from day one, and adopt the pattern incrementally where it delivers the most value.

At Lueur Externe, we’ve been helping businesses build scalable, modern web architectures since 2003. As certified AWS Solutions Architects and e-commerce specialists, we bring deep expertise in designing event-driven systems that perform under real-world conditions. Whether you’re modernizing a monolith or building a new platform from scratch, our team is ready to help.

Ready to make your web application truly reactive? Get in touch with our cloud architecture experts and let’s design something extraordinary together.