Design a low-latency Inventory Management System

Question

Design a low-latency inventory management system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Real-time Inventory Tracking**: The system must provide immediate updates to inventory levels when items are added or removed.
2. **Multi-user Support**: Multiple users should be able to access and modify inventory data concurrently without conflicts.
3. **Search and Filter**: Users need to search for items and filter results based on various attributes (e.g., category, stock level).
4. **API Access**: A RESTful API should be available for external integrations, allowing third-party systems to access inventory data.

### Non-Functional Requirements
1. **Low Latency**: The system should respond to requests in under 100ms to ensure a seamless user experience.
2. **High Availability**: The system should maintain 99.9% uptime to ensure continuous access to inventory data.
3. **Scalability**: The architecture should handle millions of requests per second as the user base grows.
4. **Data Consistency**: Strong consistency is required for inventory levels to avoid overselling.

Assuming Figma serves around 1 million users, with an average of 10 requests per user per day, we can estimate:

- **Total Requests Per Day**: 1,000,000 users * 10 requests = 10,000,000 requests/day.
- **Requests Per Second (QPS)**: 10,000,000 requests/day / 86400 seconds = ~115.74 QPS.
- **Peak Load**: During peak times, we can assume a 5x increase in traffic, leading to ~579 QPS.
- **Storage Needs**: If we assume an average of 1 KB per inventory item and expect to manage 10 million items, we would need approximately 10 GB of storage.
- **Bandwidth**: With an average of 1 KB per request and peak load of 579 QPS, we would require ~579 KB/s bandwidth during peak times.

The architecture consists of:
1. **API Gateway** (e.g., AWS API Gateway or NGINX): Routes requests and handles rate limiting.
2. **Load Balancer** (e.g., AWS ELB): Distributes incoming traffic to multiple application servers.
3. **Application Servers** (e.g., Node.js or Go): Handle business logic and interact with the database.
4. **Distributed Database** (e.g., CockroachDB or Cassandra): Stores inventory data with horizontal scaling and strong consistency.
5. **Caching Layer** (e.g., Redis): Caches frequently accessed data to reduce database load and improve latency.
6. **Monitoring and Logging** (e.g., Prometheus, Grafana for monitoring and ELK stack for logging): Tracks system performance and alerts on anomalies.

This architecture supports scalability, fault tolerance, and real-time performance.

The primary schema for the inventory items could look like:

```sql
CREATE TABLE Inventory (
    item_id SERIAL PRIMARY KEY,
    item_name VARCHAR(255) NOT NULL,
    quantity INT NOT NULL,
    category VARCHAR(100),
    last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
```

### Access Patterns
- **Read Operations**: Frequently access item details; therefore, caching item data in Redis can minimize database hits.
- **Write Operations**: Updates to inventory levels must ensure consistency to prevent overselling, using transactions.
- **Search Operations**: An inverted index can be maintained for common search attributes to speed up search queries.

1. **Consistency vs. Availability**: Given the need for strong consistency in inventory levels, we choose a CP (Consistency and Partition tolerance) approach using a distributed database like CockroachDB. This ensures accurate inventory counts but may affect availability during partition scenarios.
2. **Caching Strategy**: Using Redis for caching improves performance but introduces complexity in invalidating stale data. We can implement a TTL (Time-to-Live) strategy for cache entries to balance freshness and performance.
3. **Sharding and Partitioning**: We will shard the database based on item category to balance load and improve query performance, but this adds complexity in query routing and management.
4. **API Rate Limiting**: To prevent abuse and maintain performance, we will implement rate limiting at the API Gateway level, which could affect users during high traffic but is essential for system stability.

Design a low-latency Inventory Management System

Figma

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Functional Requirements

Capacity Estimation

Submit Your Answer

Figma Software Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search