Ebay Auction (used)

April 10, 2022 6:00 PM PDT

---

This document summarizes the mock system design interview focused on an eBay auction system. The discussion covered functional and non-functional requirements, system architecture, database design, and various technical considerations for implementing a robust auction platform.

Interview Details

• Level: L5 (Senior)
• Duration: 45 minutes
• Topic Covered: eBay auction system
• Drawing Tool Used: Excalidraw

Requirements

Functional Requirements

1. Seller Actions:

   • Seller enlists a product (product, inventory).
   • Seller creates an auction.

2. Bidder Actions:

   • Bidder can search for products.
   • Auction starts; bidders can place bids.
   • Bidders can see real-time bidding prices.
   • Bidders can limit bids (v2).
   • Waiting list for bidders (v2).
   • Auction concludes with a winner -> payment -> auction finish.

Non-Functional Requirements

• User Load:
  • 100M Daily Active Users (DAU)
  • 1M products
  • 100 queries/product/day
• Query Performance:
  • Query QPS: 1000
  • Bidding write QPS: 200
  • 50% of connections for real-time price display.

System Design

External APIs

• Integration with external services for payment and notifications.

Database Schema

• Use of NoSQL databases to handle high write throughput.
• Options for handling large records:
  • HDFS for append logs.
  • Sharding by option ID or time range.

Bidding Process

• Bid Agent Functionality:

  • Informs bidders of the latest prices.
  • Maintains a list of top-N prices.

• Data Structures:

  • HashTable for storing user bids.
  • LinkedList for managing bid history.

Streaming and Processing

• Use of Flink for stream processing with "exact once" semantics.
• Kafka for message queuing:
  • Two Kafka topics for different processing stages.
  • First topic for real-time bidding data.
  • Second topic for aggregated data post-processing.

Caching and Performance

• Use of Redis for in-memory operations:
  • Writeback buffer to manage data updates.
  • Consideration of data loss risks with frequent updates.

Handling Spiky Traffic

• Strategies for managing high read/write loads:
  • Redis can handle up to 100k operations per node.
  • Sharding and replication strategies for scaling.

Feedback and Discussion Points

Interviewer Feedback

• Strong foundation in system design concepts.
• Emphasis on focusing on the bidding process rather than seller actions.
• Need for consistency in handling NoSQL vs. SQL trade-offs.

Audience Insights

• Discussion on QPS estimation and scaling concerns.
• Clarification on Kafka usage and the need for multiple topics.
• Consideration of load balancing and data consistency across multiple data centers.

Technical Questions Raised

• How to manage large record sizes in the database?
• When to persist data from Redis to the database?
• The necessity of using Redis alongside Kafka for buffering peak services.

Conclusion

The interview highlighted the complexities involved in designing a scalable and efficient auction system. Key considerations included real-time bidding, data consistency, and handling high traffic loads. The discussion provided valuable insights into the trade-offs and architectural decisions necessary for building a robust eBay auction platform.