Inventory status checks development and performance considerations

Accuracy with inventory is an important consideration. There are some native features that can help ensure that this risk is as low as possible such as back orders and setting the out of stock threshold. Both of those topics can be read on Adobe Experience League for further explanation.

There are projects and use cases where real time inventory status checks are requested for an Adobe Commerce store. This tutorial provides insight for handling this conversation with development and performance considerations.

Validate if this request is necessary

Prepare to discuss the request with as much information as possible. The most important thing to do is to verify that native functionality is not acceptable for this project. Find the reasoning behind this request to validate that the native capabilities of Adobe Commerce fail to fulfill this request.

Another consideration is the cost to develop, test, and maintain this feature. A stakeholder’s opinion does not necessarily make something a requirement. There are associated costs with doing inventory validation outside of the core functionality of Adobe Commerce. These costs come in the form of technical debt, more testing and validation as well as usage documentation and supporting documents for its architecture.

Determine what is an acceptable inventory update cadence

Try to consider inventory checks and how it is accomplished in 3 approaches. Each one has benefits and limitations. They also increase in complexity and require more testing and thought for error handling. Remember, when you decide to implement a custom solution, there are added responsibilities and considerations. Examples include a fallback process, monitoring, testing and troubleshooting, which fall to the development team. A few good items to include are new supporting documentation, training and monitoring to ensure that the development team can support the entire feature. A side effect is that the development team owns the process and no longer leverages the native functionality provided by the core Adobe Commerce application. Adobe support is unable to assist with this level of customization.

The first approach is using the native functionality. Using native functionality is the least amount of risk and has many benefits. Taking this approach means you can rely on all existing documentation and tutorials that Adobe Commerce provides for the use of the feature. There are many aspects to inventory management, so use what comes with the application as the first consideration. However, there are use cases where the data found in commerce at the time of the order is not accurate. An example of how data becomes unsynchronized is that sales are allowed outside the Adobe Commerce application directly in the Order Management system. A reason is that to ensure that the accurate inventory levels are represented in Adobe Commerce, it requires some sort of integration to keep the Adobe Commerce information as close to accurate as possible. If over-selling is not acceptable, then adding an out of stock threshold is a good method to stop the sale of items before you get to zero. The native sync functionality for Adobe Commerce is at a maximum of 1 time per day. This frequency is enough for some use cases, however it is not frequent enough for others. Please read Scheduled import and export for detailed information.

The second approach is near real-time. Near real-time still uses the native functionality. However, this includes some extra work to provide an integration that feeds commerce frequently to update its inventory on a schedule. For example, every hour. This option requires thought for how an integration works, but using the “bulk api” and having some middleware do the transformation of the data and push it to commerce is a great approach. Look at using Adobe App Builder or similar platforms to do the bulk of the work and push the information to Adobe Commerce on a more frequent cadence.

The third approach and the most complex with the most amount of risk and responsibility is real-time Live inventory checks to an external API or data source. Doing a real-time inventory check to an external system is risky and has several other elements that need to be considered. Here are a small set of other things that need to be evaluated:

Considerations for non-native inventory management

Keep the customizations as non-complex as possible.
How flat can the organization of the inventory be, is it 1 sku and the total amount of available stock OR are there other attributes that need to be considered.

If the inventory information is fairly flat, for example a sku and the total available quantity, the options for near-real-time are expanded. The concept of near real-time means that there is a background operation that gathers the inventory from the source, and then populates a storage engine to be used to respond to the request. For this you can use things such as Redis, Mongo, or other non-relational databases. These options are fast and work great for key/value pairs. If the data is a bit more complex, then using a relation database, either inside or outside the commerce application, is required. By offloading this from the commerce database, you keep the core commerce application isolated from these transactions. Another set of benefits are saving the I/O from the commerce application, CPU, RAM and others from use. To save resources from the Adobe Commerce application servers, take advantage of the new APIs to pull the data from the off site storage. This process requires a middleware to help transform any data. Then ensure that the calling application can get the result as expected. By using Adobe App Builder with API mesh the data can be transformed and returned properly formatted.

Using Adobe App Builder with API mesh is also a great option when there are multiple sources of inventory.

Move execution logic out of process

Adobe Developer App Builder provides a unified third-party extensibility framework for integrating and creating custom experiences to extend Adobe solutions. Adobe Commerce can use Adobe Developer App Builder. This approach is an excellent use case for extending some functionality that normally occurs in the core application and moves it off-site. By removing functionality from the Commerce application, this reduces the number of modules and complexity to the Commerce application. In turn, lower numbers of in-process customizations reduce the complexity for upgrading and maintenance.

For inspiration for how this task is accomplished, the team at Adobe has created some documentation that is a great source of inspiration and provides working code samples. When a shopper adds a product to the cart, a third-party inventory management system checks whether the item is in stock. If it is, allow the product to be added. Otherwise, display an error message. For code samples and further information go to Webhook Use Cases.

When to do inventory checks

When to check if inventory is still available is up to the business stakeholder, the software architect with some input from other key stakeholders. A few appropriate times include when adding an item to the cart and when entering the checkout workflow. Any other events add load to the backend systems when it is not necessary. Keep in mind that the goal is to catch an inventory issue only when it is paramount. Carefully consider other checks that impact the overall goal for inventory status checks, and only allow them if stakeholders are aware of the potential risk for extra load.

Research your inventory source

Comprehensive investigation of the external inventory source is required. Items that should be evaluated are available API options, support for GraphQL, and expected response times. If the inventory source has a limited connection bandwidth or was never intended to be used in a real time request, the ability for use is excluded and the architect needs to consider near-real-time instead. If the API request times exceed the defined parameters, it excludes this from being a viable option. An example of this behavior is api responses are 200 ms for one-time requests, but rise to 500 to 900 ms under moderate load. This situation gets worse with more load and rules out live inventory calls from being available.

Be sure to test the api response times with simple requests as well as with a high volume similar to the expected traffic on the live website. Remember to test all areas from commerce at the same time to simulate real world scenarios. If live inventory calls occur on product pages, in the cart, and during checkout, load testing must simulate all of these simultaneously to mimic real customer behavior.

Fallback options

If the inventory source is down and monitoring is available, using the native capability of Adobe Commerce is recommended. However, with proper monitoring the customer experience can dynamically change to reflect the loss of real time inventory checks. This means that a sale or event is canceled early or removed from display to avoid overselling. Discuss the fallback plan with the store owner so everyone understands the automatic process that takes over if the inventory source goes down.

Conclusion

The decision to do real-time inventory checks is a significant one. Ensuring that the website owner, development team, and others are fully educated and aware of all gains and potential pitfalls rest on the developer lead or architect. By providing a thoughtful plan that covers reasons and a fallback process is key to success.

Live inventory checks can be accomplished but requires research and thought around testing and validation during the QA cycle. Ensuring that load testing and end to end automated tests help ensure that all potential issues are caught and triaged.

If monitoring detects failed calls or slow response times, perform actions to keep the site online and minimize customer irritation. Fallback options range from using native functionality to disabling promotions, notifying the dev team, or re-routing requests to a secondary backend system. How the fallback mechanism is implemented should be as carefully planned as the actual integration because every system experiences issues at some point. Anything that is automated or needs manual action should be clearly documented.