Reservations
The process of order conversion is a complex process as the seller must guarantee the quantity on an e-commerce site or store location are to be fulfilled at the end of the pipeline. Typically, if there is an order conversion delay between the front end and the backend system, it can lead to overselling if not handled properly. For example, on a product detail page, the seller can indicate the total quantity available and when two shoppers are adding the item to cart or checkout at the same time, there is a need for a deterministic way to resolve who receives the last quantity of the product.
Reservation enables item quantities to be set aside for short-time that enables backend system to complete the processing of demands. The reservation requests occur in real-time and have a nonlocking behavior such that when a request is received, the availability is verified before reservation booking. In case if the are multiple reservations to access the same quantity, the first successful booking is processed and all reservations that are done on later dates are rollback and rejected. The reservation quantity accepted is next considered in future availability lookups that includes the new reservation requests.
- Auto rollback on unsuccessful reservation
- Reservation expiry is configurable
- Reservation is consumable as part of demand update.
- Reservation can be grouped by reference
- Partial reservation is supported
- Reservation workflow
- Consider an online shopping scenario where a shopper wants to place an order for an item. When
the item is added to a cart or as part of checkout, the following steps occur in the backend system:
- Obtain the item availability and compare it against the request quantity.
- If sufficient quantity is available, an item reservation is requested.Note: The second step can be performed when the items are added to a cart or can be done when items are in process of checkout.
- Verify the reservation state and determine whether the reservation is fully reserved, partial reserved, or unreserved. If the quantity is not fully reserved, the user should be notified of insufficient quantity.
- If the quantity is canceled or removed from the cart, the corresponding reservation should be amended to reflect the latest quantity reserved that frees up the availability to other shoppers.
- The reservation is converted into order or demand. The backend system includes the reservation ID as part of demand and order update, which triggers consumption of the reservation.
| Reservation | Outcome |
|---|---|
| Reserved | If the full quantity is reserved, the store publishes a demand that includes the reservation details so that the reservation can be consumed. |
| Partially reserved | The partial quantities are reserved on the system. Based on the order acceptance status, the customer needs to determine whether the reservation needs to be preserved or deleted. |
| Unreserved | The inventory is not reserved and the customers need to look for alternative inventory. |
Overriding safety stock quantity in reservation
By default, all the reservations APIs consider the total available quantity and safety stock that
is withheld when a reservation is accepted. Under specific circumstances, a reservation API can
override and consume the withheld safety stock quantity by using the
considerSafetyStock = false parameter. However, doing so
might cause inventory to be over promised leading to a shortage.
For more information,
see Reservation API.
Item with an associated parent
When a child item is reserved, its parent is also reserved to maintain overall parent availability as sum of all its child items availabilities.
V1 reservations by using node priority behavior
When a network level V1 reservation is created (legacy behavior), the system considers the network availability before blocking inventory quantity. In some complex scenario where one or more nodes is part of multiple networks, this can quickly lead to an overselling scenario.
For example, consider Node1 has 5 qty and Node2 has 7 qty of availability. If two distribution groups are created as DG1 and DG2 where both have the same node, then both observe the same availability of 12 qty. In this legacy behavior, the reservation created against one distribution group is not aware of the other group. This means that it is possible for both DG1 and DG2 to reserve 12 qty leading to overselling.
The fundamental difference with node priority reservation is that the system performs an inventory check on both individual node in the distribution group and network upon accepting the requested quantity. The reservation quantity is assigned to a node instead of network level so that any network sharing the same node has the latest inventory picture. When multiple nodes exist in the distribution group definition, the reservation booking is done in the order of the node priority value.
If you are using V1 reservation, you can enable node priority reservation by setting reservations.placeNodeLevelReservationForDg=true in the inventory Settings API.
To configure the order which nodes are considered, the user can defined the priority value for
each node in the distribution group as multiple nodes can have the same priority value. The tie
breaker is the node with the oldest inventory is reserved first.
For more information,
see Distribution Group API.
As an example, DG1 has [Node2, Node1, Node3, Node4] as the node priority sequence. This means Node2 availability is always reserved first. Once the Node2 depletes, the system then traverses to subsequent priority node until the reservation request quantity is met.