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.
Top comments (0)