System requirements

Functional:

1. Merchant Management- The system should be able to register and maintain merchants information.
2. Store Management for Merchants - The System should allow for merchants to create online stores and maintain information about those stores.
3. Product Management - The System should be able to keep the types of Products listed on the specific merchant stores and the associated Inventory for that product.
4. Inventory Tracking - The system should be able to provide a way of tracking the inventory associated with the product that is being sold.
5. Order Processing - The System should be able to accept an order from a customer and process that order.
6. Payment Gateway - The System should be able to provide a payment gateway to process payments from the registered customer for the merchant.

The basic requirement is for the system to be able to provide a website and all associated services like product management, inventory management, order processing and tracking and payment integration for every merchant that registers with the system.

Non-Functional:

1. High Availability - Since there will be many merchants and their stores hosted on the platform, it should be highly available platform.
2. Scalability - The system should have the capability to handle growing number of merchants and associated stores.
3. Accurate Inventory Tracking - The system should be able to give an accurate representation of the inventory associated with the products that are being sold by the merchants on the stores.
4. The Merchant data should be isolated.

Capacity estimation

1. Total number of merchant stores = 500000.
2. Total number of active users across all merchants = 10000000.
3. Total number of products for each store , roughly 200, so total number of products = 500000*200 = 100,000,000 100M products.
4. Total orders per day = 1 million and number of orders at peak hours during sale season maybe 5M orders per day.

API design

Merchant Store Management Service

1. API for merchant to create stores.

POST/api/v2/createStore

PATCH/api/v2/updateStore?id=x;

Product Management Service.

1. API For merchants to add and list product, update products etc.

POST/api/v2/store/createProduct

PATCH/api/v2/store/updateProduct?productid=x;

API to view Products- GET/api/v2/product?id=x;

API to search products GET api/v2/products/search

Order Management Service

API to place an order with the system.

POST/api/v2/createOrder

Customer Management Service

API to add, update, delete customers from the Merchant's store

POST/API/v2/createCustomer.

Inventory Management Service

API to fetch merchant's inventory for a specific store

GET api/v2/store/id/inventory

API to add details to merchants's inventory for a specific store

PUT api/v2/store/inventory/createInventory

Merchant Service

Allowing for new merchants to be registered to the system

POST api/v2/createMerchant

Every new merchant registered with the system will be allocated with resources, and web application components and databases for their own isolated management.

Database design

The main goal of this system will be to enable customers to place orders on the merchant's store's website. We need strong consistency and accuracy around the data, because this will involve, modifying item's inventory and making payments. We will choose a Relational Database for this design.

The merchant's data and the related metadata can also be stored in a relational database, for the system.

1) Merchant Database - merchant_id, merchant_metadata_id, date_Created.

2) Merchant_metadata_id - merchant_metadata_id, merchant_name, merchant_num_stores, merchant_location, merchan_Additional_info, merchant_preferred_payment etc.

For every merchant, they will have the below database design

1) Customer - customer_id, customer_name, customer_email, date_created.

2) Item- item_id, item_name, item_date_created, inventory_id

3) Inventory- inventory_id, inventory_num

4) Orders - order_id, date_Created, order_amount, order_Status, payment_id etc.

5) Payment - payment_id, payment_status, payment_method_info, date_created.

High-level design

1. Merchant Orchestrator - We need to be able to provide a mechanism to store the merchants and scale them in isolation. Every merchant should have their own web application components, and database and associated microservices. To enable this, we can make use of some containerised orchestration platform like Kubernetes to help maintain separate merchant pods for every merchant.
2. MerchantStore Management Service - This will allow for adding stores for merchants.
3. ProductManagement Service - This allows merchants to list, create, update or delete products
4. Customer Management Service- This allows for creation, updation or deletion of customers for a particular merchant.
5. Inventory management Service- This allows merchants to update inventory, fetch inventory details.
6. Order management Service - This enables merchants to manage the lifecycle of an order, order creation, integrate with payments, process order, update database with the updated inventory post order.
7. Payment Integration Service- This helps in processing the payment, via a payment gateway.
8. Notification Service-To push notifications to the customer about order updates.
9. Monitoring Service like Datadog - to help leep track of application logs, and monitor the health of the various components and alert if any component goes down.
10. Database - Relational Database for storing the information about the different entities.

Request flows

1. Merchant registers itself on the system
2. After merchant is registered, the merchant orchestrator service allocates resources and database and other components to this merchant.
3. The merchant makes a request to add a store on the website. The MerchantStore Management service creates stores and adds store details into the database.
4. After the store is added, the merchant can now add products to its store. The product management service takes care of this and provides APIs to add the products onto the store.
5. The merchant can add inventory and update inventory for the products via the Inventory Management Service.
6. When a customer browses products on the store, and want to place an order, the Order management service takes care of creating the order, updating inventory in the database after placing the order.
7. The payment gateway confirms the payment for the order and sends the status to the order service.
8. The notification service sends notification to the customer about the order updates based on the notification preferences of the customer.

Detailed component design

Merchant Orchestrator - Since we need all merchants to be isloated from each other, we can use a container orchestration platform like Kubernetes for this. When a merchant registers itself with the system, the system triggers an automated deployment to spin up a merchant pod for the merchant. This process will involve creating containers for the services required by the merchant pod to exist like database, web application components and web servers.

Kubernetes provides a host of services like monitoring and maintaining the health of these pods, load balancing and allocation of resources etc.

This way, we can have a seamless way of spinning up merchant pods for different merchants and keep them isolated too.

For the database, we are using MySQL or PostGres SQL - This will ensure strong consistency for the data. We can optimise by directing reads from read replicas, and writing to master node.

For search functionality on the merchant's store, we can use inverted indexes for product search . that will help deliver faster results.

Trade offs/Tech choices

MySQL vs NoSQL - MySQL is chosen because we need a more consistency and accuracy of data here. More than the amount of data, since we are making payments, and updating order inventory, we make use of the ACID properties of MySQL.

Microservices based architecture - Because we have a lot of different tasks involved, microservices are best suited to localise the functionalities and deal with failures/issues with different services at an isolated level.

Failure scenarios/bottlenecks

1. All the microservices for a particular merchant are horizontally scalable, we can add more instances of the services.
2. MySQL will have a master- slave replication model, It will be optimised to perform reads from read replicas and writes to the master node.
3. Payment Failures - If the payment fails on the payment gateway, we can allow the user to do another retry and if it fails post that, we need to mark this order as payment failed, and send an alert to the payment integrator we have integrated with.

Future improvements

1. Using ML/AI algorithms for payment fraud detection.
2. Using ML/AI for predictive determining of spike times, and auto scaling.
3. Recommender systems for customising the experience for customers.
4. As the system gets global users, we can deploy the services in multiple geographical regions and also use CDN to deliver static content based on that. This will further reduce latency.