System Design Fight Club: Designing an Inventory Tracking System

Introduction

• Objective: Design an inventory tracking system.
• Resource: Payment gateway documentation (e.g., Stripe) was used for guidance.

Key Features to Support

• Track item count and show in-stock items.
• Track inventory changes in distributed transactions.
• Expose an API interface similar to payment gateways.
• Support inventory snapshots and inventory auditing.

Out of Scope Features

• Order placement and payment handling.
• Item listing and location lookup.

Common Interview Concerns

• Thread contention.
• Large object issues.

System Requirements

• Handle large volume similar to Amazon.com:
  • ~3 billion visits/month, 10 page views/visit.
  • Prime Day: 300 million items in 2 days (~1500 writes/second).
  • Roughly 10,000 reads/second needed.

System Architecture

Interface for Distributed Transactions

• Step 1: Place a hold on an item.
• Step 2: Execute the hold when the purchase is confirmed.

Components

• Customer Browser
• Ordering Service: Handles order placements.
• Listing Service: Handles item availability checks.
• Inventory Service: Centralized system for managing inventory.
• Inventory Database (DB): Stores inventory details.
• Event Sourcing DB: For capturing changes for snapshot reconstruction.

Process Flow

1. Read Scenario:
   • Request from Listing Service → Check Inventory DB → Respond with availability.
2. Order Placement:
   • Request from Ordering Service → Place hold → UUID generated → Update Inventory DB.

Detailed Design

Database Schema

• Item ID (e.g., ABC123)
• Count (e.g., 5)
• Warehouse ID (e.g., 123)
• UUID for Holds
• Timestamp for Holds

Handling Transactions

• Use a message broker (e.g., Kafka) for high availability and to decouple database operations.
• Record transactions in an event sourcing database for reconstructing snapshots.
• Use strong consistency for hold placements; eventual consistency for holds execution.

Snapshot and Auditing

• Reconstruct snapshots using MapReduce with tasks reading event sourcing DB.
• Snapshot DB records snapshots up to a certain timestamp.
• Schema: Item ID, count, warehouse ID, timestamp (snapshot time).
• Consistency: Strong read for transactions, eventual consistency for snapshots.

Handling High Volume and Large Objects

• Thread Contention: Avoid blocking by not tracking inventory strictly or sharding items.
• Large Object Handling: Separate holds into a different DB if objects become too large.

Conclusion

• Design offers scalability similar to large e-commerce platforms (e.g., Amazon).
• Future improvements include optimization of snapshot processing and database management.
• Encouragement for feedback and new problem suggestions.