The heaviest studies on the smallest box.

§1 — The real question, and the two fears behind it

"Can it handle big studies?" actually hides two distinct fears, and they stress completely different resources:

Fear 1: the giant object (memory)

A single 3D tomosynthesis volume is ~561 MB to over 1 GB — one such study outweighs thousands of routine images. The worry is that a few of these arriving at once will exhaust the box's RAM. This is the failure mode that constrains processing nodes, which must hold the decoded volume in memory.

Fear 2: the giant count (throughput & contention)

A wide-detector CT angio can be 3,000–10,000 thin slices — each small, but the sheer number stresses the per-object pipeline: connection churn, and the routing-state lookups that a study-aware balancer performs for every instance. This is the contention class that can choke a naïve database-backed router.

A trustworthy answer has to address both axes — few-huge and many-small — not one. This paper measures each.

§3 — The central finding: memory doesn't track data

The single most important result: SynthIQ's memory footprint is governed by how many objects are in flight at once, not by how big they are or how many you send. Because SynthIQ is a routing proxy — it inspects an object's identity to make a placement decision, but never decodes the pixels — each in-flight object is spooled to a temporary file and streamed to the chosen backend. The pixel bytes live on disk for the moments they're in transit; they never inflate the managed heap.

Plotted against the payload pushed through it, SynthIQ's heap is essentially a flat line hugging the floor of the box:

Measured peak heap on a 2 vCPU / 8 GB instance. The heap stays at the floor of the box across a 7× range of data volume — and never approaches the host ceiling. This is the spool-and-stream design: the in-flight pixel data is on disk, not in memory.

§5 — Fear 2, tested: high-count CT (the giant count)

To stress the count axis we simulated a busy CT environment: a fleet of ten 1,000-object studies plus two 10,000-object "Alpha CT" studies, all arriving concurrently — 30,000 objects, ~30 GB, with a new routing decision and routing-state lookup for every object.

A correction to this table. Its last column previously read "Delivery", with totals of 10,000 / 10,000 and 20,000 / 20,000 presented as a delivery ledger. Those totals were sender-side counts of successful C-STOREs, not a receiver-side reconciliation, and we have removed them rather than restate them. The sender's view cannot separate an object that was lost from one that was merely unacknowledged, and a single association fault marks a whole 50-instance batch failed regardless of what actually arrived. Receiver-side reconciliation exists as a separate procedure; it was not run against these results, so there is no delivery percentage here to quote. What the table does say is that nothing was refused: every object we sent was accepted, and SynthIQ reported no failure on any of them.

Over a 23-minute sustained run, SynthIQ's heap peaked at 620 MB and plateaued; ~6.9 GB of RAM stayed free; CPU was never pinned; and the management API answered every one of 282 health probes. Critically, SynthIQ absorbed 30,000 routing-state lookups — the exact contention pattern that overwhelms database-backed routers — without a stumble, because its study-affinity store records a placement once per study and serves the rest from a fast cache.

Few-huge or many-small, the answer is the same: heap under 700 MB, not one refused or failed object, on a 2 vCPU / 8 GB box.

§7 — What does scale with the box: throughput

Memory is settled. The lever that remains is throughput. SynthIQ opens a fresh, fully-released association per forwarded object — a deliberate reliability choice that eliminates a class of stale-socket failures — so an extreme-instance study (a 10,000-slice Alpha CT) clears at a rate governed by per-object handling and the available cores. On the 2 vCPU floor, that single 10,000-object study was accepted over about 23 minutes; on more cores it parallelises and clears faster, though well short of proportionally: quadrupling the load balancer from 2 to 8 vCPU bought 25% on our Azure rig, and most of that arrived by 4 vCPU. Throughput rises with cores, with diminishing returns; it is never gated by memory.

Both of those figures — the 23 minutes and the 25% — are ingest acceptance, timed from the sender's C-STORE responses. Behind SynthIQ sits a router that answers as soon as it has spooled an object and queued it, so a successful C-STORE means the object was accepted, not that the destination has it. The delivered rate is materially lower. On the two single-router hosts where we have measured delivery directly, counting on the receiving side, delivery ran at roughly a third of ingest — 159 instances/sec against 511 on one host, 196 against 751 on the other.

Delivery through a pool — measured, and it is the better number

An earlier version of this section said we had not measured delivery through a SynthIQ pool. We have now. On a separate rig where both routers are the same 8 vCPU silicon, each forwarding through its own outbound leg to its own destination: three runs per condition, the published workload unchanged, every router-class host — including both destinations — reset to a clean database first, and every run settling at exactly 20,000 delivered with zero failures.

The ingest row reproduces the 0.45 pooling ratio we had already published at this balancer tier — on the same runs that produced the delivery row, which is what makes the delivery row trustworthy rather than merely new. The two rows are not the same fact. Pooling costs about a third of delivery throughput, not more than half, so the 0.45 we had been quoting is an ingest ratio that understates what a pool does for the work actually leaving the path. Pooled delivery is also 1.24× a single node — 432 against 350 — so on the delivery framing a second node buys throughput as well as availability, where the ingest framing made pooling look like a tax paid purely for redundancy. The split between the two nodes was even to within 1%, so balancing is not the constraint.

The reason the two ratios differ is structural. Ingest is the front door, and the balancer hop in front of it costs real acceptance capacity — that is what 0.45 measures. Delivery is the pipeline behind that door, and the pipeline is where a second node genuinely helps: each router forwards through its own outbound leg to its own destination. Measuring only the front door hid the benefit the pool exists to provide. Two nodes is what was measured; nothing about a third node is, and the ratios are not extended to one.

One further disclosure about the campaign that produced the 25% figure: it neither reset nor recorded the size of each router's operational database between measurements, and every host on both rigs was afterwards found past the volume knee at which a router begins refusing new work — a knee measured at 438–583 MB, against hosts found at 1,467 MB and 1,901 MB. Those figures were therefore taken at an unknown and drifting database volume. The delivery measurements quoted above were taken on a clean database with the queues verified empty at settle.

And capacity grows the same way it does for the rest of the platform — by adding nodes, not bigger boxes. A SynthIQ pool load-balances DICOM across multiple instances, and its weight-aware placement steers the heavy studies toward the backends with the most headroom. Scale-out is predictable and needs no forklift upgrade, and the architecture is highly available by design rather than dependent on a single oversized node. It is not, on the evidence above, linear: a second node delivered 1.24× one node, not 2×. Plan for the measured ratio, not for the arithmetic one.

Conclusion

The worry that a DICOM load balancer will buckle under big studies does not survive measurement. On the smallest instance a cloud will rent, SynthIQ took 70 tomosynthesis studies and 30,000 CT objects without a single failed C-STORE, using under 700 MB of memory, staying responsive throughout. Because it routes rather than renders, its memory is bounded by concurrency, not by the size or count of the studies — so 2 vCPU / 8 GB is enough for every modality, with room to spare. Size SynthIQ for the throughput you want — measured as what the path delivers, not as what it accepts — and you will never size it to survive the biggest study.