In the third and final part of this series, we look into how events are routed to the various services that require these events to start or continue their execution as the case may be. We also make some orders and see how Serverlesspresso works when an order is made from the Customer application.
Routing events
Events are routed to a serverless event bus using AWS Step Functions. I created rules to send events to the relevant services that require the events. These events enable communication between the application microservices.
An AWS event is a message in JSON format that shows a change in the state of a system. It contains relevant information such as what changed and the new state. Events are based on things that have happened and they cannot be undone. Microservices can monitor them and it is important to pay attention to their timing.
The workflow is in charge of managing orders and has some steps that require human interaction. The workflow sends events at these steps and waits for a response from a human before execution can continue. These events are sent to a serverless event bus, where Amazon EventBridge then sends them to the intended services using rules that have been created.
This is a pictorial representation of how Amazon EventBridge works:
Logging Events
Each Serverlesspresso event is emitted to an event bus called “Serverlesspresso”. For debugging purposes, logging is very important.
New Order
Previously, I started the OrderProcessor workflow manually from the Step Functions console.
However, in production, an event generated from the Validator service is responsible for starting the execution. The event is emitted each time a customer scans a QR code. A new rule in Amazon EventBridge that passes the Validator event to the OrderProcessor workflow was then created.
Then, I created a mock event and sent it to the event bus that was created using the CLI. A new execution in the OrderProcessor workflow then begins which verifies that the Validator event triggers the rule and starts the workflow.
Workflow started
The Order Processor workflow module generates a WorkflowStarted event to signify that the order processing sequence has begun. At this stage, the workflow confirms that the coffee shop is open and the barista has the capacity to make a customer's order. In the waiting period now, the customer has up to 15 minutes to make their coffee selection and submit the order. This is the first instance in the workflow where human interaction is needed to continue the execution.
Step Functions uses the Wait for callback Task Token pattern to coordinate with Amazon EventBridge and other services. Step Functions pass a token for any task that requires a response from an integrated service to continue. When the service has completed its execution, a signal indicating whether the execution succeeded or failed is sent back with the same token to the task so Step Functions can coordinate seemingly complex workflows with many services and actions.
The rule that receives the WorkflowStarted event containing the task token is then created. This event is sent to an AWS Lambda Function which sends the token to an AWS DynamoDB table to be stored together with the particular order number.
The Order Manager service keeps a record of each order and this includes information about the order status (e.g. whether it's been made or it's in the queue). Both the Barista and Customer applications get order lists that are either being processed or are already done from this service. To ensure that the service is always current, it listens for events that are triggered by the workflow.
When the customer makes an order from the Customer Application, the Order Manager microservice will get the task token from the DynamoDB table and send it to the Step Functions service which then uses the token to resume the workflow for that order.
Designing rules to handle events and sending them to specific targets helps to connect the backend microservices through events occurring in the workload.
Order Manager Workflow
This workflow is responsible for managing the orders made by the customers. The workflow is triggered whenever an order is made and the entry number in the dynamoDB table is updated. Then, the order processor workflow is resumed.
The OrderManager workflow handles 4 different tasks:
Customer put: This is when a customer submits a drink order. It will cross-check with the menu to see if it is available and then the table will be updated with the order details.
Cancel order: This is the path taken when an order is canceled either by the customer or the barista.
Complete Order: This is the path taken when the barista chooses the Complete button on the barista app.
Make / Unmake: This is the path taken when the barista makes an order or moves it to a pending state.
When an invalid order is made, the image below shows the execution path followed. A different execution path is followed for the valid order so an invalid order is not entered into the dynamoDB table.
Configuring the Frontends
The frontend applications are hosted with AWS Amplify. There are 3 frontend applications which are:
Display App: This is the app where the QR code is displayed and upcoming and completed drinks orders are shown on this screen.
Barista App: This is the app that allows the barista to complete and cancel orders depending on the case.
Customer App: This is the app that allows customers to place and cancel their drink orders.
The Publisher microservice is designed to get events by using EventBridge rules and these events are forwarded to topics in AWS IoT Core. The frontends listen to appropriate topics by design.
The publishing services are three lambda functions and three EventBridge rules which publish to three different topics which are the admin topic (used by the admin apps which are the barista app and the display app), the user topic (used by the customer app), and the config topic (subscribed to by all three apps for changes in system configurations)
- Display App: A QR code is displayed for customers to scan and make their orders. The images below show what is seen on the display app after an order is accepted, is being made, or when is ready.
- Barista App: The barista accepts orders and moves the drink from the preparation stage to the completion stage by selecting the appropriate buttons on the app. the barista can also close or open the store to accept new orders. Here's what it looks like:
- Customer App: This is where the customer signs up by registering their email address and then they scan the QR code which allows them to place their order. Here's what a user session on the Customer App looks like:
YouTube: {% youtube UM5TQ-uUdMQ %}
Conclusion
Serverlesspresso was built using AWS serverless offerings and this project is a great way of showing how event-driven architecture helps with decoupling services and how orchestration, authentification, etc. can easily be done using the services mentioned here.
To build your serverlesspresso, visit this site to get started.
Thanks for making it this far! Comments are greatly appreciated.