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. CommandAn 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 & ConsEvents 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 busRegarding 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 & CQRSFinally, patterns such as event sourcing & CQRS combine both events and commands to great effect. |
Join 15K readers and level up you AWS game with just 5 mins a week.
Last week, we looked at 6 ways to version event schemas [1] and found the best solution is to avoid breaking changes and minimise the need for versioning. But how exactly do you do that? How can you prevent accidental breaking changes from creeping in? You can detect and stop breaking changes: At runtime, when the events are ingested; During development, when schema changes are made; Or a combination of both! Here are three approaches you should consider. 1. Consumer-Driven Contracts In...
Synchronous API integrations create temporal coupling [1] between two services based on their respective availability. This is a tighter form of coupling and often necessitates techniques such as retries, exponential delay and fallbacks to compensate. Event-driven architectures, on the other hand, encourage loose coupling. But we are still bound by lessor forms of coupling such as schema coupling. And here lies a question that many students and clients have asked me: “How do I version my...
ICYMI, Serverless Inc. recently announced the Serverless Container Framework. It allows you to switch the compute platform between Lambda and Fargate with a one-liner config change. This is a game-changer for many organizations! It'd hopefully nullify many of the "lock-in" worries about Lambda, too. As your system grows, if Lambda gets expensive, you can easily switch to Fargate without changing your application code. To be clear, this is something you can already do yourself. It's not a...