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. 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. |
Master Serverless
Join 17K readers and level up you AWS game with just 5 mins a week.
Step Functions is often used to poll long-running processes, e.g. when starting a new data migration task with Amazon Database Migration. There's usually a Wait -> Poll -> Choice loop that runs until the task is complete (or failed), like the one below. Polling is inefficient and can add unnecessary cost as standard workflows are charged based on the number of state transitions. There is an event-driven alternative to this approach. Here's the high level approach: To start the data migration,...
Lambda Durable Functions comes with a handy testing SDK. It makes it easy to test durable executions both locally as well as remotely in the cloud. I find the local test runner particular useful for dealing with wait states because I can simply configure the runner to skip time! However, this does not work for callback operations such as waitForCallback. Unfortunately, the official docs didn't include any examples on how to handle this. So here's my workaround. The handler code Imagine you're...
Lambda Durable Functions is a powerful new feature, but its checkpoint + replay model has a few gotchas. Here are five to watch out for. Non-deterministic code The biggest gotcha is when the code is not deterministic. That is, it might do something different during replay. Remember, when a durable execution is replayed, the handler code is executed from the start. So the code must behave exactly the same given the same input. If you use random numbers, or timestamps to make branching...