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

Here is a simple sequence diagram for when the customer places an order for a deal.

Detailed component design

Deal Management and Inventory Management for Preventing Over-selling in a Distributed System

Here's a detailed look at how deal management and inventory management work together to prevent overselling in a distributed system during a flash sale:

1. Real-time Inventory Tracking:

• Utilize a key-value store (e.g., Redis) to maintain real-time stock levels for each product associated with a flash sale deal.
• Update inventory levels immediately after successful order placements.

2. Inventory Checks before Order Processing:

• Integrate inventory checks into the order processing service.
• Before finalizing an order, verify if sufficient stock is available for each item in the cart.
• This check should happen at the database or key-value store level, not just on the application layer.

3. Inventory Buffers (Optional):

• Consider using an inventory buffer, reserving a small number of additional items (e.g., 1-2) beyond the actual stock.
• Allocate these buffer items first during order processing.
• This can provide a smoother user experience by reducing the likelihood of immediate "out of stock" messages during high concurrency.
• However, manage buffers carefully to avoid overselling.

Challenges in Distributed Systems:

• Eventual Consistency: Data updates in a distributed system might not be reflected instantaneously across all servers. This can lead to temporary inconsistencies.
• Network Latency: Communication between servers can introduce delays.

Handling Over-selling Risks:

• Optimistic Locking: If the stock level update fails due to optimistic locking (meaning another transaction already reduced the stock to zero), the order is rejected, and the user receives an "out of stock" message.
• Inventory Buffers: If the actual stock reaches zero after fulfilling buffered orders, subsequent orders will be rejected.
• Inventory Reconciliation (Optional): Regularly reconcile inventory levels across servers to identify and rectify any discrepancies.

Handling Simultaneous Transactions for a Single Item in a Flash Sale System

Here's how a flash sale system can handle edge cases like simultaneous transactions for a single remaining item:

1. Optimistic Locking (or Pessimistic Locking):

• A common approach is to implement optimistic locking or pessimistic locking at the database level.
• Optimistic Locking:
• Reads the item's stock level before processing the order.
• Attempts to decrease the stock level in the database.
• If another transaction has already reduced the stock to zero, the update fails due to a version mismatch.
• The user receives an error message indicating the item is out of stock.
• Pessimistic Locking:
• Acquires a lock on the item's stock level before processing the order.
• Only one transaction can hold the lock at a time.
• Other transactions attempting to acquire the lock will wait or be rejected.
• Releases the lock after successfully updating the stock level or encountering an error.

2. Inventory Buffer (Optional):

• In addition to locking mechanisms, you might consider an inventory buffer.
• This involves reserving a small buffer of additional stock (e.g., 1-2 items) beyond the actual available quantity.
• When an order is placed, the buffer is decremented first.
• If the actual stock reaches zero after fulfilling buffered orders, subsequent orders will be rejected.
• This approach can provide a smoother user experience by reducing the chance of immediate "out of stock" messages during high concurrency. However, it requires careful management to avoid overselling.

3. Queueing System (Optional):

• For high-demand items, consider a queueing system.
• Users who attempt to purchase the last remaining item are placed in a queue.
• The system processes orders one at a time based on the queue order.
• This ensures fairness and avoids race conditions where multiple users might see the item available and attempt to purchase it simultaneously.

API Rate Limiting Strategies for Flash Sales

API rate limiting is crucial for protecting a flash sale system from abuse and ensuring fair access to deals for all users. It involves restricting the number of requests a user or client can make within a specific time window. Here's a breakdown of different rate limiting strategies and their effectiveness in a flash sale scenario:

1. Fixed Window Rate Limiting:

• This is the simplest approach. It sets a maximum number of requests allowed within a fixed time window (e.g., 10 requests per minute).
• Users who exceed the limit within the window are blocked for the remaining duration.
• Effectiveness for Flash Sales: Partially effective. It prevents excessive requests but might be too rigid for a burst of activity at the sale's start.

2. Sliding Window Rate Limiting:

• This approach tracks the number of requests within a moving window.
• As time progresses, older requests "slide out" of the window, and new ones come in.
• This allows for a more dynamic approach compared to the fixed window.
• Effectiveness for Flash Sales: More effective than fixed windows. It accommodates bursts of activity at the sale's beginning while still limiting excessive requests.

3. Token Bucket Algorithm:

• This method uses a virtual "bucket" with a limited capacity to hold tokens.
• Users acquire tokens at a fixed rate (e.g., 1 token per second).
• Each API request consumes a token.
• If the bucket is empty, requests are rejected until it refills.
• Effectiveness for Flash Sales: Highly effective. It allows for a smooth flow of requests while preventing overload. You can adjust the refill rate to accommodate peak loads.

4. Leaky Bucket Algorithm:

• Similar to the token bucket, but instead of a fixed refill rate, the bucket leaks tokens at a constant rate over time.
• Users can make requests as long as there are tokens in the bucket.
• Effectiveness for Flash Sales: Can be effective for scenarios where users might have idle periods between requests. It allows for quick bursts of activity after the bucket refills.

Choosing the Right Strategy:

For flash sales, a combination of sliding window and token bucket algorithms is often recommended. The sliding window allows for initial bursts of activity, while the token bucket ensures a sustained, manageable flow of requests throughout the sale.

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?