Event-Driven Architecture on AWS: Practical Patterns with SNS, SQS, Lambda, and EventBridge — insights from “Event Driven Architecture in AWS” by Walter Huber (KaWa commerce GmbH)

Why event-driven — and why now

At DevJobs.at we’ve been tracking the steady shift from monolithic systems to distributed architectures. In “Event Driven Architecture in AWS,” Walter Huber (KaWa commerce GmbH) framed that evolution clearly: away from a single codebase toward small, independent services that communicate over well-defined interfaces — increasingly asynchronous and serverless.

He also positioned his team’s perspective: KaWa commerce GmbH operates as an AWS Advanced Consulting Partner in Austria, works extensively with event-driven architectures and microservices, and holds certifications (Solution Architect, DevOps, Cloud Practitioner) as well as Solution Provider status. The examples in the talk were grounded in that hands-on experience.

From monoliths to microservices: the problem space

The architectural journey goes from “everything in one” to independently owned and operated services — each with its own API, its own architecture, its own team, and often its own database.

What is a microservice? Huber described it as an architectural and organizational approach in which software is composed of small, independent services that communicate over well-defined APIs. Each service takes on a narrow, specific job and “does it well,” with the ability to scale autonomously and evolve independently.

Crucially, the communication model is changing. Instead of always speaking synchronously via direct API calls, teams increasingly rely on asynchronous messaging — events rather than immediate request/response chains.

Synchronous vs. asynchronous: latency and failure propagation

Synchronous: when every link must work at once

Synchronous calls are fine for many APIs, especially with caching. But Huber highlighted the downsides in complex backends. In an e‑commerce example, creating an order may trigger several backend services — say, five — each fetching or updating data.

• Latency adds up: If one service needs 200 milliseconds, those delays stack — in Huber’s example, roughly one second before the original request returns.
• Failures propagate: If one link in the chain fails, the entire request can fail, and the caller must handle that failure cascade.

Asynchronous: decouple, buffer, and continue

Asynchronous communication flips the model: publish an event, then move on. Consumers receive the message when they’re ready. The publisher doesn’t block and doesn’t require every consumer to be up and reachable at the same time.

Huber showed how this decoupling improves fault tolerance and scaling. If a downstream service is in a maintenance window or temporarily down, messages aren’t lost — they queue up and get processed later.

Message brokers at a glance — and the AWS angle

Message brokers such as Apache Kafka, RabbitMQ, and newer pub/sub capabilities in Redis provide a bus for publishers and subscribers.

The challenge: operating and scaling clusters. You must install, patch, update, and monitor them; you scale hardware for load, ensure availability, and handle failover. Huber’s point wasn’t that these tools are inadequate — they’re powerful — but that the operational burden is real.

AWS provides managed building blocks that remove most of that undifferentiated heavy lifting and fit naturally with serverless. These are the services Huber walked through.

AWS Lambda: react to events and scale automatically

Lambda is “just a piece of code” triggered by an event; it processes data and emits a result. Its superpower is elastic scaling. Huber’s memorable line of thought: whether once per second or 100,000 times per second, Lambda scales with the load.

He illustrated it with an image-resizing scenario: an event signals that an image is available; a Lambda function reads it, resizes it, stores variants back to S3, and completes. No servers to manage, no manual scaling — AWS handles it.

In an event-driven design, Lambda becomes the natural compute for consuming and transforming messages: lightweight, cost-aligned (“pay only what you need”), and highly scalable.

Pub/sub on AWS: Amazon SNS for topics, Amazon SQS for buffering

Amazon SNS: topic-based fan-out

With Amazon SNS (Simple Notification Service), publishers post events to a topic. Subscribers — any services that need that information — receive the message. In Huber’s e‑commerce example, a “new order” is published to an SNS topic; services such as delivery or customer service subscribe and react.

SNS decouples senders from receivers: the publisher doesn’t need to know who consumes; it simply announces the event and SNS fans it out.

Amazon SQS: queues for durable processing

SNS by itself doesn’t handle consumer downtime; a subscriber might miss messages during maintenance. Huber’s answer is to combine SNS with SQS (Simple Queue Service):

• Fan-out: One SNS topic fans out to multiple SQS queues. Each downstream service processes from its own queue.
• Buffering: If a consumer is in a maintenance window or temporarily down, messages accumulate in its queue and get processed later.
• Throttling: A service can intentionally process at the rate its dependencies permit (e.g., a database with limited connections). Huber cited reducing 1,000 messages per second down to 100 per second by batching from SQS — protecting the database while keeping the pipeline healthy.

This SNS+SQS pattern acts as a managed message broker in AWS: robust fan-out, durable buffering, and backpressure control without running your own clusters.

Dead-letter queues and “poison messages” to watch

Huber also underscored that messages which cannot be processed (“poison messages”) should be routed to a dead-letter queue (DLQ). The DLQ needs active monitoring; if it grows, something’s wrong in the processing path.

EventBridge: the event bus for AWS services and custom events

AWS EventBridge complements SNS/SQS with flexible, rule-based routing and deep integration with AWS service events. Huber emphasized two dimensions:

• Internal AWS events: Events such as creating an EC2 instance or changes in RDS appear on EventBridge and can be consumed.
• Custom events: External services or your own applications can publish custom events to EventBridge. EventBridge then routes these to subscribers.

In Huber’s words, EventBridge behaves “kind of like Kafka”: a managed event bus that accepts messages and fans them out to subscribers — but fully managed and integrated with AWS.

AWS Step Functions: orchestrate multi-service workflows

Not every process can be left entirely to loose coupling. Some flows need a coordinator that knows when the whole job is done. Huber’s example was order processing:

• An order event is produced.
• Multiple services — for example, delivery and customer service — react and perform their tasks.
• Only when all steps are completed should a final “all done” notification be sent to another service.

Step Functions handle that orchestration. They can emit a final completion signal once all constituent steps have finished — invaluable for end-to-end correctness without tightly coupling services.

Observability and operations: X-Ray and CloudWatch

As the number of microservices grows, so does the risk of losing the big picture. Huber cautioned against that and highlighted two pillars:

• AWS X-Ray: With code-level instrumentation, you make service-to-service calls visible. You can see “where the traffic goes,” where requests flow, and where problems arise.
• Amazon CloudWatch: The long-standing service for logs and metrics. It’s key to visualize queue depth, set alerts (e.g., growing DLQs), track throughput, and build dashboards.

Without this visibility, an event-driven system is flying blind. With it, you can quickly pinpoint hot spots, latency sources, and failure modes.

Cost and scaling: “pay only what you need”

Huber returned several times to the cost profile: on AWS you pay for what you use. If you handle 100 requests, you pay for 100; if you handle 100,000, you pay for 100,000 — with no idle servers to maintain. This is especially true with Lambda and the event-driven primitives (SNS, SQS, EventBridge).

Just as important, each service can scale at its own pace. If a service can only process 100 messages per second, it processes 100 — with SQS buffering the rest. And if one component fails, the whole system doesn’t collapse; messages remain queued until the service returns.

A concrete mental model: order flows in e‑commerce

Huber anchored his examples in e‑commerce, where order events kick off multiple downstream activities. The sequence generalizes well:

• A service publishes “new order” to SNS or EventBridge.
• Several consumers (delivery, customer service, accounting, reporting) subscribe, each reading from its own SQS queue.
• Temporary outages or maintenance are absorbed — queues buffer messages.
• Multi-step flows that must emit a final completion signal are orchestrated with Step Functions.
• Lambda functions process events elastically — from low to very high rates.
• X-Ray and CloudWatch provide end-to-end visibility: flows, errors, DLQs, queue depth.

Events instead of synchronous chains, buffers instead of timeouts, orchestration where required — that was the practical throughline.

Orchestration is a challenge — solvable with the right tools

Huber called out orchestration as a challenge in event-driven systems. Knowing when “everything is done” across distributed services isn’t trivial. Step Functions address precisely that need. He also mentioned the Serverless Application Model (SAM) as a framework to build and deploy serverless applications at scale on AWS.

The message is clear: architecture first, then tools. With SAM, Step Functions, X-Ray, and CloudWatch, you get a toolkit that supports design, operations, and visibility.

Guardrails and patterns (distilled from the session)

Staying within the boundaries of the talk, here are the guardrails we noted:

• Decouple with SNS+SQS: use SNS to fan out events and SQS to buffer and throttle; isolate services from each other’s availability.
• Prefer async when sync becomes fragile: if synchronous chains add latency or amplify failures, publish events instead.
• Plan for maintenance windows: SQS buffers messages when consumers are down; no data loss, controlled backpressure.
• Orchestrate when you need end-to-end completion: let Step Functions coordinate and emit the final signal.
• Make visibility non-negotiable: X-Ray for flow-level tracing; CloudWatch for logs, metrics, dashboards, and DLQ monitoring.
• Align cost with usage: serverless and “pay only what you need” enable cost-effective architectures — even under bursty loads.

A pragmatic starting path

Following Huber’s blueprint, a pragmatic way to start in AWS could be:

1. Identify domain events: what meaningful events exist (e.g., “new order”)?
2. Define topics and queues: one SNS topic per event, one SQS queue per consumer service.
3. Encapsulate processing: one Lambda per queue, with batch sizes that match downstream capacity (throttling).
4. Model orchestrated flows: use a Step Functions state machine where you need a final “all done.”
5. Turn on observability: instrument with X-Ray; configure CloudWatch metrics and alarms for queue depth, errors, and DLQs.
6. Standardize deployments: use the Serverless Application Model (SAM) to define and deploy the serverless stack.

These steps mirror the session’s guidance — without adding the operational burden of self-managed broker clusters.

Clear benefits — clear focus

Huber’s conclusion summarized why event-driven architecture (EDA) resonates:

• Each service scales independently.
• One component’s failure doesn’t take down the whole stack.
• Costs scale with usage — from 100 requests to 100,000.
• Orchestration is tractable with the right AWS services.

This is not architectural theater; it’s a pragmatic response to latency, coupling, and operational pain in distributed systems.

Closing and a note on hiring

Huber closed by noting that KaWa commerce GmbH is looking for serverless application developers, with open roles listed on the DevJobs.at platform. If event-driven systems on AWS are your interest area, there’s a tangible path to put these ideas into daily practice.

Key takeaways from “Event Driven Architecture in AWS” by Walter Huber

• Microservices benefit from asynchronous messaging: less coupling, more resilience.
• SNS+SQS is a pragmatic broker pattern on AWS: fan-out, buffering, and throttling.
• EventBridge adds rule-based routing and deep AWS integration, plus custom events.
• Lambda delivers elastic compute — from single events to very high volumes.
• Step Functions orchestrate end-to-end flows that need a final completion signal.
• X-Ray and CloudWatch are essential for visibility into flows, errors, DLQs, and queue depth.
• “Pay only what you need” makes EDA on AWS cost-effective — regardless of load spikes.

Huber’s core message distilled: moving from fragile synchronous chains to robust, decoupled event flows yields scalability, fault tolerance, and operational clarity — using managed building blocks that fit naturally within AWS.

• 

  

  Walter Huber, CTO von KaWa commerce

  Der CTO von KaWa commerce Walter Huber gibt im Interview Einblicke in die Möglichkeiten zur Weiterentwicklung im Unternehmen, was beim Recruiting im Vordergrund steht und wie die Projekte technologisch umgesetzt werden.

  Watch now