Fourteen checkouts, one license.

Picture an office with a single phone line and fourteen clerks. If each needed the line all the time, you would need fourteen lines. But each call lasts a few seconds and nobody talks all day. An operator who connects the calls in order solves it with one line, and nobody notices the wait.

A store's checkouts work the same way. Each sale makes short queries to the management system, the ERP: price, stock, invoice. Between sales, the checkout does not use the ERP. The ERP license, however, was counted per connected terminal.

The proxy is the operator: it sits between the checkouts and the ERP, keeps a single connection open and passes the requests in order, with a queue for peaks and a cache for what repeats.

It was not a performance problem. The ERP could handle the volume; what did not fit was the license-counting rule, in the budget and in the deadline. Without a technical solution, the store would open Black Friday with fewer checkouts.

We learned the protocol the checkouts use to talk to TOTVS, mapped the critical operations and wrote a proxy in Go, a language good at many simultaneous conversations that compiles into a single program that is easy to install. It has four parts:

Single connection. The checkouts connect to the proxy as if it were the ERP; the proxy holds the licensed connection.

Queue. When two checkouts ask at the same time, one waits fractions of a second. The queue absorbs the peaks.

Cache and connection pool. What repeats (the same price looked up many times) comes back faster, and the connection is reused.

Monitoring and recovery. Every operation is logged, and if the connection drops the proxy reconnects on its own.

The checkouts were not changed. For them, nothing changed.