State and Server Resource Management
The Novos integration API is designed so that the client (cart) "owns" the transaction state. The client is the source of truth for the items in the customers' cart.
At any point in time the client can PUT the transaction to Novos and Novos will reconcile the client's transaction state with the internal state of the ACE Point Of Sale application. ACE is the single source of truth from the retailer's perspective.
In order to be as efficient as possible, Novos attempts to optimize the reconciliation between the client state and the ACE state by caching the the last known client state. "clientInfo.uuid" is the lookup key used to cache the client state. If Novos receives a request without a client UUID, it generates one and caches the client response using the generated UUID/key. The client just needs to include the auto-generated UUID on subsequent requests.
Each time Novos receives a client request Novos performs a comparison between the new state in the request and the last known client state (the last response). Using the deltas, Novos only performs the minimal number of operations needed to reconcile the client with ACE.
If no cached client state is found, Novos assumes that it must void any existing ACE state and start the transaction from the beginning. The logic here is that if there is no cached state, it is most likely an indication that either the client, Novos, or the ACE application has re-initialized or otherwise become unsynchronized or unknown. This indicates to Novos that the connection between ACE and the client needs to be resynchronized.
This does not mean that Novos retains no state - Novos is managing instances of the ACE application which do retain considerable state information across requests.
Each ACE application instance requires non-trivial CPU and memory resources on the server. Each ACE instance also takes significant time to create and initialize. Depending on conditions outside of our control it can sometimes take multiple minutes to create an instance of the ACE application and make its resources available to the clients.
The number of ACE instances available is also limited. There is a hard limit of 999 instances that must be shared across all platforms in the store (SCO, front end POS, mobile POS, smart carts, etc.). QVS's Terminal Concentrator also has a limit of around 100 instances that it can manage. That limitation is driven by some old networking protocol limitations as well as CPU/memory/disk requirements of the applications. You can run multiple instances of Terminal Concentrator if more than 100 instances of the ACE application are required.
Since ACE instances are memory-intensive to create and ACE's internal state is complicated and expensive to generate, Novos further tries to optimize operations by keeping a client associated with the same ACE instance across client requests. As long as the number of clients does not exceed the number of active ACE instances Novos can preserve ACE state across client requests.
If the number of clients exceeds the number of ACE instances, Novos will multiplex the client requests into the available ACE instances by automatically voiding and restarting transactions as needed.