Event-Driven Messaging and Event Routing

What it is

An event-driven architecture lets producers emit messages or events without knowing who consumes them. Consumers react on their own schedule, so a slow or failed consumer does not break the producer.

At the professional level the question is never "should we decouple". It is which messaging service gives the ordering, delivery guarantee and fan-out the scenario needs, and how events travel between accounts, Regions and connected clients.

How it works

Choosing the messaging service

FIFO ordering is scoped to the message group ID. Use many group IDs (one per customer, for example) so different groups process in parallel while each group stays ordered.

Kinesis orders records per shard, and the partition key decides the shard. A hot partition key overloads one shard, so pick a key with high cardinality.

Idempotency and failure handling

Most services deliver at least once, so every consumer must be idempotent. A common pattern stores a processed message ID or business key in DynamoDB with a conditional write, and skips the work if the key already exists.

• Dead-letter queues catch messages that fail after a set number of receives, so one poison message does not block the queue.
• Visibility timeout must be longer than the processing time, or the message reappears and runs twice.
• Partial batch responses let a Lambda function report only the failed items in an SQS or Kinesis batch, so the whole batch is not retried.

Cross-account and cross-Region routing

EventBridge rules can target an event bus in another account or Region. The receiving bus needs a resource-based policy that allows the sender (an account ID or the whole organization), and the sending rule uses an IAM role.

Events do not chain. If a receiving account forwards events it received from another account on to a third account, EventBridge does not deliver them. Design a hub that receives directly from every source.

For Regional resilience, EventBridge global endpoints pair a primary and secondary Region, use a Route 53 health check to fail over publishing, and can replicate events to the secondary Region.

WebSocket and publish-subscribe for real time

API Gateway WebSocket APIs keep a two-way connection open to each client. The $connect, $disconnect and $default routes invoke a backend, usually Lambda.

The backend stores each connection ID, often in DynamoDB. To push a message, it posts to the connection through the API's callback URL, so the server can send without the client polling.

Pair the WebSocket API with SNS or EventBridge when many backend producers must reach many connected clients. Producers publish once, and a fan-out function pushes to each stored connection.

How the exam asks about this

• "Payment events for each account must be processed in order, but different accounts should process in parallel" -> SQS FIFO with the account ID as the message group ID.
• "Fifty workload accounts must send security findings to one central account with minimal custom code" -> EventBridge rules in each account that target a central event bus allowed by an organization-wide resource policy.
• "A trading dashboard must push price changes to thousands of browsers without polling" -> API Gateway WebSocket API with connection IDs stored in DynamoDB and a backend that posts through the callback URL.