How to Build a Scalable Inventory Management System (With Architecture)

"Do you have another one of these? Can you check the stock?"
This customer question has been a headache for retail employees for as long as retail itself has existed.

But a question that was once easy (if annoying) to answer has become extremely difficult in the digital age. With online and offline shoppers mixing together and pulling products from retail shelves and digital shelves in real time, it's not easy to know exactly what stock you have and where it is. Even online-only e-commerce stores sometimes struggle to build an effective inventory management system.

So why is inventory management so difficult? Let's take a look at how to design an effective, reliable system.

1. Overall Inventory Management Reference Architecture

So how do successful retailers achieve inventory management? Let's start by looking at an overview example. This anonymized diagram is based on the actual architecture of an online and offline retailer with annual revenue in the billions of dollars.

In the diagram, the purple rectangles arranged horizontally in the center represent the online shopper's actions, from login to purchase. The cylinders represent databases, of which there are four.

・The customer database, which stores information about users. It includes tables such as PII (Personally Identifiable Information), order history, and browsing history.

・The inventory database, which stores all metadata related to product stock. It has tables including SKU descriptions, product availability, and stock location. This is the source-of-truth database for inventory management.

・The image database, which stores product images. It holds the product images displayed on product description pages (PDP), customer search results, and so on.

・The database or API that provides product specifications to the PDP. This data typically comes from a third-party provider, and the retailer itself may not track or manage it.

Let's take a closer look at the user's purchase flow.

1. When a user logs in, the application needs to query the customer database.
2. When a user views a product detail page (PDP), the application needs to query the inventory database (stock status, product description, etc.), the customer database (recommendations, user-specific information, etc.), the image database, and the product specification database.
3. When a user adds a product to their cart, how it's handled is up to the system architect, but a common approach is to temporarily mark the item as sold out (temporarily reducing stock) and hold it until the sale completes or a timer expires. If the sale completes successfully before the timer expires, the item is permanently removed from inventory. If the sale doesn't complete, the item is removed from the user's cart and marked available again in the inventory database.
4. When a user proceeds to checkout, the application needs to query the customer database to display the relevant user information.
5. Whether or not the user completes the purchase, the inventory database permanently reflects the stock changes described in step 3.

This may seem like a relatively simple process, but achieving this kind of flow while maintaining consistency at scale requires choosing the right tools. A lack of consistency at scale has led to products being oversold, damaging the customer experience.

2. Steps to Develop an Inventory Management System

The timeline and approach for designing and developing an inventory system depend on the specific inventory operations to be solved and their scale. Below, we explain the steps that we at Miichisoft typically take when implementing robust inventory management software.

2.1. Defining Requirements for the Inventory Management System

Duration: 4 weeks

Miichisoft begins an inventory management system implementation project with the following steps. We clarify the functional and non-functional requirements of the inventory management system, and define user roles, the necessary integrations with other systems (ERP, CRM, accounting systems, etc.), and data migration activities (migrating data from spreadsheets or inventory management solutions currently in use).

We determine the type of inventory management system: software-only, or one that supports barcode/RFID. We select the software technology. If needed, we create a list of the required hardware devices. We design a high-level architecture of the solution with its key components and how they interact. We create a UI prototype.

2.2. Project Planning

Duration: 1–2 weeks

Our experts at Miichisoft firmly believe that accurate project planning is the foundation of a successful inventory system implementation. This stage covers the following items.

・An overview of the scope and duration of the work, along with the associated risks and how to mitigate them.

・Calculating the expected Total Cost of Ownership (TCO) and Return on Investment (ROI) of the inventory system.

・Defining the milestones, goals, and Key Performance Indicators (KPIs) of the inventory system implementation project.

2.3. Developing the Inventory System

Duration: 4–6 months

At this stage, Miichisoft carries out the following work.

・Delivering the backend of the inventory solution, which integrates and processes inventory data uploaded by users, as well as inventory data generated by tracking devices (for barcode/RFID-enabled systems). This triggers data-driven actions that automate inventory operations.

・Delivering the web and mobile applications that users interact with.

・(Optional) Optimizing the inventory management process by implementing a machine-learning-based demand forecasting module.

・Running pre-production quality assurance procedures to verify the quality of the inventory software and fix bugs.

2.4. Integrating With Other Systems

Duration: 1–12 weeks

At this stage, the Miichisoft team finalizes the integration patterns and procedures defined during the inventory system's design phase. We implement and test integrations with other business-critical systems (e.g., ERP, accounting, CRM) and with Business Intelligence (BI) tools for reporting and visualizing inventory-related data.

2.5. Migrating Inventory Data

Duration: Depends on migration complexity

・For data migration from inventory management software or spreadsheets, Miichisoft provides support through the following steps.

・Developing migration scenarios and creating the scripts used to automate the migration and the data mapping.

Extracting inventory data from legacy inventory management systems or spreadsheets, verifying its quality, and identifying and resolving issues (e.g., lost or corrupted data).

・Loading the data into the dedicated inventory database and running data validation procedures to ensure data accuracy and consistency.

2.6. Deploying the Inventory Management System

Duration: From month 3 onward

At Miichisoft, deployment of the inventory management system typically takes place in the following stages.

Stage 1. Setting up the software infrastructure and configuring backup and disaster recovery procedures. Installing and adjusting hardware as needed (e.g., barcode printers and readers, RFID tags and readers). Deploying the solution to one of the target facilities (warehouse/distribution center) for a pilot run. For systems that require hardware support, this takes 2 weeks.

Stage 2. Monitoring the system's functionality in a live environment. Handling change requests and issues (e.g., related to barcode/RFID). The pilot run lasts 1–2 months.

Stage 3. Deploying the final version of the solution to all target facilities. Deploying an RFID/barcode-based system takes about 2 months (the duration may vary depending on the number of facilities and the complexity of their layout).

2.7. Training Users

Duration: 2–4 weeks

At Miichisoft, we take the following steps so that employees involved in inventory-related work can quickly put the solution to use in their daily tasks.

・Drawing up a plan to integrate the new inventory system into the workflows of employees (inventory management and procurement specialists, warehouse workers, etc.).

・Creating administrator guides and user tutorials for the software and hardware.

・Conducting workshops for the relevant user groups (e.g., warehouse staff who label inventory items in the new system).

2.8. Post-Release Support, Maintenance, and Evolution

Duration: Depends on your requirements

Miichisoft offers a variety of services to keep the inventory system running smoothly over the long term. These services include the following:

・Providing ongoing user support.

・Carrying out planned system updates and feature expansions based on business growth and user feedback — for example, adding new types of inventory reports or improving the UI.

・For systems that support barcode/RFID, fixing hardware defects and performing hardware maintenance (in cooperation with hardware vendors). This specifically includes device servicing (such as repairing RFID readers) and the timely supply of consumables (such as RFID tags).

3. What Are the Technical Challenges of Inventory Management?

Challenge #1: Consistency

One of the biggest technical challenges in inventory management is maintaining real-time consistency. This is especially critical at large scale, since a lack of consistency can cost a company money and damage its reputation.

For example, if a product runs out of stock during a Black Friday sale and a company's e-commerce site doesn't immediately reflect that, dozens, hundreds, or even thousands of customers could end up purchasing a product that doesn't exist.

To prevent this, you need a source-of-truth inventory database that can stay in sync with the various application services that require inventory data. You can sell inventory down to zero, but you can't sell past zero — and building and maintaining a system like this isn't easy, especially since it must maintain high performance even under heavy load.

Challenge #2: Scalability

Retail trends aren't always predictable. But even when they are, you need the ability to scale quickly (up or down) in order to maintain high-performance infrastructure without overspending.

In other words, you should build a system that can handle massive traffic like Black Friday, while avoiding paying to handle "Black-Friday-level" traffic on some random Tuesday in January.

Challenge #3: Latency

To reduce latency and improve the customer experience, it makes sense to place customer-related data in a database close to their geographic location. However, splitting the database geographically can make it harder to maintain consistency (as we'll explain in more detail later), since you need to maintain consistency across the different regional database shards.

Challenge #4: Product Complexity

So far, we've mainly used sales as an example, but inventory management is about more than simply tracking whether a product has sold. Products may move from warehouse to warehouse. They may get lost or damaged. Some products may expire.

There's also the ambiguous period of a "product in the cart." During this period, a specific unit of stock hasn't been sold yet, but it's not necessarily available either. To maintain accurate inventory, you need to track every one of these factors.

Challenge #5: Usability

Solving all of the problems above is certainly possible, but many solutions are technically complex and require substantial investment — in engineering time, training, and more. This can create a variety of new problems, such as delays and higher-than-expected costs.

4. What Are the Technical Requirements of a Modern Inventory Management System?

The challenges above are really just the tip of the iceberg, but what should a company look for when choosing tools and designing its own inventory management solution?
A system like this needs to meet the following requirements.

・High availability: If a system goes offline at the wrong moment — even for just a few minutes — it can cost a company millions. An inventory management system must have high availability and be durable enough that data is never lost.

・Global consistency: The inventory management system must track the source of truth for product stock and be able to deliver that truth, in real time, to every application service that needs it — either directly or through solutions such as changefeeds.

・Flexible scaling: Every part of the retail backend, including inventory management, must be able to scale up or down easily to handle heavy load during peak sales periods. At the same time, it should minimize infrastructure costs during quiet periods to keep expenses down.

In addition, while these may not be strict requirements for every use case, an ideal inventory management system should also have the following characteristics:

・Geographically scalable: Placing data geographically enables a better customer experience (and in some cases, may also be a regulatory requirement).

・(Relatively) easy to use: Inventory management is never easy, but reducing system complexity and taking advantage of managed services wherever possible can help reduce the internal costs associated with building and managing the system.

Achieving these goals requires a combination of carefully chosen tools and a well-thought-out architecture.

5. Cost Factors for Implementing an Inventory System

The average cost of building an inventory management system ranges from 10 million to 30 million yen for mid-sized companies working with an offshore vendor, and from 20 million to 50 million yen for large enterprises.
*Costs may be higher if developed by a Japanese development company.

The main cost factors are as follows.

・The type of inventory system: software-only, or one using RFID/barcode technology (the latter includes hardware equipment costs and maintenance costs).
・The number and complexity of features in the inventory management software. For example, the complexity of inventory data analysis depends on the types of analysis required, whether and how many machine learning algorithms are used, the volume of data, and the number and complexity of reports.
・The number of user groups and the complexity of the user permissions system.
・The uniqueness and complexity of the interface design.
・The complexity of the required data migration process (e.g., based on the number of data tables and types of data).
・The number and complexity of integrations with other systems (ERP, accounting software, CRM, etc.).
・The system's requirements for availability, performance, security, capacity, and scalability.

6. Summary

Miichisoft is a software development provider headquartered in Vietnam. We have IT consultants at our Japanese entity, Miichisoft Japan, allowing us to provide one-stop support from the requirements definition stage all the way through development, testing, and operations.

Because we hold ISO 9001 and ISO 27001 certifications, we rely on a mature quality management system, and we guarantee that working with us poses no risk to your data security. For more details on our development approach, please check out our custom software development offering.

If you have any software development needs, please feel free to contact us.