Feedback wanted: Sales order API v3 - eventual consistency for Inventory update

[Joni Wolff]

Hi

As part of the implementation of the Sales order API v3 we update the Inventory quantities(Available, Available for shipping etc) for the items included in the sales order.

While testing this, we noticed concurrency issues for the quantities when orders with the same item are created at the same time, which can lead to wrong quantities and/or longer time for processing the order.

To improve the flow, we plan to introduce eventual consistency related to the inventory update for the orders created from the Sales order API v3. This means that the quantities will still be updated, but the update will run as a separate process in the background right after the order is created.

For you as an integrator, the only difference from today is that the inventory quantities will be updated within a time frame of 100 - 3000 ms. This will be seen, for example, in that the quantities in GET/inventory will be updated within that time frame.

Therefore we want to ask you, our integrators, about your view on this. Is it OK that the inventory quantities are updated with this short delay? Please comment your input in this thread.

[Trygve Storrønningen1]

Hi, Joni!

In principle this sounds like a good idea. Are you also suggesting that the order will be given an initial status which indicates that it is valid and acknowledged by the system, which then changes to another status which indicates that the inventory is updated with the quantities in this order?

We should be able to tell by looking at the order status whether it is included in the inventory or not. Then it won't matter if it takes a couple of seconds before the separate process completes. In short, the system must tell the truth at all times.

[Joni Wolff]

Thanks for the input! We will discuss on a good way to solve this also considering what you stated about the status.