Batch endpoints look like a gift to the sizing engineer at first glance. One HTTP request that carries fifty resources means one hit on the front door, one authentication check, and one entry in the request log. In the sizing spreadsheet the request rate stays low, and the capacity plan looks comfortable.
The gift is real on the network layer and misleading on every layer below. The actual capacity cost of a batch endpoint is the sum of the sub-request costs, and that number grows quickly. For related capacity mechanics, the FHIR learning path is the collection on the home page.
What the Batch Endpoint Is Actually Doing
A FHIR batch or transaction Bundle is a container of sub-requests, each carrying its own verb, target, and payload. The server unpacks the container, processes each sub-request against the database, and stitches the responses back into a single response Bundle. The client sees one HTTP round trip; the server does N.
That fan-out is the source of the inflation. A twenty-entry transaction Bundle exercises the database and cache layers as twenty distinct operations, all inside one lock window if the operation is transactional. A pass through the site's FHIR server throughput sizing widget can model the amplification when the average batch size is entered explicitly.
The Two Sides of the Amplification
Two sides of the amplification matter for sizing:
- Database load — every sub-request in the batch translates to at least one database operation. Reads inside a batch scan indexes; writes fire the same cascade a standalone write would.
- Lock scope — a transaction Bundle holds a lock across all its sub-requests. Long batches serialize behind that lock and reduce effective write concurrency.
Sizing that models the batch as one write per HTTP request misses both effects. For the underlying write-cost model, why FHIR write RPS is not the same as read RPS covers the cascade.
The Batch Size Distribution
Batch sizes in production almost never follow the average alone. Most workflows send a heavy tail of large batches during ingestion windows and a light tail of small batches for interactive updates. Sizing that uses only the average under-counts the peak and over-counts the trough.
Ask the workflow designer for the batch size distribution, not just the average. If the distribution is not known yet, plan for the ninety-fifth percentile size at the target RPS. That single number gets you closer to a realistic peak than the mean will.
When the Amplification Helps
The amplification is not always bad news. Batches avoid the per-request network overhead, they cut authentication cost, and they let the database batch its own commits. On a well-tuned server the amortized cost of a fifty-entry batch is meaningfully less than fifty standalone writes.
The catch is that the savings live on the network side, while the amplification lives on the database side. The two do not cancel out for sizing purposes; they need to be modeled separately.
The Chatty Client Comparison
Batch endpoints are the counter to the chatty client problem. A workflow that fires twenty small requests per action is easier to route and cache but harder to serialize on the write path. A workflow that fires one twenty-entry batch is easier on the network but harder on the database. Both patterns exist in production, sometimes for the same workflow at different times of day. For the chatty-client side of the same conversation, when RPS estimates lie: the cost of chatty FHIR clients covers the failure mode.
Sizing the Batch Line
Add batch endpoints to the sizing plan as their own line. Multiply the batch RPS by the average batch size to get the effective sub-request rate, and size the database tier against that number. The line often turns out to be the largest contributor to write capacity in the plan.
Naming batch amplification explicitly is the shortest path to a plan that survives the first ingestion peak.
Sources
- HL7 FHIR core specification of the Bundle resource - HL7 FHIR core specification of the Bundle resource, canonical rules for batch and transaction expansion semantics