Inventory management in HLD - Scalability & System Analysis

Scalability Analysis - Inventory management

Growth Table: Inventory Management System

Scale	Users	Inventory Items	Requests per Second (RPS)	Data Storage	Key Changes
Small	100	10,000	50	1 GB	Single server, monolithic DB, simple caching
Medium	10,000	1,000,000	5,000	100 GB	DB read replicas, app server scaling, caching layer
Large	1,000,000	100,000,000	500,000	10 TB	DB sharding, distributed cache, load balancers, async processing
Very Large	100,000,000	10,000,000,000	50,000,000	1 PB+	Multi-region deployment, CDN, advanced partitioning, event-driven architecture

First Bottleneck

At small scale, the database is the first bottleneck because it handles all inventory reads and writes. As users and inventory grow, the single database server struggles with query load and data size.

At medium scale, the application servers can become CPU and memory bottlenecks due to increased request processing and business logic.

At large scale, network bandwidth and data partitioning become critical as data volume and traffic grow beyond single data center limits.

Scaling Solutions

• Database Scaling: Use read replicas to distribute read traffic. Implement sharding to split data by inventory categories or regions.
• Caching: Add a distributed cache (e.g., Redis) to store frequently accessed inventory data and reduce DB load.
• Application Scaling: Horizontally scale app servers behind load balancers to handle more concurrent users.
• Async Processing: Use message queues for inventory updates to smooth spikes and improve responsiveness.
• Network & Storage: Use CDNs for static content and multi-region deployments to reduce latency and bandwidth bottlenecks.

Back-of-Envelope Cost Analysis

• At 10,000 users with 5,000 RPS, expect ~100 GB storage for inventory data and metadata.
• Each server handles ~3,000 concurrent connections; thus, 2 app servers needed at this scale.
• Database can handle ~10,000 QPS with read replicas; write QPS is lower, so write scaling needed.
• Network bandwidth: 1 Gbps (~125 MB/s) can support ~10,000 RPS if payloads are small (~10 KB).
• Cache memory sizing depends on hot data size; 10-20 GB Redis cluster typical at medium scale.

Interview Tip

Start by defining the scale and key metrics (users, requests, data size). Identify the first bottleneck logically (usually DB). Then discuss scaling strategies step-by-step: caching, read replicas, sharding, app scaling, and network optimizations. Always justify why each solution fits the bottleneck.

Self Check Question

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first and why?

Answer: Add read replicas to distribute read queries and reduce load on the primary database. This is the fastest way to scale read capacity without major redesign.

Key Result

Inventory management systems first hit database bottlenecks as users and data grow; scaling requires caching, read replicas, and sharding combined with app server scaling and network optimizations.

Practice

1. Which component is essential in an inventory management system to keep track of all products and their details?

easy

A. Product catalog

B. User authentication

C. Payment gateway

D. Notification service

Solution

1. Step 1: Understand the role of components in inventory management

   The product catalog stores all product details like name, ID, and description.

2. Step 2: Identify the component that tracks products

   Only the product catalog directly manages product information essential for inventory.

3. Final Answer:

   Product catalog -> Option A

4. Quick Check:

   Product catalog = Tracks products [OK]

Hint: Product catalog holds product info, key for inventory [OK]

Common Mistakes:

• Confusing payment gateway with product tracking
• Thinking user authentication manages products
• Assuming notification service stores product data

2. Which of the following is the correct way to represent a stock update transaction in an inventory system?

easy

A. {"product_id": 101, "change": +5}

B. {"id": 101, "stock": "increase"}

C. {"product": 101, "update": "add"}

D. {"item": 101, "quantity": "plus"}

Solution

1. Step 1: Analyze the transaction format for clarity and correctness

   The transaction should clearly identify the product and the numeric change in stock.

2. Step 2: Compare options for proper keys and value types

   {"product_id": 101, "change": +5} uses clear keys and a numeric change (+5) which is standard for stock updates.

3. Final Answer:

   {"product_id": 101, "change": +5} -> Option A

4. Quick Check:

   Numeric change with product_id = Correct format [OK]

Hint: Use numeric change with product_id for stock updates [OK]

Common Mistakes:

• Using string values instead of numeric for stock change
• Using unclear keys like 'item' or 'update'
• Missing product identification key

3. Given this simplified flow: A product stock is 10 units. A transaction reduces stock by 3 units, then another adds 5 units. What is the final stock?

medium

A. 15 units

B. 12 units

C. 8 units

D. 10 units

Solution

1. Step 1: Apply the first transaction reducing stock

   Starting stock is 10 units. Reducing by 3 units gives 10 - 3 = 7 units.

2. Step 2: Apply the second transaction adding stock

   Adding 5 units to 7 units results in 7 + 5 = 12 units.

3. Final Answer:

   12 units -> Option B

4. Quick Check:

   10 - 3 + 5 = 12 [OK]

Hint: Add and subtract transactions stepwise to find final stock [OK]

Common Mistakes:

• Adding before subtracting stock
• Ignoring one of the transactions
• Confusing initial stock with final stock

4. In an inventory system, a stock update transaction sometimes fails to update the stock count correctly. Which is the most likely cause?

medium

A. Missing transaction logging

B. User interface color mismatch

C. Race condition on stock updates

D. Incorrect product catalog data

Solution

1. Step 1: Understand common causes of incorrect stock updates

   Race conditions happen when multiple updates happen simultaneously without proper locking.

2. Step 2: Identify the cause that directly affects stock count accuracy

   Race condition can cause lost updates, leading to incorrect stock counts.

3. Final Answer:

   Race condition on stock updates -> Option C

4. Quick Check:

   Race condition = Incorrect stock update [OK]

Hint: Concurrent updates need locking to avoid race conditions [OK]

Common Mistakes:

• Blaming UI issues for backend stock errors
• Ignoring concurrency problems
• Assuming logging affects stock accuracy

5. You design an inventory system for a large retailer with thousands of products and frequent stock changes. Which design choice best ensures scalability and accuracy?

hard

A. Use manual stock updates by warehouse staff only

B. Use distributed caches with eventual consistency for stock counts

C. Use a centralized database with strong locking for all stock updates

D. Use event-driven architecture with message queues and atomic updates

Solution

1. Step 1: Consider scalability and accuracy needs

   Large scale with frequent updates requires a system that handles concurrency and scales well.

2. Step 2: Evaluate design options for best fit

   Event-driven architecture with message queues allows asynchronous, atomic updates and scales horizontally.

3. Final Answer:

   Use event-driven architecture with message queues and atomic updates -> Option D

4. Quick Check:

   Event-driven + atomic updates = Scalable & accurate [OK]

Hint: Event-driven with atomic updates scales best for inventory [OK]

Common Mistakes:

• Choosing centralized locking which limits scalability
• Relying on eventual consistency causing stock errors
• Using manual updates which are slow and error-prone