System requirements

Functional:

• User Authentication: This ensures only registered users can participate in the flash sale. It includes functionalities for user registration, login, and logout.
• View Deals: Users should be able to browse ongoing flash sale deals with details like product information, discounts, and remaining time.
• Add to Cart: Allows users to add desired deals to their virtual shopping cart during the sale.
• Checkout: Enables users to complete the purchase process by confirming items in their cart, processing payment, and placing the order.
• Inventory Management: This ensures accurate tracking of available product quantities throughout the sale. It involves functions for managing stock levels and updating them as purchases are made.
• Order Processing: Real-time processing of orders placed during the flash sale is crucial. This includes handling payments, updating inventory, generating order confirmations, and notifying users.

Non-Functional:

• Scalability: The system should be able to handle a sudden influx of users and concurrent transactions during the flash sale peak hours. This might involve implementing techniques for horizontal scaling to distribute the load across multiple servers.
• Reliability: High availability is essential during the flash sale. This ensures the system remains operational throughout the event to avoid any disruptions or downtime. Techniques like redundancy and failover mechanisms can be employed to achieve this.
• Performance: The system should respond quickly to user actions with minimal latency. This provides a smooth and responsive user experience, especially during peak traffic. Optimizing database queries, caching mechanisms, and efficient data structures can contribute to faster performance.
• Security: Security encompasses data privacy, secure payment processing, and protection against unauthorized access. This involves implementing measures like data encryption, secure authentication protocols, and intrusion detection systems.
• Maintainability: The system should be designed with maintainability in mind. This allows for easier updates, bug fixes, and future feature implementations to support evolving needs. Techniques like modular design, clear documentation, and automated testing can improve maintainability.

Capacity estimation

let us assume during the flash sale, there are 10 million requests, and the sale lasts for 15 minutes.

Calculations:

Requests per Second:

• Total Requests = 10,000,000
• Sale Duration = 15 minutes = 15 * 60 seconds = 900 seconds
• Requests per Second = Total Requests / Sale Duration = 10,000,000 / 900 = 11111.11 (round up to 11112 for whole requests)
• Approximately, we need to handle 11 thousand request per second.

Scaling the Services:

• Traffic Spikes: Traffic might not be evenly distributed throughout the sale. There could be surges at the beginning or end, requiring more capacity than the average.
• Server Overhead: The 10,000 requests per server is an ideal scenario. Real-world servers have additional processing overhead that can reduce capacity during peak loads.
• Buffer for Unexpected Load: Unexpectedly high traffic can overwhelm a system designed for the calculated average.

Therefore, horizontal scaling is recommended for a flash sale system. This involves adding more servers to handle increased load during the event. Here's how it can be implemented:

1. Load Balancing: A load balancer distributes incoming user requests across a pool of servers. This ensures no single server gets overloaded while others are idle.
2. Auto-Scaling: Cloud platforms offer auto-scaling features that automatically add or remove servers based on predefined metrics like CPU usage or number of concurrent connections. This helps to dynamically adjust server capacity to meet fluctuating demand during the flash sale.

Ensuring System Stability During Peak Load:

Here are additional strategies to handle peak load and prevent crashes:

• Caching: Frequently accessed data (e.g., product details) can be cached to reduce database load and improve response times.
• Database Optimization: Optimize database queries and consider using a distributed database for high traffic situations.
• Queueing System: Implement a queueing system for tasks like order processing. This helps handle temporary spikes without overwhelming the system.
• Monitoring and Alerting: Continuously monitor system performance during the sale. Set up alerts to identify potential bottlenecks and allow for proactive intervention before issues arise.

API design

Here's a breakdown of some key APIs for the flash sale system, categorized by functionality:

User Management APIs:

• Register User: Allows users to create a new account with necessary details (name, email, password etc.)
• Login User: Enables user login with credentials (email, password) and generates a secure session token.
• Logout User: Terminates the user session and invalidates the session token.

Deal Management APIs:

• Get Active Deals: Retrieves a list of ongoing flash sale deals with details like product information, discount, and remaining time.
• Get Deal Details: Fetches detailed information for a specific flash sale deal. (Optional)

Cart Management APIs:

• Add to Cart: Adds a specific deal (product) to the user's shopping cart.
• Remove from Cart: Removes a specific deal (product) from the user's shopping cart.
• Get Cart Items: Retrieves a list of all deals (products) currently in the user's cart.
• Update Cart Quantity: Allows updating the quantity of a specific deal (product) in the cart.

Checkout and Order Processing APIs:

• Checkout: Initiates the checkout process, retrieves the user's cart details and calculates the total amount.
• Place Order: Places an order for the items in the user's cart. This involves processing payment information (may require integration with a payment gateway API), updating inventory levels, and generating an order confirmation.

Inventory Management APIs:

• (Internal API, not exposed publicly):
• Check Inventory: Checks if sufficient stock is available for a specific deal (product) before adding it to the cart or placing an order.
• Update Inventory: Reduces stock level for a specific deal (product) after a successful order placement.

Notification APIs:

• (Internal API, not exposed publicly):
• Send Notification: Sends real-time notifications to users about new deals, order status updates, and flash sale announcements.

Additional Considerations:

• Security: All APIs should implement authentication and authorization mechanisms to ensure only authorized users can access specific functionalities.
• Error Handling: APIs should handle potential errors gracefully and return informative error codes and messages.
• Rate Limiting: Implement rate limiting for specific APIs (e.g., checkout) to prevent abuse and ensure fair access during peak loads.
• Versioning: Consider versioning APIs to allow for future updates and maintain backwards compatibility with existing clients.

These are some of the core APIs needed for the flash sale system.

Database Selection Breakdown for Flash Sale System

Data Type: User Accounts & Orders (including historical data)

Database Type: SQL Database (e.g., MySQL, PostgreSQL)

Reasoning: Structured data with complex relationships benefits from relational capabilities for efficient queries and data integrity.

CAP Theorem Focus:

• Balanced (Consistency & Availability)
• Transactions and replication ensure data integrity while maintaining high availability during peak loads.

Data Type: Product Catalog & Static Deal Information

Database Type: NoSQL Document Store (e.g., MongoDB)

Reasoning: Flexible schema and fast read/writes are ideal for product data with potential variations in structure.

CAP Theorem Focus:

• Availability Focused
• Prioritize read/write performance during peak sales even if data consistency might lag slightly across replicas.

Data Type: Shopping Carts & Inventory Levels

Database Type: Key-Value Store (e.g., Redis)

Reasoning: Fast access and updates for frequently changing data like cart contents and stock levels are crucial for a smooth user experience.

CAP Theorem Focus:

• Availability Focused
• Prioritize immediate updates to reflect real-time changes in carts and inventory, even if consistency across all servers might be momentarily delayed.

Data Partitioning Strategies for Flash Sale System

Best Partitioning Strategy:

For the flash sale system, a horizontal partitioning strategy based on user ID is most suitable. This distributes user data and related orders across multiple database servers.

Reasoning: User data and orders are typically accessed by individual users. Horizontal partitioning by user ID ensures balanced load distribution and improves query performance during peak traffic when specific users are most active.

Partitioning Algorithm: Hashing is a common partitioning algorithm for horizontal partitioning. The user ID can be hashed to determine the appropriate server for storing that user's data.

High-level design

This section outlines the key components required for a scalable and robust flash sale system:

1. User Management Service:

• Handles user registration, login, and logout functionalities.
• Issues secure session tokens for authenticated users.
• Manages user profiles and preferences (optional).

2. Product and Deal Management Service:

• Stores product information, including details like name, description, category, and price.
• Manages flash sale deals with defined product associations, discount percentages, and duration.
• Provides APIs for adding, editing, and deleting deals.

3. Inventory Service:

• Tracks real-time stock availability for each product.
• Uses a key-value store (e.g., Redis) for fast access and updates.
• Provides APIs for checking stock levels and updating them after successful order placements.

4. Shopping Cart Service:

• Manages user shopping carts, allowing users to add, remove, and update quantities of desired deals.
• Stores cart contents for each user during the sale.
• May integrate with a session management system for persistent carts.

5. Order Processing Service:

• Processes user orders during the flash sale.
• Validates cart contents and ensures sufficient inventory.
• Integrates with a payment gateway to handle secure payment processing.
• Creates and stores order details in the database.
• Triggers updates to inventory levels upon successful order completion.
• Optionally, sends order confirmation emails to users.

6. Deal Display Service (Optional):

• Responsible for caching and serving product and deal information efficiently to users.
• Utilizes a caching mechanism (e.g., CDN) to reduce load on the main product and deal management service.
• May integrate with a content delivery network (CDN) for faster content delivery.

7. Notification Service (Optional):

• Sends real-time notifications to users about new deals, order updates, and flash sale announcements.
• Utilizes a message queue (e.g., RabbitMQ, Kafka) for asynchronous and reliable notification delivery.

8. Load Balancer:

• Distributes incoming user traffic across multiple instances of the various services.
• Ensures that no single server gets overloaded during peak loads.

9. API Gateway:

• Serves as a single entry point for all external APIs exposed by the system.
• Provides routing and authentication mechanisms for incoming API requests.

10. Database (SQL & NoSQL):

• Stores user accounts, orders, and historical sales data (relational database).
• Stores product information and potentially frequently accessed deal details (NoSQL document store).

11. Monitoring & Logging System:

• Continuously monitors system performance and resource utilization.
• Logs system events for troubleshooting and audit purposes.
• Generates alerts for potential issues to ensure proactive intervention.

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

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?