System Requirements

Functional

1. Inventory Tracking
   1. Users can add, update and delete items in the inventory
   2. Each item includes additional information along with it, product name, description, SKU, price, quantity, location and supplier information
2. Stock Replenishment
   1. Users receive notifications for parts running low on stock
   2. Users can set up replenishment systems that order products as soon as an item runs low on stock
   3. Replenishment orders can be placed automatically or manually
3. Order Fulfillment
   1. Users can process customer orders
   2. Inventory levels are updated in real time as orders are processed in real time
   3. Features include order processing, shipping and tracking
4. Real Time Inventory Updates
   1. Inventory figures are updated in real time. This facilitates in accurately processing orders
5. Automated Stock Alert
   1. Alerts for the system can be sent via email, SMS etc.
6. Reporting and Analytics
   1. Users have access to reporting and analytics dashboard
   2. Data visualization tools are used to present actionable insight to users

Non-Functional

1. Scalability
   1. System should be able to handle growing volume of inventory and increasing orders
   2. All components should be stateless and thus, be available for horizontal scaling
2. Performance
   1. The system should be highly performant and should have low latency for all processed transactions
3. Reliability
   1. Inventory data should never be lost
   2. Redundancy measures must be put in place to make sure data is not lost in case of a failure
4. Security
   1. All data should be encrypted when stored and while in transmission
5. Compliance
   1. The system needs to comply with regional regulatory requirements

Capacity Estimation

User Base:

• Number of Users: We assume an average of 50 concurrent users accessing the system at any given time. These users could include warehouse staff, inventory managers, sales team members, and administrators.

Transaction Volume:

• Average Transactions: Considering the operations involved in inventory management, we estimate an average of 500 transactions per hour. These transactions include updating inventory levels, processing orders, generating reports, and managing stock alerts.

Data Storage:

• Initial Data Volume: We assume an initial data storage requirement of around 100,000 product items with associated details such as SKU, description, price, supplier information, and inventory levels.
• Growth Rate: We estimate a growth rate of 10% per month in data volume to account for the addition of new products and increased transaction history.

API Calls:

• Average API Calls: We assume an average of 100 API calls per minute for real-time updates, order processing, and integration with sales channels.

Peak Traffic:

• Peak Usage: We identify peak traffic during specific time periods, such as a 2x increase in transactions during sales promotions or seasonal peaks.

System Response Time:

• Response Time Target: We aim for an average response time of under 1 second for most user interactions within the system.

Redundancy and Scalability:

• Scalability Planning: We plan for scalability to accommodate a 20% increase in users and transaction volume over the next year.

Performance Metrics Definition:

1. Response Time: Aim for an average response time of under 1 second for most user interactions.
2. Throughput: Target an average of 500 transactions per hour.
3. Error Rate: Aim for a minimal error rate, ideally less than 1%.

Workload Characterization:

1. Transaction Types: Inventory updates, order processing, report generation, and API calls for real-time updates and integration.
2. Peak Usage Scenarios: Seasonal peaks, sales promotions, and increased activity during specific time periods.

Resource Estimation:

1. CPU and Memory: Estimate CPU and memory resources based on the expected workload and concurrent user connections.
2. Storage: Estimate storage requirements for storing product details, transaction logs, and historical data.
3. Network Bandwidth: Estimate network bandwidth for handling API calls, data transfers, and integration with external systems.

Scalability Planning:

1. Horizontal Scaling: Plan for horizontal scaling to accommodate future growth and handle peak traffic loads.
2. Redundancy: Implement redundancy and failover mechanisms for high availability and fault tolerance.
3. Elasticity: Ensure the system can dynamically scale up or down based on demand to optimize resource utilization

API Design

1. Inventory Management
   1. /inventory/items Gets item information or information on a list of items present in the inventory. Also, lets you add items to the inventory
   2. /inventory/:itemID Updates or deletes an item from the inventory
2. Stock Replenishment
   1. /replenishment/automate Lets the user automate the reorder of items. Item IDs are provided to the API in the form of a JSON
   2. /replenishment/order Lets the user create, fetch or update replenishment orders
3. Order Fulfillment
   1. /orders Manages order processing, shipping and tracking
   2. orders/:orderID/status Fetches the current status of an order
4. Reporting
   1. /report Generates various reports and analytics based information

Database Design

classDiagram class Users { # id: int + name: string + age: string + contactnum: string + add() + update() } class Stocks { # id: int + name: string + number: string + details: string + addStock() + updateStocks() } class Sales { # id: int + details: string + date: string + transaction: string + create() + update() } class Transaction { # id: int + name: string + details: string + date: string - confirmation: string + create() + update() } class Products { # id: int + name: string + price: string + details: string + create() + update() } class Suppliers { # id: int + name: string + address: string + contacts: string + create() + update() } class Admin { - username: string - password: string } class Customer { + address: string + transaction: string + details: string + createTransaction() + updateTransaction() } Sales --|> Transaction Customer --|> Users Admin --|> Users Admin --|> Stocks Customer --|> Sales Customer --|> Transaction Transaction --|> Products Products --> Suppliers Admin <--> Suppliers

1. Since we want to enforce a very high degree of consistency and because our data is structures, we opt for a relational database
2. All data in our system is highly normalized
3. We want a relational database that works well with deadlocks

High-Level Design

graph LR; UserInterface --> |HTTP Requests| ApplicationServer; ApplicationServer --> |Queries| Database; Database --> |Data Retrieval| ApplicationServer; ApplicationServer --> |Updates| InventoryManagementModule; ApplicationServer --> |Order Requests| OrderProcessingModule; ApplicationServer --> |Data Analysis requests| ReportingAnalyticsModule; ApplicationServer --> |Data Exchange| IntegrationLayer; ApplicationServer --> |User Authentication| AuthModule;

Request Flows

In this refined sequence diagram:

• Each action performed by the user corresponds to interactions with specific modules such as Authentication, Inventory, Orders, and Stock
• The User Interface module orchestrates the interactions between the user and the respective modules
• Each module handles its specific functionality, such as authentication, inventory management, order processing, and stock management.
• The sequence concludes with the successful logout of the user from the system

sequenceDiagram participant User participant UserInterface participant AuthModule participant InventoryModule participant OrderModule participant StockModule User->>UserInterface: Login activate UserInterface UserInterface->>AuthModule: Authenticate activate AuthModule AuthModule-->>UserInterface: Authentication Successful deactivate AuthModule UserInterface-->>User: Login Successful User->>UserInterface: Check Inventory activate UserInterface UserInterface->>InventoryModule: Retrieve Inventory Data activate InventoryModule InventoryModule-->>UserInterface: Inventory Data deactivate InventoryModule UserInterface-->>User: Display Inventory User->>UserInterface: View Pending Orders activate UserInterface UserInterface->>OrderModule: Retrieve Pending Orders Data activate OrderModule OrderModule-->>UserInterface: Pending Orders Data deactivate OrderModule UserInterface-->>User: Display Pending Orders User->>UserInterface: View Shipped Orders activate UserInterface UserInterface->>OrderModule: Retrieve Shipped Orders Data activate OrderModule OrderModule-->>UserInterface: Shipped Orders Data deactivate OrderModule UserInterface-->>User: Display Shipped Orders User->>UserInterface: Add New Stock activate UserInterface UserInterface->>StockModule: Enter Stock Details activate StockModule StockModule->>StockModule: Update Inventory StockModule-->>UserInterface: Stock Added Successfully deactivate StockModule UserInterface-->>User: Stock Added Successfully User->>UserInterface: Logout activate UserInterface UserInterface->>AuthModule: Logout activate AuthModule AuthModule-->>UserInterface: Logout Successful deactivate AuthModule deactivate UserInterface UserInterface-->>User: Logout Successful

Detailed Component Design

1. Authentication Module:

The Authentication Module is responsible for validating user credentials and managing user sessions securely. It consists of a User Authentication Service and Session Management component.

Responsibility: The User Authentication Service validates user credentials against stored records in the database, ensuring only authorized users gain access. Session Management tracks user sessions and generates access tokens using JSON Web Tokens (JWT) for secure communication between the client and server.

Technologies such as Node.js with Express and Passport.js are used for implementing the Authentication Service, while JWT is utilized for session management.

User roles and permissions management is crucial for ensuring proper access control and segregation of duties within the Inventory Management System. Let's elaborate on how different types of system users, such as warehouse staff, managers, and administrators, can be managed effectively:

1. Warehouse Staff:

• Role Description: Warehouse staff are responsible for day-to-day operations such as managing inventory, fulfilling orders, and updating stock levels.
• Permissions:
  • Read access to inventory data for checking stock levels and item details.
  • Write access to update stock levels, mark items as received, and process orders.

2. Managers:

• Role Description: Managers oversee warehouse operations, monitor inventory performance, and make strategic decisions regarding stock management.
• Permissions:
  • Read and write access to inventory data for monitoring and making adjustments.
  • Access to reporting and analytics tools for analyzing inventory turnover, stock accuracy, and supplier performance.

3. Administrators:

• Role Description: Administrators have full control over the system, including user management, configuration settings, and system maintenance.
• Permissions:
  • Full access to all system functionalities, including user management, configuration settings, and system administration.

Technologies:

• RBAC can be extended to include administrative roles with superuser privileges for managing users, roles, and permissions.
• Access control mechanisms such as access control lists (ACLs) can be implemented to enforce additional security policies for administrative actions.

2. Inventory Module:

The Inventory Module handles the management of inventory items within the system. It includes components for managing inventory data, stock alerts, and stock level adjustments.

Responsibility: The Inventory Database stores inventory-related information such as product details, stock levels, and supplier information using a relational database like SQL Server. The Inventory Management Service implements business logic for inventory operations, ensuring accurate tracking of stock levels and handling stock replenishment. Microservices architecture can be utilized for scalability and modularity in the Inventory Module.

3. Order Module:

The Order Module is responsible for processing customer orders and managing order fulfillment. It encompasses components for managing order information, processing orders, and updating inventory levels.

Responsibility: The Order Database stores order details, customer information, and shipping details using a relational database like MySQL. The Order Processing Service orchestrates order processing workflows, interacting with inventory and shipping systems to ensure timely fulfillment.

Technologies such as Python with Flask can be employed for developing the Order Processing Service, providing a robust and scalable solution.

4. Stock Module

The Stock Module is tasked with managing stock levels, tracking stock movements, and handling stock replenishment. It comprises components for managing stock data and implementing stock management operations.

Responsibility: The Stock Database stores stock-related data, including stock levels, movements, and replenishment history, utilizing a NoSQL database like MongoDB for flexibility and scalability. The Stock Management Service implements business logic for stock management operations and generates stock alerts using Go for concurrent processing and real-time monitoring

5. Reporting & Analytics Module:

The Reporting & Analytics Module generates insights and reports on inventory turnover, stock accuracy, and supplier performance. It consists of components for storing historical data and processing analytics.

Responsibility: The Reporting Database stores historical data for generating reports and analytics, leveraging technologies like Amazon Redshift for data warehousing and analytics. The Analytics Engine processes data to generate insights and visualizations, utilizing Apache Spark for distributed data processing and visualization. Micro-service architecture can be employed for scalability and modular development in the Reporting & Analytics Module.

Trade offs/Tech Choices

1. For our relational database, we use MySQL since it offers a high degree of consistency along with the ability to handle race conditions well
2. For our messaging queue, we use Apache Kafka

Failure Scenarios/Bottlenecks

Future Improvements

1. Employ machine learning models to find out the optimal range of quantity for parts, cutting on overstocking costs and preventing cases where we are unable to place an order due to insufficient stock. We can use an algorithm like Prophet for this case