Authors:
Oleksandr Kravchuk, Backend Developer at Vaimo, Magento Master
Maksym Novik, Backend Developer at Decima Digital, Magento Community Maintainer
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.
If you are not familiar with the Inventory project and (or) its functionality, you can read more in the official Magento documentation on Github and Devdocs.
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.
In-Store Pickup
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.
Performance Optimization
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:
- The new inventory officially becomes a part of the Magento codebase, which means that you will receive new features, bug fixes and security fixes to it as a part of each Magento upgrade.
- The Magento Inventory is a live project which means that you can expect an assistant with any issue or bug which you can face
- In the early 2.4 line, Magento is going to release major fixes of performance issues. With new performance boosts, Magento Inventory is expected to be much faster than the legacy one.
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:
- Products Landing Page (PLP) - up to 14%
- Search - up to 13%
- Product Details Page (PDP) - up to 5%
- Add to cart - up to 30%
- Checkout - up to 15%
- Success Page - up to 10%
Further improvements will be included in subsequent releases. For additional details see PRs #3039, #3088, and #3151.
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.
Source: Introducing the Command Query Responsibility Segregation Pattern
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:
- asynchronously applies reservations for the Stock data (like Event Handler applies to react on the event and provide mutations for projection or Read data);
- gets rid of usage of Source Items (Write data) for salability status on application storefront and replace the source with pre-calculated Stock data
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.
- Make IsProductSalable service to be able to work with composite products. Currently, configurable and bundle products salability statuses are being calculated dynamically.
- Move salability status calculation from `catalog_product_load_after` event into a plugin in order to use it only if and when it is required, instead of calculation status together with product data load from the database. Something kind of lazy-loading.
- Decrease Adding product to cart complexity. At the moment, when a new product is added to cart or item QTY is updated, salability status is being recalculated for each item (algorithm with O(n) complexity) that can lead to dramatic performance degradation issues for shopping carts with many items - for example for B2B customers. The new approach is to check the salability status only for an item that is going to be added to a shopping cart (algorithm with O(1) complexity).
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.
Summary
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)
3 Comments