System requirements

Functional:

1. User Authentication:
   • Customers should be able to log in and log out of the system.
2. Shopping Cart Management:
   • Ability to add items to the cart.
   • Update item quantities in the cart.
   • Delete items from the cart.
   • View the contents of the cart.
3. Checkout Process:
   • Payment processing should be enabled.
   • Order confirmation once the payment is completed.
4. Item Availability:
   • Check if items are in stock before adding to the cart.
5. User Profile Management (optional):
   • View and edit personal details such as name, address, and payment methods.

Non-Functional:

1. Performance:

• Expected Response Time: Critical operations, such as product searching, should have a response time of less than 2 seconds.
• Concurrent User Support: The system should be able to handle 5,000 concurrent users without performance degradation, necessitating load balancing and performance optimizations.

2. Scalability:

• Scaling the System: When the number of users reaches 50,000, the system should maintain performance without degradation. This could involve horizontal scaling (adding more servers).
• Handling Peak Traffic: The system should handle sudden spikes in traffic, especially during shopping seasons (e.g., holidays or special sales).

3. Reliability:

• Acceptable Downtime: The system should allow a maximum of 2 hours of downtime per week for scheduled maintenance.
• Required Availability: A target for system uptime should be set at 99.9% annually.

4. Security:

• Required Security Measures: SSL certificates and encryption should be implemented to protect user data. Additionally, tokenization and hashing methods for sensitive data may be recommended.
• Authentication Methods: Implementing two-factor authentication (2FA) for users can enhance security.

5. Usability:

• User Experience Expectations: The user interface should allow customers to reach their goals within a maximum of 3 clicks.
• Accessibility: The platform should cater to users with different abilities (e.g., support for screen readers).

6. Compliance:

• Industry Regulations: The system needs to comply with regulations such as GDPR and PCI DSS, which may require developing policies for data processing.

7. Maintainability:

• Ease of System Updates: The system should be designed for straightforward updates, ideally on a weekly or monthly basis.
• Documentation: Comprehensive technical documentation for all system components should be prepared to aid the maintenance team and developers.

8. Portability:

• Multi-Platform Support: The system should be compatible with both web and mobile devices.
• Multi-Language Support: Options for different languages should be provided based on target markets.

Capacity estimation

1. Normal Daily Requests:
   • 350,000 requests per day.
2. Peak Traffic Levels:
   • Moderate Peak: 2x to 4x increase → 700,000 to 1,400,000 requests per day.
   • High Traffic Events: 5x to 10x increase → 1,750,000 to 3,500,000 requests per day.

Summary of Capacity Estimation

1. Define Key Entities and Record Counts

Customers

• Expected: 50,000
• Average size per record: 1 KB
• Total size:

50,000×1 KB=50 MB

50,000 x 1 KB = 50 MB

Products

• Expected: 10,000
• Average size per record: 2 KB
• Total size:

10,000×2 KB=20 MB

Orders

• Expected orders per day: 1,000
• Order history retention: 30 days
• Total orders:
• 1,000×30=30,000

Average size per record: 1.5 KB

• Total size:

30,000×1.5 KB=45 MB

Order Items

• Average items per order: 3
• Total order items:
• 30,000×3=90,000
• Average size per record: 1 KB
• Total size:

90,000×1 KB=90 MB

Total Database Size

Total Size=50 + 20 + 45 + 90 =205 MB

3. Backup and Growth Considerations

• Backup Strategy: Allocate 1.5× to 2× the current size to account for backups and redundancy.
• Growth Rate: If growth is estimated at 10% per year, adjust the size accordingly.

4. Final Estimation

• Adjusted size with backups:
• 205 MB×1.5≈308 MB
• Rounded estimate for scalability: ~400 MB

API design

API Design Components

1. Authentication

• POST /api/auth/register: Register a new user.
• POST /api/auth/login: Authenticate a user and return an access token.
• POST /api/auth/logout: Logout a user.

2. User Management

• GET /api/users/{id}: Retrieve user profile by ID.
• PUT /api/users/{id}: Update user profile (e.g., name, address).
• DELETE /api/users/{id}: Delete user account.

3. Product Management

• GET /api/products: Retrieve all products (with optional query parameters for filtering).
• GET /api/products/{id}: Retrieve a specific product by ID.
• POST /api/products: Add a new product (admin only).
• PUT /api/products/{id}: Update product information (admin only).
• DELETE /api/products/{id}: Remove a product (admin only).

4. Shopping Cart Management

• POST /api/cart: Create a shopping cart or retrieve an existing one.
• GET /api/cart: Get contents of the shopping cart.
• POST /api/cart/items: Add an item to the shopping cart.
• PUT /api/cart/items/{id}: Update item quantity in the cart.
• DELETE /api/cart/items/{id}: Remove an item from the cart.

5. Order Management

• GET /api/orders: Retrieve all orders (admin only).
• GET /api/orders/{id}: Retrieve specific order details.
• POST /api/orders: Create a new order.
• PUT /api/orders/{id}: Update order status (admin only).
• DELETE /api/orders/{id}: Cancel an order.

6. Payment Processing

• POST /api/payments/initiate: Initiate a payment process.
• GET /api/payments/confirm: Confirm payment status.
• POST /api/payments/refund: Process a refund.

Database design

Key Entities

1. Customer: Stores customer information with unique identifiers, name, email, and address.
2. Product: Holds details about each product, including its name, price, description, and category.
3. Order: Represents an order placed by the customer, linking to the customer who made it and the order status.
4. Order Item: Details the individual items within an order, linking back to both the order and the product.
5. Shopping Cart: Represents a customer's active shopping cart, linking to the customer.
6. Cart Item: Contains items within a customer's shopping cart, similarly linking products and quantities.
7. Product Category: Categorizes products to facilitate searching and browsing.
8. Payment Transaction: Keeps track of payment details, linking to orders and storing important transaction information.

High-level design

High-Level Architecture Overview

The system can be divided into several layers/components:

1. Client Layer
   • Web Applications
   • Mobile Applications
2. API Layer
   • RESTful API Server or GraphQL Server
3. Business Logic Layer
   • Application Server
4. Database Layer
   • Relational Database Management System (RDBMS)
5. External Services
   • Third-party Payment Gateway
   • Notification Service (email/SMS)
   • Cloud Storage (for product images, etc.)

Description of Each Component

1. Client Layer:
   • Web Applications: Built using frameworks like React, Angular, or Vue.js to create an interactive user experience for browsing products, managing carts, and placing orders.
   • Mobile Applications: Native or cross-platform apps (e.g., React Native, Flutter) allowing users to access services on their mobile devices.
2. API Layer:
   • A RESTful API server handles incoming requests from the client applications, including user authentication, product retrieval, cart management, order processing, and payment requests. Frameworks like Express.js (Node.js), Flask (Python), or Spring Boot (Java) could be utilized.
3. Business Logic Layer:
   • The application server contains the core business logic, processing user requests, performing validations, and orchestrating interactions between various components. It will also handle security measures like authentication and authorization.
4. Database Layer:
   • A relational database (e.g., PostgreSQL, MySQL) stores structured data including users, products, orders, etc. This layer handles all data storage, retrieval, and management operations.
5. External Services:
   • Payment Gateway: A third-party service like PayPal, Stripe, or Square is integrated to handle payment processing securely.
   • Notification Service: For sending order confirmations, notifications, and promotional messages via email (e.g., using services like SendGrid or Mailgun) or SMS (e.g., Twilio).
   • Cloud Storage: Services like Amazon S3 or Google Cloud Storage can be used to store product images and any uploaded files.

Scalability and Resilience

• Load Balancer: Distributes incoming API traffic across multiple instances of the application server to handle increased traffic and ensure availability.
• Microservices Architecture: Optionally, you could design this system as microservices, splitting functionalities into smaller services that can be deployed independently.

Additional Considerations

• Caching Layer: Use a caching mechanism (e.g., Redis or Memcached) to store frequently accessed data, ensuring faster response times.
• Monitoring and Logging: Implement monitoring tools (e.g., Prometheus, Grafana) and logging (e.g., ELK stack) to observe system performance and troubleshoot issues quickly.
• API Gateway: To manage API traffic, perform request routing, authentication, and rate limiting.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

1. Monolithic vs. Microservices Architecture

Choice: For the initial phase, a microservices architecture is proposed, dividing the system into smaller, independently deployable services (e.g., authentication, product management, order processing).

Trade-offs:

• Pros:
  • Scalability: Each service can scale independently based on demand.
  • Deployment Flexibility: Different services can be deployed and updated without affecting the entire application.
  • Development Parallelism: Different teams can work on different services concurrently.
• Cons:
  • Complexity: Introducing multiple services increases the complexity of managing API communication, error handling, and inter-service dependency management.
  • Latency: The need for network calls between services can introduce latency in requests.

2. SQL vs. NoSQL Database

Choice: A relational database system (e.g., PostgreSQL or MySQL) was chosen over NoSQL databases (e.g., MongoDB, Cassandra).

Trade-offs:

• Pros:
  • ACID Compliance: Ensures data integrity and consistency through transactions, which is crucial for order processing.
  • Structured Query Language (SQL): Provides powerful querying capabilities, making it easier to manage complex queries.
• Cons:
  • Scalability: While relational databases can be vertically scaled, they might struggle with horizontal scalability compared to some NoSQL databases.
  • Schema Rigidity: Changes to the data schema can introduce overhead and require migrations.

3. Caching Strategies

Choice: Implementation of a caching layer using Redis to speed up access to frequently requested data (like product lists and user sessions).

Trade-offs:

• Pros:
  • Performance Improvement: Reduces load on the database and increases the response time for frequently accessed data.
  • Reduced Latency: Since Redis operates in-memory, accessing cached data is substantially faster than querying a database.
• Cons:
  • Consistency: Keeping the cache in sync with the database can introduce complexity, especially during concurrent writes or updates.
  • Data Volatility: Cached data can expire or become stale, requiring handling for cache invalidation strategy.

4. REST vs. GraphQL for API Design

Choice: Opted for RESTful APIs rather than implementing GraphQL.

Trade-offs:

• Pros:
  • Simplicity and Familiarity: REST is widely understood and easy to implement, making it an ideal choice for initial development.
  • Statelessness: Each API request is independent, simplifying load balancing and server management.
• Cons:
  • Over-fetching/Under-fetching: REST APIs might return more data than needed (over-fetching) or necessitate multiple requests to get all required data (under-fetching) compared to GraphQL's flexible querying capabilities.
  • Versioning: Keeping track of multiple versioned endpoints can increase maintenance overhead as the API evolves.

5. Cloud Provider Choice

Choice: Chose to deploy the application on a cloud provider like AWS or Google Cloud Platform instead of on-premises servers.

Trade-offs:

• Pros:
  • Scalability: Cloud services make it easy to scale resources up or down based on traffic demands.
  • Maintenance: Offloading infrastructure management to the cloud provider allows the team to focus on development.
  • Pay-as-you-go: Only pay for the resources you use, which can help manage costs effectively.
• Cons:
  • Vendor Lock-in: Dependence on a specific cloud provider can complicate migration to other providers or on-premises solutions in the future.
  • Cost Management: Without strict monitoring and scaling policies, cloud costs can escalate quickly.

Failure scenarios/bottlenecks

1. Database Bottleneck

Scenario:

The database may become a bottleneck during peak traffic (e.g., weekends, holidays) if requests for product information or order processing exceed its capacity.

Impact:

• Increased response times.
• Potential timeouts or failure in processing orders.
• Customer dissatisfaction and abandoned transactions.

Mitigation Strategies:

• Implement database sharding to distribute the load.
• Use read replicas to offload read requests from the primary database.
• Introduce caching mechanisms (e.g., Redis) for frequently accessed data to reduce database load.

2. API Rate Limiting

Scenario:

If the API layer is overwhelmed with requests (especially during promotional periods), it might become unresponsive.

Impact:

• Users may experience degraded service quality or timeouts.
• Increased error rates for API calls (HTTP 429 Too Many Requests).

Mitigation Strategies:

• Implement rate limiting using techniques like Token Bucket or Leaky Bucket.
• Use load balancers to distribute requests across multiple API instances.
• Optimize API endpoints to reduce processing time.

3. External Payment Gateway Failure

Scenario:

If the external payment provider experiences downtime or latency, payment processing requests may fail.

Impact:

• Orders cannot be processed, leading to customer frustration.
• Failures may block registration or checkout processes.

Mitigation Strategies:

• Implement payment fallback mechanisms using multiple payment gateways.
• Provide clear user feedback during the payment process (e.g., “Payment processing may take longer than usual”).
• Cache the status of previously successful payments to minimize retries.

4. Service Dependency Failures

Scenario:

Microservices designed for specific functionalities (like user authentication, order management, etc.) could fail or become unresponsive.

Impact:

• Related services might not be able to fulfill requests (e.g., placing an order if the authentication service is down).
• Overall system functionality may be affected.

Mitigation Strategies:

• Implement circuit breakers to gracefully handle failures and prevent cascading failures.
• Utilize service discovery to ensure dependency management and dynamic routing.
• Use retries with exponential backoff for transient errors in service calls.

5. Network Latency or Outages

Scenario:

Issues like high network latency or complete network outages can disrupt communication between client devices, API layer, and database.

Impact:

• High latency can lead to poor user experience while navigating the application.
• Network outages can prevent any interaction with the server.

Mitigation Strategies:

• Deploy in multiple geographic regions to provide redundancy for users in different locations.
• Leverage content delivery networks (CDNs) to cache static assets closer to users.
• Use asynchronous communication where possible to allow for user operations to continue even if network issues occur.

6. Frontend Application Failures

Scenario:

A bug in the web or mobile app might lead to crashes or significant usability issues during high traffic.

Impact:

• Users might be unable to add items to their cart or complete checks.
• Loss of sales and damage to brand reputation.

Mitigation Strategies:

• Implement thorough testing, including unit tests, integration tests, and end-to-end tests prior to release.
• Utilize feature flags to control which features are visible to users at any time, allowing you to roll back changes quickly.
• Monitor analytics and error reporting to identify and resolve issues rapidly.

7. Data Consistency Issues

Scenario:

Data can become inconsistent, especially if multiple services are involved and not properly synchronized.

Impact:

• Users may see outdated product information or incorrect order details.
• This inconsistency can lead to trust issues, causing customers to abandon the system.

Mitigation Strategies:

• Utilize distributed transactions or eventual consistency models according to the usage context.
• Regularly audit and maintain data consistency across services.
• Employ change data capture (CDC) mechanisms to ensure updates are propagated.

8. Resource Exhaustion

Scenario:

Running out of computational power, memory, or storage can cause slowdowns or outright failures of services.

Impact:

• Services might slow down significantly, leading to failed requests.
• New data cannot be written if storage is exhausted.

Mitigation Strategies:

• Implement autoscaling to dynamically adjust resource allocation based on current load.
• Regularly monitor resource utilization with alerting systems.
• Set up storage alerts for threshold monitoring while implementing data retention policies.

Future improvements

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