Building solutions in the cloud is difficult. You sometimes need to bend to the will of the managed service you rely on, in order to fulfil your business requirements.
Once a development/architect team accomplishes this once (no easy feat), they now have the domain knowledge and reference code to use this managed service again next time. This leads to overly-comfortable engineering teams who fit their requirements to the solution - rather than the reverse.
When it comes to event-driven architecture, it is very easy to choose the wrong approach and “make it work”. While you will achieve what you set out to do, complexities will arise because you haven’t used these managed services in the intended way.
The purpose of this daily article series is to elevate the way you think of event-driven architecture and development. If you understand the fundamental building blocks of all the different solutions, you can infer cloud-based behaviour - rather than having to memorize it all.
To give you an example, do you know what type of Lambda invocation is made from EventBridge, SQS and API Gateway? And how many times is your Lambda Function’s invocation retried when there are failures? If you have those answers memorized, congratulations. But ask yourself: do you understand why those answers are correct?
Part 1: The Payload
Messages vs Commands vs Events
A message represents a request from one system to another, containing some kind of payload/data. Think of a message like receiving a letter in the mail from your utility provider.
Commands and events are types of messages.
A command is a message with a payload detailing an action to be taken by the downstream service. Think of a command like receiving a utility bill that you need to pay.
An event is a message with a payload detailing a state change. Think of an event like receiving a change in terms of service from your utility company.
A key distinction between the two is that events tend to be broadcast in a one-to-many model of producers/subscribers. They are not directed at a particular subscriber. So the producer does not need to be aware of its subscribers.
Whereas commands are designed to be instructions given by the producer to the consumer (notice I did not use subscriber when talking about commands here). So by nature, the producer must be aware of the consumer because it is telling it what to do.
An Example
Imagine being the employee (or piece of software) at the utility company responsible for preparing utility bills (commands) and posting them. Of course they need to be aware of the consumer (you), because they are checking your account balance and issuing a bill if required. They are sending specifically you a command. Then there is an expectation that you will in-fact pay your bill - giving this a synchronous nature.
Now imagine being the lawyer (and hopefully not a piece of Gen-AI software, yet) responsible for drafting the changes to the company’s Terms Of Service. That lawyer is not aware of who is receiving this state change of the business. They are not tailoring their content to you, and you will simply be sent a notification of a change to Terms of Service - a state change, or an event. It is the responsibility of the subscriber (you) to react to this event accordingly - giving this an asynchronous nature.
Tomorrow: Part 2
Tomorrow, the series will expand on what we discussed today. We will be bringing some computer science concepts into the foreground and (hopefully) understand why the likes of event buses and queues need messages, commands or events (according to the textbook).
Interested In More?
Connect with me on LinkedIn, Twitter and you are welcome to join the #BelieveInServerless Discord Community.
See you tomorrow!