The first bulk export a FHIR deployment runs against production is usually the moment somebody discovers that exports and interactive traffic do not play well on the same server. The export finishes; the clinicians report that the app was slow for an hour; the postmortem names the export as the cause. Planning around traffic windows is the discipline that keeps that discovery in staging rather than production.
Naming the schedule explicitly is the trick. For related walkthroughs, related FHIR walkthroughs collects the surrounding material.
The Interaction With Interactive Traffic
Exports read from the archive and hold pool slots while they serialize resources. Every slot the export holds is a slot the interactive workload cannot use. When the interactive workload bursts, requests queue behind the export's slots.
The disciplined pattern is to schedule exports into traffic valleys where the interactive workload is quiet. A pass through the site's export duration estimator helps you bracket whether the export will fit in a specific window.
Naming the Valleys Explicitly
Every FHIR deployment has traffic valleys. Overnight hours are the most common. Weekends work for some workloads; holidays for others. Naming the valleys per deployment is the first step in scheduling exports around them.
The valley schedule should be documented and shared. Exports that get scheduled outside the valley need explicit approval and a rate limit.
Rate-Limiting the Export
The mitigation that actually protects interactive traffic during an export is a rate limit. Cap the export to a percentage of total capacity while it runs. Thirty percent is a reasonable starting point; adjust based on measurement.
The export takes longer at a lower rate. That is the trade. For the specific driver framing that shapes the rate-limit sizing, the four things that dominate $export duration covers the shape.
Multiple Concurrent Exports
Some workloads run more than one bulk export at once. When two exports contend for the same persistence tier, both slow down and the interactive workload experiences the sum of their impact.
Deployments that support concurrent exports should carry an aggregate export budget. The budget caps total export I/O regardless of how many exports are running.
Cancellation as a Circuit Breaker
Every scheduled export should have a defined maximum duration. When the export exceeds the duration, the client should cancel it and reschedule. The cancellation prevents runaway exports from bleeding into the next traffic window.
For the specific abort framing, when to abort a stuck bulk export covers the decision criteria. Every deployment that runs bulk exports at scale benefits from a defined circuit breaker.
Communicating With Clinical Teams
Exports scheduled against production traffic should be visible to the clinical operations team. Even well-behaved exports can produce brief latency spikes at cache-eviction moments; giving the clinical team advance notice reduces the escalation cost when a spike arrives.
The notice does not need to be elaborate. A shared calendar entry that names the export, its expected duration, and the mitigation is enough.
Reporting After the Fact
Every export should emit a summary: duration, throughput, contention observed, mitigations triggered. The summary becomes the input to the next planning round. Deployments that track summaries over time build a real benchmark of their own workload. For the prediction framing that this feeds, predicting how long a bulk data $export will actually take is the accompanying reference.
Every bulk-data operation that lands well shares the same posture: pick the valley, rate-limit the export, cap the duration, communicate the plan.
Sources
- HL7 FHIR Bulk Data Access IG - HL7 FHIR Bulk Data Access IG, canonical spec for scheduling patterns