High-Level Overview of my Commerce Demo

The goal of this demo is to show a realistic but compact e-commerce flow on AWS:

  • Users sign in with Google SSO via the Amazon Cognito Hosted UI.
  • The frontend exchanges the OAuth code for a Cognito access token.
  • That access token is sent as a Bearer token to an API Gateway HTTP API.
  • API Gateway uses a Cognito JSON Web Token authorizer to validate the token.
  • Requests are routed to small, focused Lambda functions.
  • Each Lambda reads and writes data in DynamoDB tables for products, carts, and orders.

This project shows a complete path: federated auth → JWT → API → Lambda → data store.

Quick demo video

I will be recording a short 3–4 minute walkthrough explaining the user flow and the key design choices:
 Watch the demo on YouTube (coming soon)

Authentication & Identity

This project uses federated authentication rather than a local username/password database. User identity is handled by Amazon Cognito, with Google configured as an external identity provider.

  • Users authenticate via the Cognito Hosted UI using their Google account.
  • After sign-in, the frontend receives a Cognito access token (JWT).
  • That access token is sent as a Bearer token with every API request.
  • API Gateway validates the JWT using a Cognito authorizer before any request reaches Lambda.

Authentication is enforced at the API boundary: if a valid access token is missing or expired, API calls are rejected and the frontend limits functionality to sign-in only.

API Gateway & Lambda

The backend is exposed through an API Gateway HTTP API (v2) protected by a Cognito JWT authorizer. Authentication is enforced at the gateway, so Lambda functions do not implement their own auth logic.

Routes are intentionally split by responsibility, with each Lambda focused on a single concern:

  • GET /products
    → commerce_products
    Returns the product catalog.

  • Cart endpoints (per user)
    → commerce_cart
    • GET /cart
    • POST /cart
    • DELETE /cart/{product_id}
  • Order endpoints
    → commerce_orders
    • POST /orders
    • GET /orders
    • GET /orders/{order_id}

Each Lambda trusts API Gateway for authentication, extracts the authenticated user ID from JWT claims, and performs scoped reads and writes against DynamoDB. Responses are returned as clean JSON for direct frontend rendering.

DynamoDB Data Model

The backend uses separate DynamoDB tables for distinct concerns: product catalog data, per-user carts, and completed orders. This keeps access patterns simple and avoids overloading a single table with unrelated responsibilities.

Products table (commerce-products)

  • Partition key: product_id
  • Stores static catalog data such as name, category, and price.

Carts table (commerce-carts)

  • Partition key: user_id
  • One cart per authenticated user.
  • Items are stored as an array of product_id and quantity.

Orders table (commerce-orders)

  • Partition key: order_id
  • Attributes include user_id, timestamp, status, and ordered items.

When an order is placed, the backend creates a new order record from the user’s cart and clears the cart. Order history queries are scoped by user and return recent orders for display in the frontend.

Frontend Responsibilities

The frontend is a static HTML and JavaScript application hosted on the same S3 + CloudFront stack as the rest of my portfolio. It is responsible for presentation, user interaction, and API orchestration - not business logic.

  • Handles user sign-in by redirecting to the Cognito Hosted UI and storing the returned access token in memory.
  • Includes the access token as a Bearer token on all API requests.
  • Renders products, cart state, and order history based entirely on API responses.
  • Adjusts visible UI state based on authentication status and API results.

All validation, authorization, and data persistence are handled by backend services. The frontend acts as a thin client that reflects backend state rather than enforcing business rules.

Infrastructure as Code & Operations

The entire stack is defined in a dedicated Terraform Cloud workspace called terraform-commerce.

  • All Cognito, API Gateway, and Lambda resources are created via Terraform.
  • DynamoDB tables for products, carts, and orders are also managed by IaC.
  • Changes are made through Git commits and Terraform Cloud runs, not by clicking around in the console.

Bottom Line

This project demonstrates a realistic, maintainable e-commerce backend on AWS using managed services for identity, APIs, and data storage. It intentionally focuses on clear trust boundaries.

The commerce domain provides a familiar use case that makes architectural decisions easy to evaluate: federated identity with Cognito, JWT-protected APIs, and DynamoDB tables aligned to access patterns. Together, these pieces form a clean end-to-end example of AWS application architecture that complements my IoT and ML projects without overlapping their problem spaces.