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.