Building a Scalable E-commerce Backend with DynamoDB, Lambda, API Gateway, and S3

Introduction. In today’s digital era, platforms like Amazon, Temu, and Jumia handle billions of requests daily. From browsing products to adding items to a cart and uploading product images—every click requires a responsive, fault-tolerant backend architecture. Each user interaction is powered by various AWS services working in sync. In this article, I’ll walk you through how we used DynamoDB, AWS Lambda, API Gateway, and S3 to simulate a lightweight backend for an e-commerce application. This was part of my hands-on class project, where we tested our APIs using Postman. But before jumping into the how-to, let’s understand why and how these services are relevant—and what makes them ideal for real-world use cases. DynamoDB: Why DynamoDB for E-commerce? DynamoDB is a serverless, fully managed, NoSQL database service provided by AWS. Now, “serverless” here doesn’t mean there are no servers—it simply means AWS handles the infrastructure, scaling, and maintenance behind the scenes. Structured, Unstructured, and Semi-Structured Data. Structured Data: Organized into tables, rows, and columns (think Excel or SQL tables). Examples: customer name, email, order ID, product name. Unstructured Data: Doesn’t fit neatly into tables, raw formats. Examples: images, videos, large texts, reviews, documents. Semi-Structured Data: Flexible formats like JSON. Not strictly tabular but still tagged and organized. Has tags or keys but not fixed schemas. DynamoDB is great for semi-structured data because it stores data in key-value and document formats, typically as JSON objects. It thrives in scenarios requiring high-speed access. DynamoDB vs RDS: When to Use Which Features: DynamoDB (NoSQL) RDS(Relational SQL) Schema,Schema-less(flexible JSON) Strict schema (tables, columns) For fast-moving data like product listings, orders, or real-time carts, DynamoDB is ideal. For payment records or transactional histories, RDS is better. Real-world E-commerce Example: Temu, Amazon, Jumia Let’s consider an e-commerce store that sells products online: Product and Customer Data (Structured) Each product has a product_id, name, price, category, and Quantity. Customer records include user_id, email, and order history. Product Images (Unstructured) Stored in S3. The connection to the database is made by storing the image URL in DynamoDB. Each file has a key, typically the product ID. Every S3 object also has an ARN (Amazon Resource Name) for resource identification. DynamoDB links the image via a URL using the partition key (e.g., product_id). Cart System (Semi-Structured / Temporary) Cart contents change frequently. Storing this temporary data in a persistent database would be costly and inefficient. Solution: Use Caching AWS ElastiCache (Redis or Memcached) stores temporary cart data in-memory. This reduces database read/write load and improves performance. The cart data can be stored using session IDs, keyed against user_id. Example DynamoDB JSON Entry: { "product_id": "P123", "name": "Bluetooth Speaker", "price": 4500, "category": "Electronics", "image_url": "https://s3.amazonaws.com/mybucket/P123.jpg" } How Does S3 Know Which Image Belongs to Which Product? When an image is uploaded to S3, it receives a URL and is stored under a key (often named using a product ID). In DynamoDB, we store the image_url as part of the product record. The link between the product and its image is made possible using: Primary Key or Partition Key (e.g., product_id) S3 Object URL Unique Identifier (ARN) for every resource Caching with ElastiCache (For Temporary Structured Data like Cart) In e-commerce, the shopping cart is often a temporary structure. It's not ideal to hit the database for every cart update, especially when the cart can change frequently. Enter ElastiCache ElastiCache is an AWS in-memory data store, ideal for: Shopping cart data User session data Product views Architecture Overview Let’s break down how we built this in our class using Lambda, API Gateway, DynamoDB, and S3: Component Role DynamoDB: Stores products in JSON format S3: Hosts images, connected via product ID or URL Lambda: Executes code for each API request (e.g., add, update, delete items) API Gateway: Provides HTTP endpoints to trigger Lambda. Postman: Tests the API endpoints with sample requests Step-by-Step (Based on Our Classwork) Create a DynamoDB Table Table name: Products Partition Key: product_id Additional attributes: name, price, category, image_url Upload Product Images to S3 Upload images with file names like P123.jpg Make the object publicly accessible (or use pre-signed URLs) Note the S3 URL:https://s3.amazonaws.com/mybucket/P123.jpg for use in DynamoDB

Apr 9, 2025 - 00:12

Building a Scalable E-commerce Backend with DynamoDB, Lambda, API Gateway, and S3

Introduction.

In today’s digital era, platforms like Amazon, Temu, and Jumia handle billions of requests daily. From browsing products to adding items to a cart and uploading product images—every click requires a responsive, fault-tolerant backend architecture. Each user interaction is powered by various AWS services working in sync.

In this article, I’ll walk you through how we used DynamoDB, AWS Lambda, API Gateway, and S3 to simulate a lightweight backend for an e-commerce application. This was part of my hands-on class project, where we tested our APIs using Postman.
But before jumping into the how-to, let’s understand why and how these services are relevant—and what makes them ideal for real-world use cases.

DynamoDB: Why DynamoDB for E-commerce?

DynamoDB is a serverless, fully managed, NoSQL database service provided by AWS. Now, “serverless” here doesn’t mean there are no servers—it simply means AWS handles the infrastructure, scaling, and maintenance behind the scenes.

Structured, Unstructured, and Semi-Structured Data.
Structured Data: Organized into tables, rows, and columns (think Excel or SQL tables). Examples: customer name, email, order ID, product name.

Unstructured Data: Doesn’t fit neatly into tables, raw formats. Examples: images, videos, large texts, reviews, documents.

Semi-Structured Data: Flexible formats like JSON. Not strictly tabular but still tagged and organized. Has tags or keys but not fixed schemas.

DynamoDB is great for semi-structured data because it stores data in key-value and document formats, typically as JSON objects. It thrives in scenarios requiring high-speed access.

DynamoDB vs RDS: When to Use Which
Features: DynamoDB (NoSQL) RDS(Relational SQL)
Schema,Schema-less(flexible JSON) Strict schema (tables, columns)

For fast-moving data like product listings, orders, or real-time carts, DynamoDB is ideal. For payment records or transactional histories, RDS is better.

Real-world E-commerce Example: Temu, Amazon, Jumia
Let’s consider an e-commerce store that sells products online:

Product and Customer Data (Structured)
- Each product has a product_id, name, price, category, and Quantity.
- Customer records include user_id, email, and order history.
Product Images (Unstructured)
Stored in S3. The connection to the database is made by storing the image URL in DynamoDB. Each file has a key, typically the product ID.
- Every S3 object also has an ARN (Amazon Resource Name) for resource identification.
- DynamoDB links the image via a URL using the partition key (e.g., product_id).
Cart System (Semi-Structured / Temporary)
Cart contents change frequently. Storing this temporary data in a persistent database would be costly and inefficient.

Solution: Use Caching
AWS ElastiCache (Redis or Memcached) stores temporary cart data in-memory.
This reduces database read/write load and improves performance.
The cart data can be stored using session IDs, keyed against user_id.

Example DynamoDB JSON Entry:

{
  "product_id": "P123",
  "name": "Bluetooth Speaker",
  "price": 4500,
  "category": "Electronics",
  "image_url": "https://s3.amazonaws.com/mybucket/P123.jpg"
}

How Does S3 Know Which Image Belongs to Which Product?
When an image is uploaded to S3, it receives a URL and is stored under a key (often named using a product ID). In DynamoDB, we store the image_url as part of the product record.
The link between the product and its image is made possible using:

Primary Key or Partition Key (e.g., product_id)
S3 Object URL
Unique Identifier (ARN) for every resource

Caching with ElastiCache (For Temporary Structured Data like Cart)
In e-commerce, the shopping cart is often a temporary structure. It's not ideal to hit the database for every cart update, especially when the cart can change frequently.

Enter ElastiCache
**ElastiCache **is an AWS in-memory data store, ideal for:

Shopping cart data
User session data
Product views

Architecture Overview
Let’s break down how we built this in our class using Lambda, API Gateway, DynamoDB, and S3:

Component Role
DynamoDB: Stores products in JSON format
S3: Hosts images, connected via product ID or URL
Lambda: Executes code for each API request (e.g., add, update, delete items)
API Gateway: Provides HTTP endpoints to trigger Lambda.
Postman: Tests the API endpoints with sample requests

Step-by-Step (Based on Our Classwork)

Create a DynamoDB Table

Table name: Products
Partition Key: product_id
Additional attributes: name, price, category, image_url

Upload Product Images to S3
- Upload images with file names like P123.jpg
- Make the object publicly accessible (or use pre-signed URLs)
- Note the S3 URL:https://s3.amazonaws.com/mybucket/P123.jpg for use in DynamoDB