DEV Community: oscarrobert-star

E-commerce Business Logic: Customer Journeys and The Services Needed

oscarrobert-star — Thu, 04 Sep 2025 08:36:40 +0000

Ever wondered how e-commerce platforms work? In this series, we'll delve into these details and much more. In the previous posts, I introduced the problem statement and shared my initial thoughts on the same. Here, we now want to get our feet wet by diving into the details that make an e-commerce platform work. And in future posts, we'll talk about development and deployment.

On a high level, in an e-commerce platform, the goal is to showcase your products, have customers browse your catalog. Enable them to add items into a cart, and once they are done shopping, check out and complete payments. Here is what the customer journey would look like.

As the business owner, you want to be able to add and track your inventory, manage customer details, monitor orders for dispatch, and track payments.

The Features & Services

From the description above, some of the services we would need are:

1. Product and Inventory Management

We can have one service handle all these. Let's call it Product Service.

This will handle all the features related to adding products, viewing products, updating product descriptions and inventory, and deleting products.
Here are the api endpoints we will need:

POST    /products       # Add a product
GET     /products       # Get all products
GET     /products/:id   # Get products by ID
PATCH   /products/:id   # Editing a product
DELETE  /products/:id   # Deleting a product

The Product Data Model

We had earlier talked about a high-level data model for each product in the database design. And true to our thoughts, we haven't deviated much. At least for the products model. We've only added one new item, category, to help us classify our products.

Product image handling.

When adding products, we need to add images. And since we'll design the UI to serve images of some specification, we need to make sure that the images are resized to the defined specification. Since image resizing is a compute-intensive task, we will decouple this process by having a separate function that gets triggered by image upload. A little infra design, ahead of time, this will be managed by a lambda function which will be triggered by S3 event notification for image uploads. We will expose the S3 bucket from api gateway to enable us upload images of whatever size. Once the image processing is complete, the function will update the product table with the image url.

2. Shopping carts

It only makes sense to talk about shopping carts at this point. This follows the natural flow of a customer's shopping journey.

Cart service.

This service enables us to add items to a virtual cart. The objectives for this service are:

To enable any user to add items into cart, whether authenticated or as a guest
To have a shopping cart that can be accessed from multiple devices for authenticated customers
To have a cart that clears after some time of inactivity. Time to live (ttl) is updated each time there is an activity on the cart e.g. adding an item.

For cart management, I'm opting to write data to Redis. This lets us load the cart quickly and reduces queries to the database. It will also enable us to clear the cart after a set period of time of inactivity. As a buffer, in case of memory pressure, I'm setting the eviction policy on redis to volatile-lru which evicts among keys with TTL, and since all the cart items have ttl, this should help clear the cart items.

This approach of cart management assumes that the inventory churn rate is high and therefore ensures we don't have stale carts. Furthermore, since we know when the cart will be cleared, we can inform the customers via pop up banners on the UI that their carts will expire after a given number of minutes.

The api endpoints are as follows:

POST    /cart/add                 # Add to cart
GET     /cart                     # Get cart data
POST    /cart/remove              # Remove an item from cart
POST    /cart/clear?x-cart-id     # Clear cart
PATCH   /cart/edit                # Edit item quantity in the cart

3. Done shopping? Check out.

Checking out shows us the intention to buy and therefore, we can proceed to create orders. This is the first time we are persisting data. The checkout service does only 2 actions, creating orders and initiating payments. That's it! The service's function is straightforward.

Api endpoint

POST /checkout    # Creating an order and initiate payment process

4. Orders

The Orders service allows us to manage orders. Here we can see the order details including the items ordered, payment status and shipping status.

The orders data model.

We'll have 2 tables for this. One is orders and the other order_items.

The endpoints will be:

POST    /orders                            # Create an order
GET     /orders                            # Get all orders
GET     /orders/:id                        # Get order by ID
PATCH   /orders/:id/payment_status         # Update payment status
PATCH   /orders/:id/shipping_status        # Update shipping status
GET     /orders/status/:payment_reference  # Get order by payment reference

With the above definition, we should be able to handle all requests related to order management.

5. Payments

To complete an order, payment is required. Therefore, we have a Payment Service for the sole purpose of initiating payment. In this case study, we are using PayStack as the payment service provider. Payment service calls Paystack API which returns a link that is redirected to on the UI to have the clients fill in their payment details. All payment transactions are handled in PayStack, and a callback is sent to us via public webhook for verification and order completion.

We have the following endpoints that perform the described payments functionality:

POST    /payments/pay        # Initiates payment
POST    /payments/webhook    # Receives the payment callback

6. Users and Customers

Obviously, we can't allow unauthenticated users to perform actions in our system. Therefore, we have a Users service that handles the business logic of creating customers and staff users.
For authentication and authorization, we'll leverage AWS Cognito. We will manage both customers and users using a single Cognito user pool and add groups (Customers and admins). This approach centralizes identity management while maintaining a clear separation for authorization rules.

On logging in, Cognito provides us with JWT (JSON Web Token). Our backend endpoints are secured by verifying this JWT. This allows us to lock down endpoints not by just authenticating users but to specific user groups based on the claims inside the tokens.

Customer and user models

Endpoints to our backend include:

POST    /users/signup            # Sign up
POST    /users/confirm-signup    # Confirm email address
POST    /users/login             # Log in
GET     /users/profile           # Get user profile

7. Notifications

Communication is key. At different points in this customer journey we'll have to communicate with our customer not only to get them informed on different events like order completion or order dispatch but also for customer satisfaction and feedback. There are tools to measure customer satisfaction like net promoter score (NPS) but we won't get into that here.
We'll create a notification service to manage communication templates and send out notifications via text messages or emails.
Remember, to send promotional messages, we must have an opt in option for compliance purposes.

To handle communication via different channels like phone numbers and email, we can employ services such as AWS SES and AWS SNS. The details for these yet to come in the cloud infrastructure section.

This way none of the services sending notifications care about how they are sent, rather they focus on what is being sent out.

Api Endpoint

POST    /notifications/order/confirmation
POST    /notifications/order/dispatched
POST    /notifications/order/payment-reminder
POST    /notifications/promotions

8. Client pages.

These include customer page (the e-commerce shop itself) and the admin page (the back office). These pages piece everything together in nice UI/UX designs to make it appealing for user interactions. Since this is not a UI/UX series, we will not be getting into those details.

Conclusion

This is getting rather long. Let's stop it here and pick it up on the next post, Developing an E-commerce website.

My thoughts on the business case by AI (ChatGPT)

oscarrobert-star — Wed, 27 Aug 2025 13:27:31 +0000

So I've decided to take on the challenge to build an e-commerce platform as a solutions architect for a new startup. The client? AI (ChatGPT). I have a business case that was generated for me by AI, and from it, I'd like to go through the intricacies and nuances of building a fully scalable platform.

Before we get into the solutions, here are my thoughts on the problem AI provided. Here is the business case to refresh your memory.

1. The scope

The scope of this particular problem is quite wide and would need an entire tech department to build and maintain. Companies pay thousands of dollars to have such a system developed. This problem spans multiple areas like solution designing, UI/UX, Development (Both frontend and backend code), Deployment, Monitoring, and then the cycle starts over. Visually, this is what that cycle ideally looks like.

2. Business case validation

From a product perspective, a business case of this scope would require its product team to conduct a lot of market research to prove that this is a viable business and the demand is as described. Only then can it warrant a solution that scales to serve clients between 5,000 and 50,000 in a day. It would be a good idea to start small and scale as demand grows. That way, you get to validate and iterate your value proposition with real customers.

3. ChatGPT has somewhat simplified this case.

What's fascinating here is that the AI has already done a lot of the heavy lifting. In a real-world scenario, a solutions architect would be the one translating the CEO's high-level vision and the business team's needs into these specific, quantifiable requirements. This ChatGPT-generated case essentially hands us the technical blueprint, skipping a crucial and often challenging part of the process.

4. Tackling the Mountain: Where We'll Start.

As much as AI has done some work for us, we still have a mountain to tackle. We know that we need to have 2 client pages, one for admins and the other for clients. We need to design the workflows for browsing the product catalog, cart management, placing orders, making payments, and sending notifications, to mention a few areas. We also need to bring all these together, and make sure that there is seamless Interservice communication. We need to design the authentication mechanism, the data layer and so much more. We will get into all these in detail in the coming sections of the series.

5. Technical interview point of view

If you were asked to design a solution for this in an interview, how would you approach it?

The first thing that comes to mind is the 2 client pages. We can serve these from a Content Delivery Network (CDN) such such AWS CloudFront or GCP's Cloud CDN. This ensures that the pages can load quickly globally since we'll have static content cached.

For the dynamic content, the clients call the backend via a load balancer that distributes the traffic to different backend applications. We can have the backend apps autoscale based on some metric of choice such as CPU or memory utilization, or even based on request count.

The backend reads data from the database. Between the applications and the database, we have caching enabled for frequently accessed data e.g product data. We can use least recently used(LRU) cache invalidation strategies to ensure we always have the latest version of the product data displayed to the customers. The other option we have is using least frequently used cache invalidation. However, this can be computationally expensive since we would have to keep track of the counts for each item accessed in the cache.

Once an order has been placed, initiate payment processing to Stripe (or whatever payment platform you prefer). We then receive callbacks via webhooks from the payment provider and send notifications to the customer on successful order placement or when the order has been dispatched.

Here is a pictorial depiction of the above:

The database design.
to store data, we would need the following tables: customer, product, order, order_items, users. Here is what the data schemas would look like.

We will use an SQL database to store the data because we can benefit from relationships to ensure data integrity.

We'll be designing the business logic, customer journeys, and the services needed to make it all possible. Stay tuned!

Business Case: E-Commerce Platform for a Niche Market

oscarrobert-star — Tue, 26 Aug 2025 07:19:53 +0000

Business Summary:

You're building an e-commerce platform for a small-to-medium enterprise (SME) selling handmade, eco-friendly products. The company expects seasonal traffic spikes (especially during sales like Earth Day, Black Friday), and they need the site to be highly available, scalable, and secure.
They also plan to expand globally within the next year.
The MVP (minimum viable product) must be ready to handle 5,000 daily users with the capability to scale to 50,000 during sales events.
The CEO loves "serverless" buzzwords, but they’re open to containers if needed.

1. Core Functional Requirements

Customers must browse products, add to cart, checkout, and receive email confirmations.
Admins need an internal dashboard to manage inventory, orders, and customer data.
Orders should trigger payment processing (assume you’re using Stripe).
Inventory must update in real time to avoid overselling.
Support for user accounts, including password reset and MFA.
All product images and static assets must load quickly worldwide.

2. Non-Functional Requirements

Scalability: Must handle spikes in traffic without downtime.
Availability: 99.9% uptime (no single points of failure).
Security:
- PCI-DSS compliance for payment data (Stripe handles most of it, but your app must be secure).
- Customer data must be encrypted at rest and in transit.
- Protection from common web attacks (SQL injection, XSS, DDoS).
Performance: Page load time under 3 seconds globally.
Observability: Full monitoring, logging, and alerting for failures.
Cost Optimization: Minimal operational overhead; pay-for-use preferred.

3. User Requirements

Customer Portal: Browse catalog, search products, checkout process.
Admin Portal: CRUD for products, view orders, manage customers.
Authentication: Cognito (or something equivalent), with social login (Google, Facebook).

4. Data Requirements

Product catalog (name, price, description, image, stock).
Customer data (PII, shipping info, order history).
Orders (customer, items, payment status, shipping status). Audit logs (who did what, and when).

5. Operational Requirements

CI/CD pipeline: Push to main → automatic build, test, deploy. Blue/Green or Canary deployments for releases.
Disaster recovery: Backup and restore within 4 hours (RTO). Data loss no more than 15 minutes (RPO).
Cost reporting: Regular cost monitoring and alerts for unusual spikes.

6. Compliance & Legal

GDPR compliance (data deletion on request, explicit consent for data processing).
PCI-DSS (payment handling done through Stripe, but secure the backend and database).
Data residency: Store customer data in EU and US regions based on customer location.

🎯 Optional Stretch Goals (if you're feeling spicy)

Integrate with AWS Personalize to offer product recommendations.
Add real-time order tracking via WebSockets or AppSync subscriptions.
Build a mobile app backend alongside the web version.
Implement Infrastructure as Code (IaC) in Terraform or CDK.
Implement serverless-first architecture (if you can justify it).

On to the solutioning

How exciting is this, right?😅
Let's not keep you waiting, let's get cracking. My thoughts on this business problem

Reverse learning with AI: Breaking down AI-generated business cases into technical solutions

oscarrobert-star — Wed, 20 Aug 2025 12:31:42 +0000

In the wake of AI and vibe coding, most of us, developers, gravitate towards prompting AI agents to find solutions, or debug, or build something.
So I figured, why not let AI give me a problem, and then I work backwards to get the solution?

I'm going to take you on my journey to build a system, from a problem statement generated by AI (ChatGPT).

But first,

Who am I?

Hi, my name is Oscar Okiya. I'm passionate about solving problems, especially tech-related. I serve as a DevOps/Cloud Engineer. You can find me on LinkedIn, I'd be happy to connect.

Why am I doing this?

Other than learning (of course), I'm working on improving my solutions architecture and technical writing skills.

That said,...

What's next?

A few months ago, I wanted to start doing projects to refresh my knowledge, test out new cloud offerings, and put out new content. It turned out that at the same time, I was engaging ChatGPT quite a lot. Then it dawned on me that instead of prompting AI to give me answers to random questions, why don't I ask it for a business problem and try to see if I transform it into technical requirements, break it down into bite-size and develop it. Guess what, it did. And that will be the start of this journey.

The first problem statement

For our first case, let's look at building an e-commerce platform for a new startup that is selling handmade, eco-friendly products. The company serves 5k clients on a daily, and scales to 50k clients seasonally on events like black Friday.

I bet you are wondering, is this all AI gave you? Of course not. I'm showing you the details of the requirements next. But before then,

Pause

If you're as excited as I am about this, give me a thumbs up! I'd like to know who I'm taking with me in this journey. A final note, this is going to be a series, so at the end of each post, you will find links to the next phase.

Let's Go!

Here is the detailed business case. 1. An E-Commerce Platform for a Niche Market.

3 tier architecture with CICD

oscarrobert-star — Mon, 16 Oct 2023 09:04:56 +0000

ABC Platform Documentation

Overview

The ABC platform is structured into three distinct tiers: Frontend, Backend, and Database. This documentation provides an overview of the architecture, technologies used, and deployment strategies within each tier.

Frontend Tier

Hosting

The Frontend of the ABC platform is hosted in AWS S3, and its content is distributed via AWS CloudFront, a content delivery network. AWS Certificate Manager is used to request SSL/TLS certificates for the CloudFront domain.

DNS Management

The CloudFront DNS is managed through AWS Route 53, where all Domain Name System (DNS) configurations are handled.

Backend Tier

Hosting

Backend services are hosted in AWS ECS Fargate, a serverless service designed for orchestrating Docker containers. To facilitate this, we create an ECS cluster, where services are deployed. Each service is defined by a task definition, specifying details like the Docker image to run. Deploying task definitions results in the creation of tasks, which are the containers responsible for running each service.

Docker Images

Docker images are built and stored in AWS Elastic Container Registry (ECR), from which they are pulled into AWS ECS services for execution.

Database Tier

Main Database

The primary database for the ABC platform is MySQL. The data will be migrated from its original source into AWS RDS Aurora for MySQL. This transition is made to optimize cost-efficiency and enhance overall database performance, as Aurora for MySQL is considered more efficient than RDS for MySQL.

Chat App Database

For the chat app component of the platform, the current MongoDB database will be migrated to use Amazon DynamoDB, a NoSQL database service compatible with MongoDB. This migration aims to improve the efficiency and scalability of the chat app's data management.

Monitoring

Log Management

All logs generated by the ABC platform are sent to AWS CloudWatch. This centralizes log management and facilitates the creation of metrics and alarms to promptly notify administrators of potential issues within the platform.

Notifications

AWS Simple Notification Service (SNS) is utilized for all notification purposes, ensuring that administrators are promptly informed of any critical events.

CI/CD (Continuous Integration/Continuous Deployment)

Source Code Management

The source code of the ABC platform is stored in Bitbucket, a Git-based source code management platform.

CI/CD Pipelines

Bitbucket is configured to run CI/CD pipelines responsible for building and deploying artifacts to AWS S3 for the frontend and Docker images to AWS ECR for storage.

Backend Deployment

To deploy the backend services, AWS CodeDeploy is used in conjunction with Bitbucket. This combination facilitates seamless updates to the AWS ECS tasks, ensuring a smooth deployment process.

SonarQube Integration

The ABC platform utilizes SonarQube, a powerful code analysis tool, within the CI/CD pipeline. SonarQube is used to perform continuous code quality checks and identify issues, vulnerabilities, and code smells in the source code. These checks help maintain code quality and security throughout the development and deployment process.

AWS Accounts

Multi-Account Strategy

ABC employs a multi-account strategy to host various environments, including development, staging, and production. AWS Organizations is used for centralized management of these accounts, while AWS IAM Identity Center is leveraged to manage permissions for users across the accounts.

This documentation provides an insight into the architecture, technologies, and strategies used within the ABC platform. For more detailed instructions and configurations, please refer to specific documents related to each tier or service.

How to automate using MFA in AWS CLI

oscarrobert-star — Wed, 03 May 2023 10:05:19 +0000

Problem Statement

I am a frequent AWS CLI user, and this has never been a challenge until my organisation decided to enforce AWS MFA for all users - a recommended practice. This significantly affected how I use the AWS CLI.

How to enable MFA: AWS Documentation on Enabling a Virtual MFA Device
How to use MFA with the CLI: AWS Knowledge Center Guide

Look at the hustle you have to go through when using the CLI. To add to that, imagine if you had 4 AWS environments. Will you be copying these temporary credentials into the .aws/credentials file all the time, or updating the environment variables each time?

Solution

In the DevOps spirit, I had to find a way to automate this. My solution has two parts:

A Python script that handles the authentication and updates .aws/credentials with the new session keys and token.
Creating shell aliases to run the Python script seamlessly.

Part 1: The Python Script

The script uses argparse to define required command-line arguments: your MFA device ARN, the MFA token from your virtual device, and the AWS CLI profile you wish to authenticate.

import argparse
import boto3
import re
import os
import fileinput

description = "Authenticate and update AWS credentials with MFA tokens"
parser = argparse.ArgumentParser(description=description)
parser.add_argument('--mfa_serial_number', type=str, dest='mfa_serial_number', help='Enter your mfa device arn')
parser.add_argument('--profile_name', dest='profile_name', type=str, help='use default if you dont have any unique profiles')
parser.add_argument('--mfa_token_code', dest='mfa_token_code', type=str, help='MFA code from your virtual device')

# Parse the command-line arguments
args = parser.parse_args()

# Assign arguments to variables
mfa_serial_number = args.mfa_serial_number
profile_name = args.profile_name
mfa_token_code = args.mfa_token_code

# Check that all inputs are present
if not all([mfa_serial_number, mfa_token_code, profile_name]):
    parser.error('Required: --mfa_token_code, --mfa_serial_number and --profile_name are required.')

The script then uses the boto3 STS client to authenticate and retrieve temporary session credentials. The session duration is configurable.

##################### Authenticate MFA ##########################
session = boto3.Session(profile_name=profile_name) # enter profile 
sts_client = session.client('sts')
response = sts_client.get_session_token(
    DurationSeconds=3600, # Value changes between 900 (15 mins) - 129600 (36 hours)
    SerialNumber=mfa_serial_number,
    TokenCode=mfa_token_code
)
access_key = response['Credentials']['AccessKeyId']
secret_key = response['Credentials']['SecretAccessKey']
session_token = response['Credentials']['SessionToken']

Finally, the script updates the .aws/credentials file in-place. It searches for a specific profile block (e.g., [mfa]) and replaces the subsequent three lines with the new credentials.

Prerequisite: You must pre-create the profile block in ~/.aws/credentials:

[mfa]
wertyio
asdfgh
zxcvbn

#################### Update .aws/credential file with the temporary mfa credentials #####################

# Define the pattern to search for
pattern = re.compile(r'\[mfa\]')

# Define the replacement content for the three lines
replacement_lines = [f'aws_access_key_id = {access_key}\n', f'aws_secret_access_key = {secret_key}\n', f'aws_session_token = {session_token}\n']

home = os.path.expanduser("~")
# Open the file in inplace mode using fileinput
with fileinput.input(f'{home}/.aws/credentials', inplace=True) as file:
    # Iterate over the lines in the file
    for line in file:
        # If the line matches the pattern, print it and then modify the next three lines
        if pattern.match(line):
            print(line, end='')
            # Print the new replacement lines
            for replacement_line in replacement_lines:
                print(replacement_line, end='')
            # Skip the next three lines in the original file
            next(file)
            next(file)
            next(file)
        # Otherwise, just print the line
        else:
            print(line, end='')

Part 2: Creating Aliases

Aliases are shortcuts in your shell to execute longer commands. This is a personal preference; feel free to modify them.

First, create an alias to source your Python virtual environment (if you use one).

# Add to ~/.zshrc or ~/.bashrc
alias source_env='source /Users/devops/Desktop/python_lab/env/bin/activate'

Next, create aliases for each of your AWS environments. The number of aliases depends on the number of environments you have (e.g., test, staging, prod).

# Add to ~/.zshrc or ~/.bashrc
alias mfaTest='source_env && python /Users/devops/Desktop/python_lab/enableMFA/newCred.py --mfa_serial_number $TEST_DEVICE --profile_name test --mfa_token_code '
alias mfaStaging='source_env && python /Users/devops/Desktop/python_lab/enableMFA/newCred.py --mfa_serial_number $STAGING_DEVICE --profile_name staging --mfa_token_code '
alias mfaProd='source_env && python /Users/devops/Desktop/python_lab/enableMFA/newCred.py --mfa_serial_number $PROD_DEVICE --profile_name prod --mfa_token_code '

Important: The mfa_serial_number argument is passed from an environment variable. You must define these variables in your shell configuration file:

# Add to ~/.zshrc or ~/.bashrc
export TEST_DEVICE='arn:aws:iam::123456789012:mfa/my-device'
export STAGING_DEVICE='arn:aws:iam::210987654321:mfa/my-device'
export PROD_DEVICE='arn:aws:iam::098765432109:mfa/my-device'

Usage: To authenticate, call the alias followed by the current MFA code from your authenticator app.

mfaTest 123456

After running, you can verify your credentials by calling any AWS CLI command using the --profile mfa flag.

Alternative Approach

If you are an admin and have IAM permissions across your AWS accounts, you can create an IAM role with cross-account permissions. This allows you to assume a role directly for the account you need, which can often be a more scalable and secure solution than managing long-term credentials and MFA tokens for the CLI.