Series: AWS Serverless Projects

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 means the cloud provider (AWS in our case) manages the servers, scalability, and infrastructure. You focus solely on writing business logic.

Understanding the Data: Structured vs Unstructured and Semi-Structured Data.
Before building, let’s talk data. E-commerce platforms like Temu, Amazon, and Jumia deal with both structured and unstructured data:

Structured Data
Data that fits neatly into Organized tables, rows, and columns (think Excel or SQL tables):

• Examples: Users, orders, transactions.
• Where it lives: Can go into RDS (Relational Database Service) like MySQL or PostgreSQL

Unstructured / Semi-structured Data
Data that doesn’t follow a strict schema, i.e, doesn’t fit neatly into tables, raw formats.

• Examples: Product attributes (color, size, promo details), user reviews, images, videos, large texts, JSON documents.
• Where it fits: Perfect for DynamoDB—a NoSQL, key-value/document-based database

Example:
In an e-commerce app:

• Use DynamoDB to store product catalog and customer carts in flexible JSON format.
• Use RDS for structured transaction logs and payment history. 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.

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

1. 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.
2. 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).
3. Product Listings – Semi-structured Stored in DynamoDB:

{
  "productID": "12345",
  "name": "Laptop",
  "attributes": {
    "RAM": "8GB",
    "Storage": "512GB SSD",
    "Color": "Silver"
  },
  "price": 800
}

1. 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. If a user doesn’t check out, data can be purged automatically after expiry.

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: Why and How?
E-commerce platforms experience spikes in traffic. Caching helps improve speed and reduce load.

• ElastiCache (Redis): Fast, in-memory caching engine for temporary data like sessions, carts, or search queries.
• Benefits: Reduces repeated database calls, ensures low latency.

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)

1. Create a DynamoDB Table

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

1. 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

2. Create Lambda Functions
   Each function is written in Python (or Node.js) to perform:

• POST: Insert product into DynamoDB
• GET: Retrieve by product ID
• PUT: Update product data
• DELETE: Remove product record Each function uses Boto3 (Python SDK) to interact with DynamoDB. When configuring Lambda, go to permissions on the IAM role, attach DynamoDB full access, add your Python code to the Lambda function, and deploy.

1. Set Up API Gateway

• Create REST API
• Define routes: /product, /product/{id}
• Create and Link methods (put, post, get, delete) to respective Lambda functions

1. Test with Postman Use Postman to send requests and observe live responses.

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

Test the GET, PUT, and DELETE endpoints to complete the flow.

Why This Architecture Works in the Real World

• Scalability: All services are fully managed and scale automatically.
• Flexibility: DynamoDB's JSON support is perfect for evolving product data.
• Low Latency: Lambda + API Gateway = near-instant execution.
• Separation of Concerns: Images are stored in S3, metadata in DynamoDB.
• Secure Resource Management: Each AWS resource has an ARN and is defined with access via IAM.
• Cost-Effective: Pay only for what you use
• Highly Available: S3 and DynamoDB are designed for 99.99% uptime
• Serverless: No infrastructure management. Multi-region setups: Use Global Tables in DynamoDB and S3 Cross-Region Replication for high availability.

Conclusion
In today’s cloud-driven world, building a robust, serverless, and scalable backend for an e-commerce platform is not only possible but also very practical. This hands-on setup is a mini version of what happens behind the scenes when building e-commerce systems, You don’t just need a database—you need a responsive, modular architecture. DynamoDB, Lambda, S3, and API Gateway form a powerful foundation for a modern, serverless backend. Paired with in-memory services like ElastiCache, this stack supports everything from dynamic product catalogs to blazing-fast cart systems.
Developers can build robust, responsive, and scalable e-commerce applications without managing servers.

Try It Yourself
Want to try this architecture?

• Launch a free-tier AWS account.
• Create your API Gateway and Lambda function.
• Connect to DynamoDB.
• Upload a product image to S3 and link its URL in your product item.

I’m documenting my learning journey, AWS, and Cloud Architecture. If you found this useful, consider following me here on Dev.to
I’ll be sharing more hands-on AWS articles, projects, and architecture breakdowns.
Let’s build in the cloud together!