Beginner: Centralized Solution
Last updated
Last updated
This is suitable for companies small to medium scale with fewer warehouses. In this centralized system, all the operations will go through a single inventory service. Stock levels and updates will be transacted atomically, reducing risk of overselling.
High Level Components:
Inventory service: Core microservice to manage stock levels, real-time updates , track multiple warehouses and also to ensure cache invalidation during stock updates.
Order Service: Handles orders and ensures stock reservation.
Notification Service: Alerts for low stock and reorder triggers.
Worker service ( supply chain ): Tracks incoming shipments and adjusts stock accordingly.
Database: Use , (AWS), (Azure), (Google).
Message Queue: This is to handle stock changes during purchase, on return, on cancellation. (Kafka)
Prometheus & Grafana: To monitor inventory trends and track stock outs / over selling incidents. You can also use for reports.
Scaling Considerations:
Horizontal scaling based on traffic.
Partition database based on the inventory to avoid hotspots.
Centralize the access control via api gateway to handle rate limiting and request throttling.
How does the above system work for the above functional requirement ?
It should track real-time inventory updates for products across multiple warehouses and locations.
Central inventory service ensures all the stock updates from multiple warehouses and updated in real time. Whenever a stock change occurs, due to orders, returns, or incoming shipments, service updates the stock levels in the database and sends out the necessary notifications or updates through the message queue.
On Purchase: Decrement available stock, increment reserved stock
On Return: Increment available stock
On Cancellation: Decrement reserved stock, increment available stock
On Shipment: Decrement reserved stock
It should support product variants like size and color.
Inventory service keeps track of all the granular information about the product. When an order is placed, the system ensures that the specific variant is reserved in the correct quantity. The database schema is designed to handle variants as part of the product record, ensuring that all different options are individually tracked.
Order Service can handle the specific variant selected by the customer, ensuring that the correct variant stock is decremented.
It should handle high traffic and concurrent transactions.
System supports horizontal scaling through the use of microservices. As traffic increases, the system can add more instances of each service - Inventory Service, Order Service to manage the increased load.
Message queue helps in managing concurrent stock updates efficiently. When multiple transactions happen simultaneously, the message queue ensures that stock updates are processed in a fault-tolerant manner, preventing issues like overselling or race conditions.
This will still have some latency, to avoid that we should use gRPC for faster communication between services.
It should provide low-stock notifications and automatic reorder triggers.
Inventory service monitors stock levels continuously. When stock drops below a certain threshold, it triggers low-stock notifications.
Notification service helps to send the notification to the warehouse managers for low stock and to reorder triggers.
It should generate accurate inventory reports and forecasts.
With Prometheus, Grafana and analytical service it aggregates the data from the inventory service and generates the reports. Analytical service ensures data is up to date and ensures accuracy.