Inventory management in HLD - System Design Exercise

Design: Inventory Management System

Includes product catalog, stock tracking, user management, and alerting. Excludes order processing and payment systems.

Functional Requirements

FR1: Track stock levels of products in multiple warehouses

FR2: Support adding new products and updating product details

FR3: Allow recording stock movements: incoming shipments, sales, returns

FR4: Provide real-time stock availability queries

FR5: Generate alerts when stock falls below a threshold

FR6: Support user roles: admin, warehouse staff, and sales team

FR7: Maintain audit logs for stock changes

Non-Functional Requirements

NFR1: Handle up to 100,000 products and 50 warehouses

NFR2: Support 500 concurrent users with p99 API latency under 200ms

NFR3: Ensure 99.9% system availability

NFR4: Data consistency for stock levels must be strong to avoid overselling

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway for client requests

Authentication and Authorization service

Product and Inventory database

Cache layer for fast stock queries

Message queue for processing stock updates asynchronously

Alerting service

Audit logging system

Design Patterns

CQRS (Command Query Responsibility Segregation) for separating reads and writes

Event sourcing for audit logs and stock changes

Cache aside pattern for stock data caching

Role-based access control (RBAC)

Reference Architecture

Client Apps
   |
API Gateway
   |
Auth Service --- User DB
   |
Inventory Service --- Product DB
   |          
   |          
Cache Layer   Message Queue
   |          |
Alert Service Audit Log Service

Components

API Gateway

Nginx or AWS API Gateway

Route client requests to appropriate services and handle rate limiting

Authentication and Authorization Service

OAuth 2.0 / OpenID Connect

Verify user identity and enforce role-based permissions

Inventory Service

RESTful API with Node.js or Java Spring Boot

Handle product and stock operations, business logic

Product and Inventory Database

PostgreSQL

Store product details, stock levels, and warehouse info

Cache Layer

Redis

Cache frequently accessed stock data for low latency queries

Message Queue

RabbitMQ or Kafka

Process stock updates asynchronously to maintain consistency

Alert Service

Custom microservice with email/SMS integration

Send notifications when stock is low

Audit Log Service

ElasticSearch or centralized logging

Record all stock changes for traceability

Request Flow

1. User sends request to API Gateway

2. API Gateway forwards request to Authentication Service for user validation

3. Upon success, request goes to Inventory Service

4. For stock queries, Inventory Service first checks Cache Layer

5. If cache miss, Inventory Service queries Product DB and updates cache

6. For stock updates, Inventory Service writes to Product DB and publishes event to Message Queue

7. Message Queue triggers Alert Service if stock below threshold

8. Audit Log Service records all stock changes asynchronously

Database Schema

Entities: - Product (product_id PK, name, description, category, price) - Warehouse (warehouse_id PK, location, capacity) - Stock (stock_id PK, product_id FK, warehouse_id FK, quantity) - User (user_id PK, username, password_hash, role) - StockMovement (movement_id PK, stock_id FK, change_quantity, movement_type, timestamp, user_id FK) Relationships: - Product to Stock is 1:N (one product can have stock in many warehouses) - Warehouse to Stock is 1:N - User to StockMovement is 1:N - StockMovement records each stock change event

Scaling Discussion

Bottlenecks

Database write contention when many stock updates happen simultaneously

Cache invalidation complexity leading to stale stock data

Message queue overload with high volume of stock events

Alert service delays when many alerts trigger at once

Solutions

Use database sharding by warehouse or product category to distribute writes

Implement cache aside pattern with short TTL and event-driven cache invalidation

Scale message queue horizontally and partition topics by warehouse

Rate-limit alerts and batch notifications to reduce load

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Clarify functional and non-functional requirements upfront

Explain choice of technologies and how they fit requirements

Describe data flow clearly emphasizing consistency and latency

Discuss how caching improves read performance and how to keep cache fresh

Highlight audit logging importance for traceability

Address scaling challenges with practical solutions

Show understanding of user roles and security

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