Event-Driven Architecture: Know your commands from your events


Events and Commands are often used side-by-side in event-driven architectures.

Knowing their differences is important so you can choose the right approach to handling them and choose the right technology stack.

Event vs. Command

An event is a notification that something has already happened. It's a fact, and it’s immutable. e.g. a customer placed an order. Events are not directed at anyone, and we don't care how many (if any) subscribers are listening.

A command is a request to perform a specific action. It’s not just information; it’s an instruction, such as a command to process a payment. Commands are directed at an intended recipient who is responsible for fulfilling the requested action.

We often want to know the result of the action. As such, a command is often followed by an event to report the outcome of the action. e.g. a "process_payment" command is followed by a "payment_succeeded" event upon completion.

Pros & Cons

Events promote loose coupling but make systems less predictable and complex, especially when it comes to handling failures.

Commands simplify your control flow as you know where each command is going, making them easier to debug too. But you increase the coupling between components.

What to use as the bus

Regarding technology choices, EventBridge and SNS are good choices for the event bus, which must broadcast events to multiple subscribers.

SQS is not suitable here because it doesn't do broadcasts.

But SQS is a great fit for the command bus precisely because it’s a targeted delivery where you would have only one subscriber per queue.

Also, messages stay on the queue until they are either expired or processed, which is an important requirement for commands.

Event Sourcing & CQRS

Finally, patterns such as event sourcing & CQRS combine both events and commands to great effect.

Event Sourcing ensures that every change is captured as an event, as you model your system’s state as a series of events rather than snapshots.

CQRS separates read and write operations to optimize performance, where the write operations are modelled as commands.

More on event sourcing and CQRS another time!

Master Serverless

Join 17K readers and level up you AWS game with just 5 mins a week.

Read more from Master Serverless

Modern applications rarely do just one thing at a time. An API request creates an order, and then another service needs to reserve stock, another to charge the customer, another to send an email, and so on. In a serverless or event-driven architecture, follow-up actions are usually triggered by messages (either events or commands). That gives us loose coupling, better scalability, and independent services. But it also introduces a reliability problem. “What happens when the database update...

If you use Claude Code a lot, you’ve probably run into usage limits, sometimes even in short coding sessions. But cost isn’t the only problem. In long-running sessions, the context window eventually fills up, and that can cause the agent to forget earlier decisions, lose important details, or come back from compaction with gaps in its working memory. Here are three tools worth checking out if you want to reduce token usage and make longer coding sessions possible. 1. CavemanThis is a Claude...

AI agents can now scan an entire open-source codebase for exploitable vulnerabilities in hours. Frontier models carry the complete library of known bug classes in their weights. So you can simply point an AI agent at a codebase and tell it to find zero-days. This isn't theoretical. Willy Tarreau, the HAProxy lead developer, reports that security bug reports have jumped from 2–3 per week to 5–10 per day. Greg Kroah-Hartman, the Linux kernel maintainer, described what happened: "Months ago, we...