System Requirements

Functional:

User authentication and authorization:

User registration, login, and logout.

Password management and reset functionality.

Product Management:

CRUD operations for products (create, read, update, delete).

Display product details, including images, descriptions, and prices.

Flash Sale Management:

Schedule flash sales with start and end times.

Apply discounts to products during the flash sale.

Order Management:

Cart functionality (add, remove, update items).

Checkout process.

Order creation and confirmation.

Payment processing integration.

Inventory Management:

Track product stock levels.

Reserve stock during checkout to prevent overselling.

Notifications:

Notify users of upcoming flash sales.

Send order confirmation emails.

Non-Functional:

Scalability: The system must handle sudden spikes in traffic.

Performance: Low latency responses, especially during peak times.

Availability: High uptime during flash sales.

Security: Protect user data and prevent unauthorised access.

Usability: intuitive and responsive user interface.

Reliability: Ensure consistent behaviour under high loads.

Capacity Estimation

Storage Estimation:

1. User Data:

Assume 1 million users, with each user record containing:

User ID (4 bytes)

Name (50 bytes)

Email (50 bytes)

Password (50 bytes)

Other metadata (50 bytes)

Total user data size: 1,000,000 users * 204 bytes/user = 204,000,000 bytes or approximately 204 GB

2. Product Data:

Assume 10,000 products, with each product record containing:

Product ID (4 bytes)

Name (50 bytes)

Description (100 bytes)

Price (4 bytes)

Other metadata (50 bytes)

Total product data size: 10,000 products * 208 bytes/product = 2,080,000 bytes or approximately 2 GB

3. Order Data:

Assume 100,000 orders per day, with each order record containing:

Order ID (4 bytes)

User ID (4 bytes)

Product ID (4 bytes)

Quantity (2 bytes)

Total amount (4 bytes)

Timestamp (4 bytes)

Total order data size: 100,000 orders/day * 20 bytes/order = 2,000,000 bytes or approximately 2 GB per day

4. Payment Transaction Data:

Assume 100,000 payment transactions per day, with each transaction record containing:

Transaction ID (4 bytes)

Order ID (4 bytes)

Payment method (2 bytes)

Transaction amount (4 bytes)

Timestamp (4 bytes)

Total payment transaction data size: 100,000 transactions/day * 18 bytes/transaction = 1,800,000 bytes or approximately 1.8 GB per day

Total Estimated Storage Required:

User data: 204 GB

Product data: 2 GB

Order data: 2 GB per day (assuming 30 days: 60 GB)

Payment transaction data: 1.8 GB per day (assuming 30 days: 54 GB)

Total estimated storage required for 30 days: 204 GB + 2 GB + 60 GB + 54 GB = 320 GB

Latency Estimation:

1. Database Query Response Time:

Assume an average query response time of 20 ms

Peak traffic: 500 RPS * 20 ms/query = 10,000 ms or 10 seconds

2. API Response Time:

Assume an average API response time of 50 ms

Peak traffic: 500 RPS * 50 ms/query = 25,000 ms or 25 seconds

3. Payment Processing Time:

Assume an average payment processing time of 200 ms

Peak traffic: 500 RPS * 200 ms/query = 100,000 ms or 100 seconds

API Design

POST /register - User registration.

POST /login - User login.

GET /products - List all products.

GET /products/{id} - Get product details.

POST /orders - Create a new order.

GET /orders/{id} - Get order details.

POST /sales - Schedule a flash sale.

GET /sales - List all flash sales.

Database Design

Users Table:

UserID (Primary Key)

Username

PasswordHash

Email

CreatedAt

Products Table:

ProductID (Primary Key)

Name

Description

Price

Stock

CreatedAt

Sales Table:

SaleID (Primary Key)

ProductID (Foreign Key)

StartTime

EndTime

Discount

CreatedAt

Orders Table:

OrderID (Primary Key)

UserID (Foreign Key)

ProductID (Foreign Key)

Quantity

OrderStatus

CreatedAt

Inventory Table:

InventoryID (Primary Key)

ProductID (Foreign Key)

AvailableStock

ReservedStock

erDiagram
    USER {
        int id PK
        string name
        string email
        string password
    }
    
    PRODUCT {
        int id PK
        string name
        float price
        int stock
    }
    
    ORDER {
        int id PK
        int user_id FK
        datetime order_date
        float total_amount
    }
    
    ORDER_ITEM {
        int id PK
        int order_id FK
        int product_id FK
        int quantity
        float price
    }
    
    FLASH_SALE {
        int id PK
        int product_id FK
        datetime start_time
        datetime end_time
        float sale_price
    }
    
    USER ||--o{ ORDER : "places"
    ORDER ||--o{ ORDER_ITEM : "contains"
    PRODUCT ||--o{ ORDER_ITEM : "included in"
    PRODUCT ||--o{ FLASH_SALE : "is part of"

High-level Design

The high-level design of a flash sales system illustrates the interaction between various microservices and databases within the system. Here's an explanation of each component and the overall workflow:

Components:

API Gateway:

Acts as the single entry point for all client requests.

Routes requests to appropriate backend services.

Handles tasks such as authentication, rate limiting, and logging.

Inventory Service:

Manages the availability of products.

Keeps track of stock levels in real-time.

Updates the inventory status based on product reservations and purchases.

Booking Service:

Handles the booking or reservation of products during a flash sale.

Interacts with the Inventory Service to reserve items when a booking is made.

Inventory Queue:

Used for asynchronous communication between the Booking Service and Inventory Service.

Ensures that updates to the inventory are processed in an orderly fashion.

Helps in handling high traffic by queueing inventory updates and processing them sequentially.

Booking DB (Database):

Store booking details and reservations.

Ensures data consistency and integrity for all booking transactions.

Checkout Service:

Manages the checkout process for users.

Processes payments and finalizes orders.

Ensures booked items are purchased or returned to the inventory if not completed.

Checkout DB (Database):

Store checkout and transaction details.

Manages data related to user payments, order confirmations, and order history.

graph TD
    subgraph User
        A[User Interface]
    end
    
    subgraph Backend
        B[Sales Service]
        C[Inventory Service]
        D[Payment Gateway]
        E[Notification Service]
    end
    
    subgraph Database
        F[User Data]
        G[Sales Data]
        H[Inventory Data]
        I[Payment Data]
    end
    
    A -->|Make Purchase| B
    A -->|Check Inventory| C
    
    B -->|Update Sales| G
    B -->|Process Payment| D
    B -->|Notify User| E
    
    C -->|Check Availability| H
    C -->|Update Inventory| H
    
    D -->|Validate Payment| I
    D -->|Update Payment| I
    
    E -->|Send Confirmation| F
    E -->|Update Notifications| F

Request Flows

Within a Flash Sales System context, the sequence diagram represents the interactions between the User, Product, Order, OrderItem, and FlashSale components. All of the steps and interactions that are illustrated in the figure are broken down into the following components:

1. User Views Products:

The user sends a request to the Product entity to view available products.

The product entity processes this request and returns the list of products to the user.

2. User Places Order:

After selecting a product, the user places an order by sending a request to the order entity.

The order entity receives this request and initiates the process of creating an order.

3. Order Checks Flash Sale:

The Order entity must check if the selected product is part of an ongoing flash sale to apply discounts.

The Order entity sends a request to the FlashSale entity to verify if the product is included in a current flash sale.

The FlashSale entity responds with the discount information, if applicable.

4. Order Adds Item:

The order entity proceeds to add the selected product to the order by creating an OrderItem.

The Order entity sends a request to the OrderItem entity to add the product as an item in the order.

5. OrderItem Confirms Item:

The OrderItem entity processes the request and confirms the addition of the product to the order.

The OrderItem entity sends a confirmation response back to the Order entity.

6. Order Confirmation:

After successfully adding the item and applying any relevant flash sale discounts, the Order entity finalizes the order.

The Order entity sends an order confirmation back to the user, indicating that the order has been successfully placed.

Key Interactions:

User and Product: Interaction to view and select products.

User and Order: Interaction to place an order for selected products.

Order and FlashSale: Interaction to check for applicable flash sale discounts.

Order and OrderItem: Interaction to add products to the order and confirm the order items.

Sequence Flow:

The sequence starts with the User browsing and selecting products.

The user places an order, triggering the creation of an Order and associated OrderItems.

The system checks for flash sale discounts, applies them if available, and confirms the order.

The sequence ends with the user receiving an order confirmation.

This diagram visually represents the flow of events and interactions within a Flash Sales System when a user orders a product that may be part of a flash sale.

sequenceDiagram
    participant User
    participant UI as User Interface
    participant SalesService
    participant InventoryService
    participant PaymentGateway
    participant NotificationService

    User->>UI: Browse Products
    UI->>SalesService: Fetch Flash Sales Products
    SalesService->>InventoryService: Get Available Products for Flash Sale
    InventoryService-->>SalesService: Return Flash Sale Products
    SalesService-->>UI: Display Flash Sale Products
    
    User->>UI: Select Product and Place Order
    UI->>SalesService: Create Order
    SalesService->>InventoryService: Check Product Stock
    InventoryService-->>SalesService: Confirm Stock Availability
    SalesService->>PaymentGateway: Process Payment
    PaymentGateway-->>SalesService: Confirm Payment
    SalesService->>InventoryService: Update Product Stock
    InventoryService-->>SalesService: Stock Updated
    SalesService->>NotificationService: Send Order Confirmation
    NotificationService-->>User: Order Confirmation Sent
    
    SalesService->>SalesService: Create Order Entry
    SalesService->>SalesService: Create OrderItem Entries

Detailed Component Design

The Flash Sale System is a complex distributed system composed of several key components. Let's dive deeper into three critical components: the “Load Balancer”, the “Database System”, and the “Queue Management System”.

1. Load Balancer

Function

The load balancer distributes incoming traffic evenly across multiple servers to ensure no single server becomes a bottleneck.

Scalability:

Horizontal Scaling: Add more servers to the pool. The load balancer can distribute requests among the available servers, ensuring that traffic spikes are managed effectively.

Auto-Scaling: Implement auto-scaling with cloud services like AWS Auto Scaling to dynamically adjust the number of servers based on traffic load.

Relevant Algorithms:

Round Robin: A simple algorithm that distributes requests sequentially to each server in the pool. Effective for evenly distributed traffic but can be inefficient if servers have varying capacities.

Least Connections: Directs traffic to the server with the fewest active connections. This helps balance the load more effectively, especially if some servers handle requests faster than others.

IP Hash: Assigns a client to a specific server based on their IP address. This ensures session stickiness, which can be important for maintaining user sessions during a flash sale.

Data Structures:

Hash Maps: For IP Hash, a hash map can map IP addresses to server instances.

Priority Queues: Used in some advanced load balancing algorithms to dynamically adjust the weight of servers based on their load.

2. Database System

Function:

The database system stores all transactional data, including product inventory, user information, and order details.

Scalability:

Sharding: Partition the database into smaller, more manageable pieces called shards. Each shard can be hosted on a different server, allowing for parallel processing and reducing the load on any single database instance.

Replication: Use read replicas to distribute read operations across multiple copies of the database. This reduces the load on the primary database and improves read performance.

Relevant Algorithms:

Consistent Hashing: Used in sharding to ensure data is evenly distributed across shards and to facilitate dynamic scaling by minimizing the need to rehash existing data.

Two-Phase Commit (2PC): Ensures atomic transactions across distributed databases, maintaining data consistency even in the event of partial failures.

Data Structures:

B-Trees: Commonly used in database indexing to enable fast lookup, insertion, and deletion operations.

Skip Lists: An alternative to balanced trees for maintaining ordered data, providing efficient search, insertion, and deletion operations.

Detailed Example - Consistent Hashing:

Consistent hashing assigns data to nodes (shards) based on a hash value. Each shard is assigned a range of hash values, and data is directed to the shard corresponding to its hash value. When a new shard is added, only a small portion of data needs to be reassigned, making scaling efficient.

3. Queue Management System

Function:

Manages the order in which users access the system during peak traffic times, ensuring fair access and preventing server overload.

Scalability:

Distributed Queues: Implement distributed queue systems to handle large volumes of requests. These queues can be spread across multiple servers to handle increased load.

Priority Queues: Allow for different levels of access based on user type (e.g., VIP customers) to improve user experience for high-priority users.

Relevant Algorithms:

FIFO (First In, First Out): Ensures fair access by processing requests in the order they arrive. Simple and effective for most use cases.

Weighted Fair Queuing: Distributes resources proportionally based on predefined weights, allowing for priority handling of certain users or requests.

Data Structures:

Circular Buffers: Efficiently manage a queue with a fixed size, ideal for handling a known maximum number of requests.

Linked Lists: Provide dynamic queue management with flexible size, suitable for varying traffic loads.

Integration and Interaction

These components interact seamlessly to provide a robust and scalable flash sale system. The load balancer directs incoming traffic to the appropriate servers, ensuring no single server is overwhelmed. The database system handles read and write operations efficiently through sharding and replication, maintaining data consistency and availability. The queue management system ensures users are processed in an orderly fashion, preventing server overload and providing a smooth user experience.

By focusing on these components, the flash sale system can handle high traffic volumes, maintain data integrity, and ensure fair user access, providing a reliable platform for conducting high-demand sales events.

classDiagram
    class User {
        +int id
        +String name
        +String email
        +String password
        +List~Order~ orders
        +placeOrder(order: Order)
    }
    
    class Product {
        +int id
        +String name
        +float price
        +int stock
        +List~OrderItem~ orderItems
        +List~FlashSale~ flashSales
        +updateStock(quantity: int)
    }
    
    class Order {
        +int id
        +int userId
        +DateTime orderDate
        +float totalAmount
        +List~OrderItem~ orderItems
        +calculateTotalAmount(): float
    }
    
    class OrderItem {
        +int id
        +int orderId
        +int productId
        +int quantity
        +float price
        +Product product
    }
    
    class FlashSale {
        +int id
        +int productId
        +DateTime startTime
        +DateTime endTime
        +float salePrice
        +Product product
    }
    
    User "1" --o "*" Order : places
    Order "1" --o "*" OrderItem : contains
    OrderItem "*" --o "1" Product : includes
    FlashSale "*" --o "1" Product : is part of

Trade-offs/Tech Choices

Designing a flash sales system involves making several crucial tradeoffs and technical choices to ensure the system can handle the unique challenges posed by sudden spikes in traffic and demand. Here are the main considerations:

1. Scalability

Challenge: Flash sales generate a massive surge in traffic over a very short period of time. The system must handle this load without crashing.

Choices:

Horizontal Scaling: Cloud infrastructure (AWS, Azure, Google Cloud) can be used to scale out by adding more servers. This is more flexible and can handle unexpected surges better than vertical scaling.

Microservices Architecture: Break down the application into smaller, manageable services that can be scaled independently.

Load Balancing: Distribute incoming requests across multiple servers to prevent any single server from becoming a bottleneck.

2. Performance

Challenge: The system must respond quickly to user actions to provide a good user experience and ensure the sale process is smooth.

Choices:

Caching: Use in-memory data stores like Redis or Memcached to cache frequently accessed data (e.g., product details, inventory status).

CDN (Content Delivery Network): Distribute static content across multiple geographic locations to reduce latency.

Efficient Database Queries: Optimize database schema and queries, use indexing, and consider NoSQL databases like MongoDB for high read/write throughput.

3. Consistency vs. Availability

Challenge: Ensuring that inventory counts are accurate (consistency) while maintaining system availability during high traffic.

Choices:

Eventual Consistency: Accept temporary discrepancies in inventory counts to keep the system responsive. This might involve using a distributed database system that allows eventual consistency.

Strong Consistency: Use techniques like distributed locks or a single source of truth for inventory counts, which may impact performance but ensure accurate inventory tracking.

CAP Theorem Considerations: Balancing consistency, availability, and partition tolerance based on the business requirements. For flash sales, a common choice is to lean towards availability and partition tolerance with eventual consistency.

4. Data Management

Challenge: Handling the burst of transactions efficiently, ensuring data integrity, and preventing overselling.

Choices:

Database Sharding: Split the database into smaller, more manageable pieces to distribute the load.

Write Optimization: Implement batch processing for writes to reduce the load on the database.

Transactional Integrity: Use ACID transactions where necessary to maintain data integrity, especially for inventory updates.

5. User Experience

Challenge: Providing a seamless experience despite the high demand and potential for contention over limited stock.

Choices:

Real-Time Updates: Use WebSockets or long polling to give users real-time updates on inventory status and purchase confirmations.

Queuing Systems: Implement a queue system to manage user requests and ensure fairness. Users can be placed in a queue and served according to their arrival.

Progressive Enhancement: Ensure the core functionality works under heavy load and add enhancements (like animations and real-time feedback) that do not strain the backend.

6. Security

Challenge: Protecting against common threats like DDoS attacks and fraud and ensuring user data security.

Choices:

DDoS Protection: Use services like AWS Shield or Cloudflare to mitigate DDoS attacks.

Secure Payment Processing: Integrate with reliable payment gateways and use HTTPS for all transactions.

Fraud Detection: Implement algorithms to detect and prevent fraudulent activities, such as multiple purchases from the same IP address.

7. Monitoring and Logging

Challenge: Keeping track of system performance and quickly identifying issues during the flash sale.

Choices:

Monitoring Tools: Use tools like Prometheus, Grafana, or Datadog to monitor system performance and set up alerts for unusual activity.

Centralized Logging: To aggregate and analyze logs, implement centralized logging solutions like ELK Stack (Elasticsearch, Logstash, Kibana) or Splunk.

8. Testing and Reliability

Challenge: Ensuring the system is robust enough to handle the expected load without failures.

Choices:

Load Testing: Use tools like Apache JMeter, Gatling, or Locust to simulate flash sale conditions and test the system’s performance.

Chaos Engineering: Introduce random failures in a controlled manner (using tools like Chaos Monkey) to test the system’s resilience and recovery capabilities.

Automated Testing: Implement a comprehensive suite of automated tests (unit, integration, and end-to-end) to catch issues early.

Building a flash sales system requires careful consideration of scalability, performance, consistency, data management, user experience, security, monitoring, and reliability. Each technical choice involves tradeoffs, and the optimal solution depends on the specific requirements and constraints of the business. By addressing these challenges thoughtfully, it's possible to create a robust and efficient system capable of handling the intense demands of flash sales.

Failure Scenarios/Bottlenecks

Database Overload:

Read replicas and sharing to distribute load.

Implement caching to reduce read load.

Application Server Overload:

Auto-scaling to handle traffic spikes.

Circuit Breaker pattern to manage failures gracefully.

Network Latency:

CDN for static content.

Optimize database queries and API responses.

Future Improvements

Queue Management System: Introduce a queuing system that places users in a virtual line during peak times, ensuring fair access and reducing server overload.

Real-Time Notifications: Provide users with real-time updates on their queue status or notify them if an item they desire becomes available again due to a cancelled order.

Robust Security Measures:

Bot Protection: Integrate advanced bot detection and mitigation techniques to prevent automated scripts from overwhelming the system.

DDOS Protection: Implement Distributed Denial of Service (DDOS) protection using services like AWS Shield or Cloudflare to safeguard against malicious traffic spikes.

Improved Transaction Management:

Atomic Transactions: Ensure that all transactions, particularly checkouts, are atomic, meaning they are completed in a single, indivisible operation to minimise errors.

Retry Mechanisms: Develop robust retry mechanisms for failed transactions to ensure transient issues do not result in permanent failures.

Data Consistency and Integrity:

Distributed Transactions: Use distributed transaction management systems to maintain data consistency across different database instances.

Eventual Consistency Models: Implement eventual consistency models where strict consistency is not critical, allowing for better performance while ensuring data accuracy over time.

Monitoring and Analytics:

Real-Time Monitoring: Employ real-time monitoring tools to track system performance and detect issues promptly. Solutions like Prometheus and Grafana can help visualise and alert on key performance metrics.

User Behaviour Analytics: Analyse user behaviour during flash sales to identify and address pain points, improving the overall user experience.

Customer Support Enhancements:

Automated Support Systems: Implement chatbots and automated support systems to provide immediate assistance to users during high-traffic periods.

Feedback Collection: Establish a robust feedback collection mechanism to gather user input on system performance and user experience, allowing for continuous improvement.

By integrating these future improvements, the flash sale system can become more resilient, scalable, and user-friendly, providing a smoother and more reliable experience for both customers and system administrators.

Solutions

echo6239 - 06/03/2024

0

alchemy1135 - 07/08/2024

1