Stock and Source Configuration design

Table of Contents

• CQRS in Source and Stock APIs

CQRS in Source and Stock APIs

The main technical concept we follow in MSI architecture is to segregate Command and Query APIs. In our case, the role of Query APIs play StockItem related interfaces and services as the StockItem entity is an aggregated indexed data among the physical locations (Sources)plus additional business rules on top of it, so that StockItem data is calculated based on the raw data we have on Source level. A customer working with front-end does not update StockItem data directly, he just exposes commands which would be processed by the system later (the role of such commands play Reservation mechanism). This concept has been used for Quantity and Salability status calculation, that's why Magento front-end which works only with Stock Services (i.e. IsProductSalableInterface, IsProductSalableForRequestedQtyInterface, GetProductSalableQtyInterface) is agnostic to the fact whether Magento is Single or Multi-Source under the hood, and the number of sources from which given Stock consists of don't affect the system performance, as the reservation we place at the time of Checkout created on the level of Stock. In contrary to this, an Admin workin in Magento Admin panel updates data on the level of SourceItem which would lead to re-building the StockItem data index. You can get more details about this concept from [CQRS and EventSourcing webinar] video recording (https://www.youtube.com/watch?v=K1jLOiIXL2M).

The similar principle should be applied for StockItem configuration as well so that Front-end would work with StockItem configuration only which is built based on SourceItem configuration. But the things here are a bit more complicated than in comparison to stock availability and salable quantity calculation, because there are different configuration options and some of them could be specified on the level of Source, others on the level of Stock.