System requirements

Functional:

• Merchants are able to create online stores.
• Merchants are able to collect payments.
• Merchants are able to list different kind of products.
• Merchants are able to edit what their store looks like.
• Product Inventory.
• Managing inventory synchronization.
• Order processing.

Non-Functional:

• Isolation
• Merchant data must be isolated.
• Reliability
• The system must be reliable. It needs to be able to deal with unexpected spikes in traffic.
• Scalability
• The system must be scalable and handle hundreds of thousands of request by users.
• Potentially consider using microservices.
• Addressing data backup and recovery strategies

Capacity estimation

We can estimate the user traffic to be in the range of millions of users per day.

API design

1. Create Store API
2. Allow users to create a new online store by providing basic information such as store name, URL, and description.
3. Assign a unique identifier or store ID to each newly created store for easy reference.
4. User Management API
5. Allow merchants to login and logout
6. Search and filtering API
7. Search products based on keywords, categories or filters.
8. Filter products based on price range, brand, etc.
9. Sort products based on relevance, price, popularity
10. Order processing API
11. Please new orders
12. Update order status
13. Retrieve order details
14. Process payments
15. Management shipping and fulfillment
16. Product management API
17. Create, update and delete products
18. Retrieve product details, including name, price, description and images.
19. Categorize products
20. Manage product variants and options

Database design

• USER entity stores information about users who interact with the platform, including authentication details.

• STORE entity represents individual stores created by users, containing store-specific details.

• PRODUCT entity holds details of products listed on the platform, linked to the respective store they belong to.

• ORDER entity tracks orders placed by users, along with order status and associated user ID.

• ORDER_ITEM entity stores individual items within orders, including quantity, price, and references to the corresponding product and order.

• PAYMENT entity records payment transactions made for orders, including payment amount, date, and status.

High-level design

We can utilize a container orchestration platform like Kubernetes to provide isolated environments for each merchant. By leveraging Kubernetes, we can create separate pods or nodes for each merchant to ensure isolation and scalability.

The code for the request handler that determines the destination pod based on the merchant context can live in various components depending on the architectural design and requirements of the system. The merchant context can be determined by the merchant_id

There would be a service discovery mechanism to dynamically handle pod discovery and routing based on merchant_id.

Each Pod that maps to a merchant would essentially have its own backend and database.

High Level Diagram(s)

We would also need components and functionalities required for e-commerce stores.

Order Processing Service

• Order status update
• Order placement
• Payment processing integration
• We would have to choose payment gateway.
• Order history

Product Management Service

• Ability to list, upload products

Inventory Management Service

• Manages the inventory stock.

Request flows

When a merchant makes a request it would go through the API Gateway. The API Gateway acts as a centralized entry point for incoming requests and is responsible for routing requests based on predefined rules. It can inspect the request metadata, making routing decisions, and direct traffic to the appropriate pods.

Once the request hits the pods it will go through the backend logic and hit the cache or database to fetch/update necessary data.

Detailed component design

Kong API Gateway

1. Kong is an API gateway with features like rate limiting, authentication, and request routing that can enhance the platform's API management.
2. Utilize Kong plugins like Request Transformer or Header Transformation to modify or extract headers containing merchant context information from incoming requests. Configure Kong to forward requests with the extracted data to Istio's ingress gateway.

Istio

1. Istio can help manage the traffic flow between services, enhance security, and provide monitoring capabilities in a microservices environment
2. Define Virtual Services in Istio to map HTTP requests to specific Kubernetes services corresponding to merchant pods. Istio Virtual Services can be configured to extract merchant-specific information from requests.
3. Set up an Istio Gateway to act as the entry point for incoming traffic. Configure Virtual Services to route requests based on the merchant context extracted by Kong, directing traffic to respective merchant pods within the Kubernetes cluster.
4. Implement Istio's Quality of Service routing capabilities to ensure that merchant-specific traffic is directed to the appropriate pods based on the extracted context. Define routing rules for different merchants to ensure effective pod targeting.
5. Maintain consistency in configuration settings and shared context data between Istio and Kong to ensure accurate extraction and routing of merchant-specific information. Update configurations as needed to reflect changes in merchant context.
6. Leverage Istio's authentication and authorization policies to enforce access control and security measures for merchant-specific traffic. Ensure that only authenticated and authorized requests are routed to designated merchant pods.
7. Enable Istio's observability features like distributed tracing and monitoring to track requests, performance metrics, and traffic patterns related to merchant-specific routing. Monitor and analyze traffic flows for optimization and troubleshooting.

Data Storage and Database Component

1. Database Sharding:
2. distribute data across multiple databases based on merchant IDs for better performance and scalability.
3. Redis for Caching:
4. Utilize Redis for caching frequently accessed data to improve application performance and reduce database load.

Isolation with Network Policies

Network Policies in Kubernetes provide fine-grained control over pod-to-pod communication, enabling administrators to define rules for traffic flow within the cluster. Here's how advanced networking features like Network Policies can be leveraged in the architecture of Shoplify:

1. Isolation between Merchant Pods:
2. Network Policies can be used to enforce isolation between pods belonging to different merchants. Policies can restrict network communication and traffic flow, ensuring data privacy and security.
3. Pod-to-Pod Communication Rules:
4. Define Network Policies to specify which pods can communicate with each other based on labels, namespaces, or other metadata. This controls the traffic allowed between components within the cluster.
5. Deny-All Default Policy:
6. Implement a default-deny policy to block all pod-to-pod traffic by default. Specific rules can then be added to permit necessary communication paths, reducing the attack surface and enhancing security.
7. Traffic Shaping and QoS:
8. Network Policies enable Quality of Service (QoS) enforcement and traffic shaping rules. This helps prioritize and control network traffic based on application requirements in the Shoplify platform.
9. Port-Level Restrictions:
10. Apply Network Policies to restrict traffic to specific ports on pods hosting sensitive services like databases or payment gateways. This adds an extra layer of security and access control.
11. Ingress and Egress Rules:
12. Craft Network Policies to manage both ingress (incoming) and egress (outgoing) network traffic from pods. Define rules for allowed sources, destinations, and protocols to enforce communication policies.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?