Magento 2 brought with it new features, increased flexibility, and a new era of collaboration with the worldwide Magento developer community. In fact, the most substantial community-led project is also one of the most important and powerful features in Magento: the Magento Inventory project.
New inventory-related features & functionality were initially introduced in Magento 2.3 via the community-led MSI project. Eventually, the project evolved into the Magento Inventory project.
Modernizing Magento's inventory features has been a long, collaborative journey between Magento's developer community and Magento. It is worth highlighting the functional and performance changes in this project, as the biggest community-driven project in the Magento ecosystem. Inventory makes up 25% of Magento 2 codebase.
The Inventory project was released on 28 November of 2018 as a part of Magento 2.3.0. After its release, community opinion was divided: from one side, the community found the Inventory project to be a great example of Community- and Domain-Driven Developed Advanced Functionality. From the other perspective, it did not go far enough, as it did not cover some inventory-management scenarios and occasionally caused performance issues on some websites.
The new Magento 2.4.0 includes a powerful update of the Inventory project, which comes with dramatic improvements in performance. Even if your website has only one Default Stock and you do not use the Inventory project, it still replaces the Magento legacy inventory system, and more importantly, it offers an increase in website performance.
Full Support for bundle products
Product type support in Magento Inventory has been implemented over time. The initial release of Inventory in 2.3.0 supported only simple and configurable products. Support of grouped products was later added as was support for bundle products in only the Default Stock scope (legacy inventory). Magento 2.4 provides full multi-sourcing support for bundle products, which means all physical product types are now completely supported.
The In-Store Pickup feature - is one of the killer-features of a new release. You can read more about it in the article. Besides, there are user guides available in Magento Dev Docs: here and here. And, of course, a webapi documentation that describes REST and GraphQl support.
In addition to new features, the initial (2.3.0) release of the Inventory project did have some performance impacts for some websites. (These were largely addressed in the 2.4.0 release, with fixes and even more net improvements set for delivery.) The problem started with the replacement of the `getQty` method implementation. In Magento Inventory, the quantity is received by calling a service instead of fetching the value directly from the database. Legacy inventory represents salable quantity as a simple product’s attribute, but in the scope of Magento Inventory, it becomes a complex model with multiple factors that could impact it.
In some rare cases the new Magento Inventory becomes a solution which can not satisfy customer needs. In any way, we recommend to stay with a new inventory as it provides the following benefits without any drawbacks in most cases:
In other words, if you decide to stay on your Legacy Stock you are buying a ticket for a train which is going in the wrong direction. Sooner or later you will be forced to buy a new ticket and change to another train. But the cost of the new ticket will be much higher.
When considering performance of Magento 2.3 + Inventory (formerly MSI) versus current 2.4.0 + Inventory, merchants can expect to see the following improvements:
Impressive, yes? Let’s go deeper into details.
The main performance problem was caused by an `IsProductSalable` service (which is deprecated since 2.4 in favor of `AreProductsSalable` service): it is accurate but expensive (0.2s per call). It was called several times on the Product Details Page which slowed it down significantly, especially for composite products. In 2.4 the problem has been resolved.
What was changed?
The solution was a simple balancing of priorities: a hyper-accurate but expensive implementation has been replaced by a cheaper, slightly less accurate one which is pre-calculated asynchronously on Storefront areas (frontend, GraphQL). Each time a reservation is placed a new asynchronous indexer is executed that recalculates the product salability status accurately. To better illustrate this, consider the following example.
Consider a product with a quantity of 1, so it's the last one available. A customer places an order for this last item available in stock. In some period of time - usually from 1 second to 1 minute when the asynchronous indexer runs - the product becomes out of stock, and the changes will affect PLP (Products List Page) and other pages as well.
Generally, the idea of such an approach is taken from the old good CQRS approach using Event Sourcing.
In terms of the Inventory model, our Write data and Read data are represented with Sources and Stock Items, correspondingly. When a customer places an order he or she creates an event message - the reservation. With the old approach, Read data has been used only on the PLP page but PDP still used Source Items data and used to calculate correct quantity with applied reservations dynamically. The time gap between order placement and salability status recalculation on PLP could be quite long: only when the order is shipped. It is a side effect which provides great improvements.
The new approach provides two general things:
What to be aware of?
Experienced developers and business application stakeholders all know the fundamental truth that systems design is always about trade-offs. Even with this refined approach, there are still some ‘edge case’ scenarios that could lead to data inconsistency.
First of all, in the case when the last product was bought, a new approach will provide a delay before product status will be updated on product landing and product details pages. The time of delay will depend on how fast reservation changes will be applied to the product's stock data by the asynchronous operation.
The second problem is more complicated. Due to technical limitations in the current implementation, the ‘asynchronous’ updater and stock index works in a slightly different way (stock index still does not count reservations during reindexing). In such cases, it could cause new issues.
Let’s assume the next situation: some product was bought and shipment still has not been created (stock deduction has not been run yet). The asynchronous update was processed and the stock status and product status has been changed to ‘out of stock’ in the index data. It seems to be something which we looked for, isn’t it? Yes, but if the indexing process will be run (e.g. someone just runs full stock reindex with command-line interface) it will lead to the wrong status in the stock table because the index will calculate status without reservations. As a result, products will appear as ‘In Stock’ on products landing and in product detail pages until shipment will be created and a stock deduction will be executed. But product status will still be correctly calculated during adding the product to the cart - to avoid any possible issues with overselling. And this is the price which we pay for such a performance boost.
Fortunately, if such a problem is critical for your business or the business of your client, the approach can be easily rolled back with a small customization! Such edge cases are expected to be eliminated in the future, at which point Multi-Source Inventory functionality will exist as initially planned - well designed, highly extensible, fast, and without data inconsistency.
What is next?
There are things to improve and plans for a bright future.
The future of performance for Magento Inventory - and for Magento 2 in general - depends on the community more than ever. As mentioned above, not all performance improvements are included in the 2.4 release, but together we can bring this moment closer. Will these improvements be a part of 2.4.1 or 2.4.2, or even later? Of course, this is a responsibility of the Magento Team but, to be honest with you, it depends on community and community contributors. Can we make it together or wait until someone will do it for us? The choice is yours, and it would be wonderful to have your involvement.
Magento 2.4 brings a new step in relations between the community and the Magento Inventory. The usage of legacy inventory becomes a burden because the latest performance measurements show that the Magento Inventory is as good as if not better than the legacy inventory system and will to fully surpass legacy inventory in the early 2.4 releases. The legacy inventory is not an option anymore from a performance perspective and the new Magento Inventory provides a wide assortment of additional enhancements for their users like multi-source support of all product types and the possibility to use out-of-the-box In-Store Pickup functionality.
(Editor note: the current version of this article clarifies Magento version details regarding performance - BHM)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.