In this session of AWS Cloud Path, we try our hands at building a serverless backend for a coffee shop ordering system using AWS Step Functions, Lambda, DynamoDB, and EventBridge. The system handles order processing, barista notifications, and order status updates in a completely serverless architecture. Check out the workshop here: Serverlesspresso Workshop
Missed the session? Catch up here:
Prerequisites
- AWS Account with appropriate permissions
- Basic understanding of serverless architecture
- Familiarity with AWS services
The Coffee Shop System Overview
The application consists of three front-end components:
- Overhead monitor display
- Barista application
- Customer ordering application
The backend system needs to handle requests from all these front-ends while managing different data payloads for each interface.
Key Features
- QR code-based ordering system with limits (10 drinks/5 minutes)
- Barista queue management (maximum 20 drinks at a time)
- Real-time order status updates
- Shop status management (open/closed)
Building the Workflow with AWS Step Functions
1. Initial Setup
The workflow begins by checking two crucial conditions:
- If the shop is open
- If the barista queue has capacity
We implement this using AWS Step Functions state machine with the following components:
{
"Comment": "Coffee Shop Order Processing Workflow",
"StartAt": "CheckShopStatus",
"States": {
"CheckShopStatus": {
"Type": "Task",
"Resource": "arn:aws:states:::dynamodb:getItem",
"Parameters": {
"TableName": "serverless-coffee-config",
"Key": {
"pk": {"S": "config"},
"sk": {"S": "shop"}
}
},
"Next": "IsShopOpen"
}
// Additional states follow
}
}
2. Shop Status Verification
The workflow first queries DynamoDB to check if the shop is open. This is implemented as a choice state that branches based on the shop's status:
- If shop is closed: Emit event via EventBridge
- If shop is open: Proceed to capacity check
3. Capacity Management
The system checks if the barista queue has capacity by listing current Step Functions executions:
- Maximum limit: 20 drinks in queue
- Uses Step Functions List Executions API
- Implements capacity verification before accepting new orders
4. Order Number Generation
When an order is accepted, we generate a unique order number using DynamoDB:
{
"TableName": "counting-table",
"Key": {
"id": {"S": "orderId"}
},
"UpdateExpression": "SET id_value = id_value + :inc",
"ExpressionAttributeValues": {
":inc": {"N": "1"}
},
"ReturnValues": "ALL_NEW"
}
5. Event-Driven Communication
The workflow uses EventBridge for event-driven communication:
- Order started events
- Shop status updates
- Order completion notifications
- Error handling events
6. Timeout Management
The system implements two crucial timeout scenarios:
- Customer timeout: 900 seconds (15 minutes) for order placement
- Barista timeout: 900 seconds for order preparation
Each timeout is handled with appropriate error states and event emissions.
Error Handling
The workflow implements comprehensive error handling:
- Customer timeouts
- Barista timeouts
- Shop closure scenarios
- Queue capacity issues
Each error case emits specific events that can be handled by other components of the system.
Testing the Workflow
To test callbacks in the workflow:
# For successful completion
aws stepfunctions send-task-success --task-token <TASK_TOKEN> --task-output "{}"
# For failure scenarios
aws stepfunctions send-task-failure --task-token <TASK_TOKEN> --error "Error.Type" --cause "Error description"
Next Steps
In the next session, we'll focus on:
- Connecting front-end applications
- Testing the complete system
The completed backend will provide a robust foundation for the coffee shop ordering system, handling everything from order placement to completion in a serverless architecture.
Remember to check your AWS free tier status before deploying, as the total cost for these services should be under $1 with free tier benefits.
Happy coding! ☕️
Top comments (0)