Great question. Memory was actually not the main constraint in this setup. Each DepthCache only keeps a limited order book depth in memory — in this test roughly 2000 price levels in total for bids and asks together. That is not a huge amount of data per market, even when running many markets with replicas. The more interesting resource was CPU. During initialization and synchronization, the cluster has to load snapshots, process live depth stream updates, keep replicas synchronized and serve REST requests. That is where the nodes started to work much harder. So the short version is: Memory stayed manageable. CPU was the part that really got hot. That also matched the later load-test behavior: the failure mode was not memory exhaustion or pod crashes, but increasing REST latency and timeouts once the small 2 vCPU nodes got under heavy CPU pressure.

Yes — but that’s just the standard depth-cache approach. My point was not “use live data instead of local memory”. My point was that embedding market-state reconstruction inside each bot is often the architectural mistake.

I don’t see that as either/or. Execution should become simpler. But getting there often means pushing complexity down into dedicated data infrastructure layers instead of keeping it inside every bot.