Magento Multi-Source Inventory (MSI) tracks stock across multiple warehouses, stores, and drop-ship locations, then rolls it up into a single salable quantity per sales channel. It is powerful and accurate, but it adds real query cost to every product page. On a Hyva storefront the job is to show correct stock and shipping signals fast, keep marketplaces in sync, and never let one channel oversell another.
This guide covers how MSI actually works under the hood, the performance tax it introduces, how to render stock cleanly on a Hyva frontend, and how to keep Amazon, eBay, and your own store from selling the same unit twice. It is written for merchants running real multi-location operations, not a single warehouse.
What MSI actually is: sources, stocks, and sales channels
MSI, built into Magento 2.3 and later and into Adobe Commerce, replaces the old single stock model with three objects you configure directly.
- Sources are physical places that hold inventory: a warehouse, a retail store, a 3PL, a drop-ship supplier. Each source has its own address, lead time, and per-SKU quantity.
- Stocks are groupings of one or more sources mapped to one or more sales channels. A stock is what a channel actually sells from.
- Sales channels are your websites or store views. Each website links to exactly one stock, which links to the sources that fulfil it.
The point of this structure is regional and channel-specific selling. A US website can sell from three domestic warehouses while a separate B2B channel sells from a dedicated distribution center, all in one Magento install. You do not run parallel catalogs; you map channels to the sources that serve them.
Salable quantity and the reservation lifecycle
The number that matters on the storefront is not the raw quantity in a source. It is the salable quantity, which is the physical stock minus everything already promised but not yet shipped. MSI keeps this accurate with a reservation system.
Here is the lifecycle:
- A customer places an order. Magento writes a row to
inventory_reservationthat holds the quantity. Salable quantity drops immediately, even though the physical source quantity has not changed. - The order is invoiced and shipped. The reservation is compensated and the quantity is deducted from the specific source that fulfilled it.
- A cleanup cron (
inventory_cleanup_reservations) clears completed reservation rows so the table does not grow without bound.
This is why a product can show as out of stock the moment its last units are in open carts, before anything physically leaves the building. It is also why the inventory_reservation table is the first place to look when checkout gets slow. If that cleanup cron lags, the table swells into the millions of rows and every salability check pays for it. Run bin/magento inventory:reservations:cleanup and confirm the cron is firing on any store where checkout has crept upward.
The performance tax MSI puts on your storefront
MSI trades a flat lookup for a normalized set of tables: inventory_source, inventory_source_item, inventory_stock, inventory_stock_sales_channel, and inventory_reservation. Every salability check now resolves a chain across those tables through a plugin chain (IsSalableConditionInterface) and the GetProductSalableQty service, and that runs on every product across the catalog page, cart, and checkout. On a category page with dozens of products, the cost cascades.
The fixes are well established. Most are configuration, not custom code.
| Symptom | Likely cause | Fix |
|---|---|---|
| Slow category and listing pages | Salability checks per product, real-time indexing | Set the inventory indexer to schedule: bin/magento indexer:set-mode schedule inventory_stock |
| Checkout latency climbing over time | inventory_reservation table bloat |
Run bin/magento inventory:reservations:cleanup; verify the cleanup cron |
| Single-warehouse store still paying the MSI tax | MSI enabled with one source needlessly | Export stock to default source and keep Default Source / Default Stock only |
| Configurable products triggering cascades | Child stock aggregated per request | Confirm Magento_InventoryConfigurableProduct is enabled |
Repeated slow queries on inventory_* tables |
No result caching on salability | Cache GetProductSalableQty results with a short TTL |
The single most common mistake is leaving the inventory indexer on “Update on Save” in production. That recomputes salability synchronously on every product edit and import, blocking the frontend. Schedule mode moves the work to cron and is the correct default for any live store.
Showing accurate stock on a Hyva storefront
MSI gives you correct numbers. Your Hyva theme decides how to show them, and this is where enterprise multi-warehouse stores need real development rather than the default availability label.
Read salability, not source quantity. Storefront blocks should read the aggregated salable quantity for the current channel, never a single source total. Showing a warehouse figure that ignores reservations is how you promise stock you do not have.
Decide what is cacheable and what is not. Stock status (in stock, out of stock, low stock) changes slowly enough to sit inside the full page cache with a sensible invalidation. A live per-unit salable count is dynamic and belongs in a private-content or lightly cached block. A practical pattern is to cache stock state at a short TTL (30 to 60 seconds) rather than querying the inventory chain on every single page load, which keeps listing pages fast while keeping the number honest.
Show source-aware shipping signals. Multi-warehouse operations win by telling the customer something useful: which location will ship, an estimated dispatch time based on that source’s lead time, or split-shipment expectations for a mixed cart. Those require Hyva-compatible blocks that read MSI source data. Because Hyva renders with Alpine.js and native JavaScript instead of the Luma component stack, these dynamic stock widgets are lighter to build and cheaper to keep fast.
Keep it fast. A Hyva frontend is the reason a catalog page rendering per-product salability across a dozen warehouses still loads quickly. Speed here is not cosmetic; slow, inventory-heavy category pages are a direct drag on Core Web Vitals and conversion. If you want the broader case, see the Magento development approach to keeping heavy catalogs responsive.
Keeping marketplaces in sync without overselling
Multi-location merchants rarely sell on their own store alone. The moment Amazon, eBay, or Walmart share the same physical stock, MSI stops being an internal detail and becomes the source of truth that every channel must respect.
The failure mode is overselling: two channels each sell the last unit because neither knew about the other’s sale in time. MSI helps by centralizing salable quantity, but the marketplace connector has to write back fast and read the same salable number your storefront uses.
Practical rules that prevent oversells:
- One source of truth. Every channel, including marketplaces, should decrement against the same MSI stock. Do not let a marketplace app keep its own separate count.
- Tight sync intervals. The gap between a sale on one channel and the stock update on the others is your oversell window. Shorten it, and add a safety buffer on fast-moving SKUs.
- Reserve on order, not on ship. Marketplace orders should create reservations immediately, the same way a storefront order does, so salable quantity reflects them at once.
- Reconcile daily. A scheduled reconciliation between physical counts, MSI, and each channel catches drift before it becomes a customer-facing error.
Your connector and middleware choices matter as much as the platform here. This is where an agency’s technology partner ecosystem across inventory, ERP, and marketplace integration earns its place, because the right connector is the difference between clean sync and a weekly oversell cleanup.
How multi-location inventory works across platforms
If you are weighing platforms partly on inventory needs, the depth of native multi-location support varies. Here is the practical picture.
| Platform | Native multi-location inventory | Notes |
|---|---|---|
| Magento / Adobe Commerce | MSI: sources, stocks, channels, reservations, source selection | Deepest native model; performance needs tuning |
| Shopify Plus | Multiple locations with per-location stock and routing | Simpler and fast, fewer B2B and source-selection controls |
| BigCommerce | Multi-location inventory with location-based fulfillment | Solid mid-market fit, less granular than MSI |
| Shopware | Warehouse and stock management, extensible | Flexible, more configuration and build effort |
If your roadmap points toward Shopify development, the multi-location model is simpler to run and quick out of the box, which suits many DTC brands. BigCommerce development sits in a comfortable mid-market spot, and Shopware development gives you flexibility at the cost of more setup. Magento’s MSI remains the most granular when you have complex sourcing rules, B2B channels, and a real source selection algorithm to run. Choose on the whole operation, not the inventory feature alone.
An implementation sequence that holds up
Multi-source projects that stay stable tend to follow this order:
- Model your real network first. List every source, its lead time, and which channels it should serve. Get the source-to-stock-to-channel mapping right on paper before configuring anything.
- Set indexers to schedule. Before you load real volume, put
inventory_stockon schedule mode. - Load stock and validate salable quantity. Confirm the number the storefront will read matches reality per channel.
- Build the Hyva stock and shipping blocks. Salability-aware status, cache strategy, and source-based shipping signals.
- Wire marketplaces to the same stock. Reserve on order, sync tight, reconcile daily.
- Load test the catalog pages. Category pages with per-product salability are where MSI performance shows up. Fix it before launch, not after.
The pattern that fails is treating inventory as a data import and skipping the storefront and performance work. MSI is accurate by design; keeping it fast and honest on the frontend is the actual project.
FAQ
What is the difference between quantity and salable quantity in Magento MSI?
Quantity is the physical stock recorded against a source. Salable quantity is that stock minus active reservations for orders that have not yet shipped. The storefront should always display or gate on salable quantity, because it reflects what a customer can actually buy right now. Showing raw source quantity is how stores oversell.
Does MSI slow down a Magento store?
It can. MSI resolves salability across several normalized tables on every product load, so category pages and checkout pay a cost. The main fixes are setting the inventory indexer to schedule mode, keeping the reservation cleanup cron healthy, caching salability results with a short TTL, and, for single-warehouse stores, not running MSI at all. Tuned correctly, the impact is manageable.
Should a single-warehouse merchant use MSI?
Usually no. If you ship from one location, the MSI machinery adds query cost with no benefit. Export your stock to the default source, keep only Default Source and Default Stock, and avoid the multi-source overhead. Turn to full MSI when you genuinely sell from more than one source.
How do I stop overselling across Amazon, eBay, and my store?
Make MSI the single source of truth, have every channel reserve stock the instant an order lands rather than at shipment, keep sync intervals short, add a safety buffer on fast movers, and reconcile physical counts against MSI and each channel daily. Overselling is almost always a timing gap between a sale on one channel and the update on the others.
Does MSI work with a Hyva frontend?
Yes. MSI is a backend inventory model and is theme-agnostic. Hyva needs blocks that read salable quantity and, for multi-warehouse stores, source-aware shipping signals. Hyva’s Alpine.js rendering makes those dynamic stock widgets lighter and faster to build than the equivalent on Luma, which matters on inventory-heavy category pages.
Where to start
If you run more than one warehouse or sell across marketplaces, get the source-to-channel model and the performance tuning right before you worry about anything else, then build the storefront stock experience on top. Bemeir is a Brooklyn Magento and Adobe Commerce agency and the USA’s first Hyva Gold Partner; you can read more about Bemeir and how the team works as an extension of yours. When you are ready to map your inventory network to a build plan, start at Bemeir.
