Skip to main content

Point of Sale Migration - Shopping Cart Concurrency Solutioning

Context:​

An existing system is in place for the client. Below is a simple sequence diagram for the cashier: Old System - Transaction

The effectiveness of this system assumes the simplicity of the current client setup:

  • There is only one actor (cashier, owner) , interacting with the device at a time.
  • As such, the sequence of events does not offer a concurrency issue.

Problem:​

Now, the client wants to move the application to the digital world, while also upgrading their Old System.

In this scenario, the store will have a buyer-facing page where the multiple users can interact and checkout items.

Assume the ff. scenario: Multiple Buyers

One solution is to force update the current Item1 entities active in the API, but that might incur an unnecessary workload to the database. Assume that there is 1,000 buyers checking out the remaining item.

That would mean an update to the remaining 999 objects once the first transaction completed.

Another solution is offline optimistic locking, as outlined by Martin Fowler. As the article says, obtaining a lock indi-cating it's okay to go ahead with the changes to the record data.. We will be implementing this via the ff: New Sequence

The Transaction API won't be block by the long operations of Product Stock API, and can continue to process transactions. assuming that a multiple checkout occurs, it will be first-come-first-serve basis. In an event that 1 out of 3 items requested is unavailable, the user may be given a choice to continue with the transaction. In the backend side, this means a new transactionId must be created.(For tracking how many transactions failed).

The product stock can also be queried by the Store application. this is to help block subsequent transactions from being requested.