Coffee Ordering at Event Venues (Serverlesspresso)

A serverless architecture that supports coffee ordering at event venue booths, from attendee orders to barista fulfillment. It combines API Gateway, Lambda, DynamoDB and EventBridge to provide QR code order validation, Step Functions order workflows, a barista app with store configuration, and realtime notifications through IoT Core. It also records per-order event history and generates journey HTML stored in S3 and served via CloudFront. Source: https://github.com/aws-samples/serverless-coffee/tree/9d494a250600a0bb7012762620a68d78061149a1 (Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.; License: MIT No Attribution (MIT-0)). The original files are reproduced without modification.

Actors

Attendees (customers)
Baristas
Store administrators
Display app
AWS IoT Core (realtime messaging)

Use cases

Display ordering QR code
Start order by scanning QR code
Submit drink order and check status
Barista order handling
Change and broadcast store config
Record order journey and generate HTML
View order journey

This architecture diagram shows the core stack of Serverlesspresso, a serverless system for coffee booths at events that covers everything from an attendee placing an order to the barista handing over the drink. It combines API Gateway, Lambda, DynamoDB and EventBridge to provide QR code order validation, Step Functions order workflows, a barista app with store configuration, and real-time notifications through IoT Core. The source is 01-appCore/template.yaml in aws-samples/serverless-coffee (license: MIT-0).

Main resources and data flow

The entry points are three REST APIs: the Validator API, the Order Manager API and the Config API. The Validator API uses Lambda to fetch and verify QR codes, and stores time-bucketed validation codes in the validator table. On successful validation, a Validator.NewOrder event is sent to the Serverlesspresso EventBridge bus and the order processor workflow (Step Functions) starts. This workflow checks store open state and capacity in the config table, and assigns an order number in the counting table. The Order Manager API starts the order manager workflow. That workflow calls the sanitize order function, stores the order in the order table, and resumes the waiting order processor workflow via SendTaskSuccess. The Config API reads and writes the config table through API Gateway direct integration. Config changes flow through DynamoDB Streams to the config-changed function, then via EventBridge to the config publisher, and on to IoT Core. In addition, the order journey workflow records every Serverlesspresso event, generates per-order journey HTML, stores it in S3, and serves it through CloudFront.

How each use case flows

The diagram describes these use cases: (1) Display ordering QR code: the display app fetches the time-bucketed code with GET /qr-code. (2) Start order by scanning QR code: the attendee's POST /qr-code is verified and the order processor workflow starts. (3) Submit drink order and check status: the order is submitted, and status is returned via GetItem/Query on the order table. (4) Barista order handling: pending and in-progress orders are listed via the order-state GSI, and make/complete/cancel actions go through the order manager workflow. (5) Change and broadcast store config. (6) Sync workflow state to order table (WorkflowStarted / WaitingCompletion). (7) Order timeout handling (OrderTimeOut). (8) Real-time order status notification: publisher functions post to the serverlesspresso-admin and serverlesspresso-user-<ID> topics. (9) Record order journey and generate HTML. (10) View order journey: on a cache miss, CloudFront fetches from the S3 origin via OAI (TTL 5 seconds). (11) Initialize tables on deployment: a custom resource seeds the config and counting tables.

Source IaC (file and main resource types)

The source is the CloudFormation template 01-appCore/template.yaml, written with AWS SAM (Transform: AWS::Serverless-2016-10-31), from aws-samples/serverless-coffee at commit 9d494a250600a0bb7012762620a68d78061149a1, licensed MIT-0. The main resource types are AWS::Serverless::Function (get/verify QR code, publishers, config changed, order state handlers, generate HTML and more), AWS::Serverless::StateMachine (order processor, order manager, order journey), AWS::Serverless::Api (three REST APIs), AWS::DynamoDB::Table (order, config, counting, validator, journey events), AWS::S3::Bucket, AWS::CloudFront::Distribution and CloudFrontOriginAccessIdentity, AWS::Events::Rule, AWS::IAM::Role / Policy, AWS::Logs::LogGroup and AWS::CloudFormation::CustomResource. The EventBridge bus, the IoT Core endpoint and the Cognito user pool are not created in this template; it references them through parameters.

How this architecture diagram was made

An AI read the IaC in the public repository (the template.yaml above) and wrote the diagram description (ADL) through IceShore's MCP (Model Context Protocol) server. IceShore then rendered the diagram. IoT Core, which is provisioned outside the template, is shown as an external system. Figures such as the number of attendees are placeholder assumptions set by the AI and do not come from the source IaC.

FAQ

Can an architecture diagram be generated automatically from a CloudFormation / SAM template?

This diagram was made by having an AI read a SAM-based CloudFormation template. The AI wrote the diagram description through IceShore's MCP server, and IceShore rendered it. Besides the resources, the description also records which resources each use case passes through.

Why are the EventBridge bus, IoT Core and Cognito not shown as resources in this stack?

The source template does not create them. It references them through parameters such as ServerlesspressoEventBus, IoTRealtimeParameter and UserPoolARNParameter. In the diagram, IoT Core is drawn as an external system, and the EventBridge bus appears as the path events travel along.

Are the numbers in the diagram, such as attendee counts, measured values?

No. Values like 10,000 attendees are placeholder assumptions set by the AI and are not part of the source IaC.

Source: aws-samples/serverless-coffee（MIT-0）

Load your IaC to get a diagram like this for your own system. What is IceShore