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