Ebay Auction

January 9, 2022 7:00 PM PST

---

This document summarizes a mock system design interview focused on the design of an eBay auction system. The interview was structured to assess the candidate's ability to design a scalable and efficient auction platform, covering both functional and non-functional requirements, system architecture, and potential challenges in handling high throughput and consistency.

Interview Details

• Target Level: L5 (Senior)
• Duration: 1 hour
• Topic Covered: eBay Auction
• Drawing Tool Used: Draw.io/Diagram

Requirements

Functional Requirements

• Ability to create products
• Support for auctions and bidding
• Management of keywords and products
• Mechanisms to prevent cheating
• Seller reporting of lower prices
• User and order service availability

Non-Functional Requirements

• Daily Active Users (DAU): 100 million, with 10% (10 million) active daily
• Read/Write Ratio: 88:2 (read product/create product/make bid)
• Queries Per Second (QPS): 10k/s to 30k/s
• Machine Capacity: 1 container ~ 1k QPS, requiring 30 replicas
• Data Storage: 2 million products/day, approximately 2GB/day

System Design

System Design Diagram

• Architecture Layers:
  1. Stateless service layer (Service mesh architecture using Istio and Envoy)
  2. Caching layer
  3. Persistence layer

External APIs

• Products:
  • GET /products/<id>
  • DEL /products/<id>
  • POST /products
  • GET /products?keyword=<key_word>&page_size=...
• Auctions:
  • POST /auctions?product_id=<product_id>

Database Schema

• Auction Handling:
  • Use of HBase for data storage
  • Handling high throughput through local and global caching mechanisms (e.g., Redis-cluster)

Bid Processing Flow

1. User makes a bid.
2. Bid is compared against the local cache to ensure it exceeds the cached maximum.
3. Bid is inserted into HBase.
4. An asynchronous process for "auction reconciliation" updates the global maximum in Redis.

Discussions During the Interview

• The interviewee proposed a solution for handling high throughput and bid legitimacy.
• Feedback indicated that while the interviewee demonstrated strong skills, there were areas for improvement in diagram clarity and requirement prioritization.
• Key points of discussion included the handling of concurrent bids, consistency across different geographical locations, and the use of message queues versus caching.

Audience Feedback

• Suggestions were made to focus on basic functionalities first and to clarify which features are most critical.
• The audience emphasized the importance of understanding the trade-offs between different database solutions and the implications of global versus regional services.
• There were discussions on ensuring high consistency and the challenges associated with it, particularly in a distributed environment.

Workable Solutions Proposed

• Implementing a message queue to buffer incoming bids before processing them in HBase.
• Utilizing Redis to maintain the highest bid, with periodic updates to ensure eventual consistency.
• Recommendations for improvements included using WebSockets for real-time updates and stream processing for handling bids efficiently.

Key Improvements

1. Implement WebSockets for real-time bid updates.
2. Use Flink and message queues to manage global maximum bids.
3. Ensure the system can scale efficiently with distributed processing capabilities.

This summary encapsulates the key elements of the mock system design interview, highlighting the technical discussions and proposed solutions for designing a robust eBay auction system.