Inventory management in LLD - System Design Exercise

Design: Inventory Management System

Includes product and warehouse management, stock tracking, alerts, and query APIs. Excludes order processing, payment, and shipping logistics.

Functional Requirements

FR1: Track stock levels for multiple products across multiple warehouses

FR2: Support adding new products and warehouses

FR3: Update stock quantities on product purchase, return, or restock

FR4: Provide real-time stock availability queries

FR5: Generate alerts when stock for any product falls below a threshold

FR6: Support concurrent updates without data loss or inconsistency

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent users querying stock

NFR2: API response time p99 under 200ms for stock queries

NFR3: System availability 99.9% uptime

NFR4: Data consistency for stock updates 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

Inventory Service to handle stock logic

Database for storing product, warehouse, and stock data

Cache layer for fast stock queries

Alerting service for low stock notifications

Message queue for handling asynchronous updates

Design Patterns

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

Event sourcing for tracking stock changes

Caching strategies to reduce database load

Distributed locking or transactions for concurrency control

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
Authentication Service
  |
  v
Inventory Service <--> Cache Layer
  |
  v
Database
  |
  v
Alerting Service
  
Message Queue (for async stock updates and alerts)

Components

API Gateway

Nginx or AWS API Gateway

Handle client requests, route to services, enforce rate limiting

Authentication Service

OAuth 2.0 / JWT

Authenticate users and authorize access to inventory APIs

Inventory Service

Node.js / Python microservice

Process stock updates, queries, and business logic

Database

PostgreSQL

Store product, warehouse, and stock data with strong consistency

Cache Layer

Redis

Cache stock levels for fast read access

Alerting Service

Custom microservice or AWS SNS

Send notifications when stock falls below threshold

Message Queue

RabbitMQ or AWS SQS

Handle asynchronous stock update events and alert triggers

Request Flow

1. Client sends stock query or update request to API Gateway

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

3. Authenticated requests reach Inventory Service

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

5. If cache miss, Inventory Service queries Database and updates cache

6. For stock updates, Inventory Service writes to Database within transaction

7. Inventory Service publishes stock update event to Message Queue

8. Alerting Service consumes events from Message Queue to check thresholds

9. Alerting Service sends notifications if stock is low

Database Schema

Entities: - Product (product_id PK, name, description, category) - Warehouse (warehouse_id PK, location, name) - Stock (stock_id PK, product_id FK, warehouse_id FK, quantity, last_updated) Relationships: - Product to Stock: 1 to many - Warehouse to Stock: 1 to many Stock table stores current quantity per product per warehouse.

Scaling Discussion

Bottlenecks

Database write contention on stock updates

Cache invalidation and consistency challenges

Message queue overload with high update volume

API Gateway rate limiting under heavy load

Solutions

Use database sharding by warehouse or product to distribute writes

Implement cache with TTL and write-through or write-back strategies

Scale message queue horizontally and partition topics

Deploy multiple API Gateway instances with load balancing

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 consistency needs and scale targets early

Explain choice of database for strong consistency

Describe caching strategy to meet latency goals

Discuss concurrency control to prevent overselling

Highlight asynchronous alerting for scalability

Mention how to handle failures and retries