Actually, updating versioned repository items from production instances is a very bad practice so in my opinion your proposal is the only possible solution I can imagine. You need a non-versioned persistent repository (let us call it InventoryRepository) containing item descriptor (let us call it stockLevel) which keeps track of the products stock.
However, there is a trap that stays behind this approach. In order to guarantee that the product's stock level is up to date, you have to disable caching on stockLevel item descriptor. This brings a risk that the data base will be overloaded with updates, which may lead to efficiency issues.
In one of my projects we worked that problem around by moving stock actualization functionality to another server instance (util) - triggered by asynchronous DMS calls (whose source was customer's action like putting item to the basket). Thanks to that, the production instances were only reading stock levels from InventoryRepository, not updating them.
That was a huge performance improvement but the production instances were still reading non-cached values very frequently. We observed that if the stock level for a particular device is very high, there is no need to check its exact value if only boolean information is required (available or not). So we introduced a cached item-descriptor which assigned a boolean property (isHighlyAvailable) to a product id. Until the stock level of a particular product was not reduced to a threshold value (say 100), isHighlyAvailable was set to true and production instances were relying on its value. Once the threshold was reached, the isHighlyAvailable was unset (by asynchronous DMS message), and from now on the exact, uncached stockLevel value was taken into consideration by production instances when evaluating product availability.