The RPS estimate on the sizing spreadsheet is only as good as the client behavior that fills it. When the same workflow is served by a well-designed client that fetches everything it needs in three calls, the sizing holds. When the workflow is served by a chatty client that fires twenty calls to accomplish the same task, the same estimate turns into an under-provisioning story. Client behavior is not usually a sizing input, and that is exactly why it catches teams by surprise.
For the wider set on capacity mechanics, more on healthcare data exchange is the collection on the home page. This piece stays with the specific failure mode of chatty clients.
What Chattiness Looks Like on the Wire
A chatty FHIR client is one that fetches every referenced resource individually instead of using _include or a batch. Loading a chart on such a client fires a Patient read, then a walk through Encounters, then per-Encounter fetches for Observations and MedicationRequests, then per-resource fetches for the referenced code systems.
The chart loads correctly, but the API receives an order of magnitude more requests than a well-designed client would fire. A pass through the site's FHIR server throughput sizing widget can model the difference when the chattiness multiplier is entered explicitly.
Where the Behavior Comes From
Client chattiness usually comes from one of three sources:
- Framework defaults — some SDKs default to lazy loading and fetch referenced resources on access rather than up front.
- Team unfamiliarity — teams new to FHIR often start with per-resource fetches and only learn about
_includelater. - Legacy adaptation — clients written against HL7 v2 patterns sometimes port the per-message model directly to FHIR.
None of these is malicious. All of them produce load patterns that a sizing plan will not have predicted.
The Multiplier That Lives in the Middle
The sizing gap from chattiness is usually a multiplier between three and ten. A workflow that a batch-savvy client accomplishes in four calls will fire between twelve and forty calls from a chatty client. The multiplier is stable per client but varies widely across clients in the same deployment.
Add a chattiness multiplier column to the sizing plan. If the deployment serves multiple client implementations, use the worst-case multiplier for the peak sizing and the average for the steady-state. For related batch counter-patterns, how batch endpoints inflate your effective FHIR RPS budget covers the other side.
Detecting Chattiness in Production
Chattiness shows up as high request counts per session with low bytes per request. Access logs that report both metrics make chatty clients easy to spot: hundreds of requests per user session, each returning a single small resource.
Deployments that only report aggregate RPS miss the pattern. Reports that break out per-client-implementation RPS surface it immediately.
Fixing the Client vs Scaling the Server
The right fix for chattiness is a client change: switch to _include, adopt batch reads, or turn on eager loading in the SDK. The wrong fix is to scale the server to absorb the pattern, which is expensive and does nothing to help the client's own latency.
That said, sometimes the client is out of scope for a quarter. In that window the sizing plan needs to hold against the chatty pattern, which usually means larger cache tiers and more read replicas.
Reading Sizing Case Studies
The FHIR community's scaling talks routinely name chatty clients as a caution. Reading those talks with an eye for the multiplier saves calibration time later. For the reading habit itself, reading DevDays scaling talks like a capacity planner is the accompanying method.
Naming the chattiness multiplier explicitly is how RPS estimates stop lying.
Sources
- HL7 FHIR core specification of search including the - HL7 FHIR core specification of search including the _include parameter that fixes chatty read patterns