In this second part of the series "Building Serverlesspresso", we look into how the workflow for the various distributed components is designed and how the workflow is validated by running tests to see if the required goal is accomplished.
Building the workflow
Here, I show how the workflow that manages the drink orders through production was built. I used AWS Step Functions Workflow Studio to build the workflow visually.
Essence of the workflow
The coffee ordering application has a multi-step workflow process for each customer order. This process involves checking the availability of the coffee shop and the barista's queue, waiting for the customer to place their order, waiting for the barista to make the drink, and completing or canceling the order. AWS Step Functions simplify and improve the workflow logic by constructing a state machine that can handle all the steps for a given drink order. Each drink order is a separate execution of the state machine, and Step Functions maintain all the separate executions independently and reliably, without complex custom code. This enables the application to handle multiple orders simultaneously without compromising the user experience or application performance.
Using AWS Step Functions, the coffee ordering application can manage each order's state in a more efficient and streamlined way. The state machine eliminates the need for many nested logic branches, and the central database keeps track of the order state. This approach ensures the reliable and independent management of multiple order executions, improving the application's overall scalability, and performance. Overall, AWS Step Functions provide a simpler and more scalable approach to managing the workflow logic, improving the application's performance, and scalability.
Shop status Workflow
To determine whether the coffee shop is open, this uses an item from a DynamoDB table to determine if the shop is open. A Boolean value in the configuration determines the path of the workflow.
Capacity determining Workflow
After checking for the shop status to know if it is open or closed, I then modified the workflow to check if the queue at the coffee shop can accept another order. To do this, I added a state that checks if the total number of open workflows is higher than a configurable maximum. This checks the amount of capacity available.
Order Number Workflow
I modified the workflow to add an order number to each coffee order. I used a DynamoDB integration in Step Functions to increment an atomic counter and use the value as the order number. The workflow uses this for the current execution.
Waiting for the order
I then edited the workflow to add a waiting period for the customer to make their order. I added a state with a callback. The execution is paused at this state until a callback with a task token is received.
I also edited the workflow to add a waiting period for the baristas to finalize a coffee order. I added a heartbeat set which causes the workflow to timeout if there is no response from the customer or barista.
I added the "Barista timedout" and "customer timedout" pass states and tested the workflow.
I used the SendTaskSuccess API callback to continue the workflow execution with the task token already provided. The workflow proceeded to the next state where this process was repeated and it ran to completion.
Emitting timeouts
Here, I added an EventBridge PutEvents state that emits an event when there is a time-out from either the barista or customer. I also added another state which emits a final event when an order has been completed, and the workflow has been executed fully. Then, the EventBridge PutEvents state that was created earlier was updated to emit an event whenever the capacity for new orders has been exceeded or whenever the shop is closed.
Testing the workflow
After the workflow has been built, tests were run with the store open and closed to see the execution paths through the workflow. The store capacity feature was also tested by starting multiple executions and monitoring at which point the capacity is exceeded. When the store is closed, here's what the execution path looks like:
The execution path followed When the store is open and an order is completed looks like this:
This is from an AWS Workshop. Visit this site to get startedThis is continued in part 3 of the series titled "Building Serverlesspresso". Comments are greatly appreciated. Thank you for making it this far!