Capacity plans that treat FHIR writes and reads as one throughput budget almost always under-provision the write side. The two operations look similar on the wire: an HTTP request in, an HTTP response out. The database work behind them is different by an order of magnitude, and the cost that matters for sizing is the database work, not the wire work.
For the wider set of capacity walkthroughs, additional FHIR walkthroughs collects the surrounding material. This piece stays on the specific split between reads and writes.
Reads Hit a Small Number of Indexes
A well-tuned FHIR read hits one or two indexes on the FHIR server's database. The response comes back in a few milliseconds under normal load. Read-heavy workloads can push tens of thousands of RPS through a modest server tier because the database work per request is small.
Caching amplifies the read side further. Reference resources sit behind edge caches; patient-scoped reads sit behind session caches. The result is that read RPS is largely a network and CPU problem, not a database problem.
Writes Trigger a Cascade
A single FHIR write is not one database operation. It is at minimum an insert, a set of index updates, and a version-history append. On many FHIR servers it also fires a subscription evaluation, an audit-log entry, and a search-parameter reindex. Under a mature deployment the write can trigger four or five downstream jobs before the HTTP response even returns.
Sizing that ignores the cascade under-counts write cost. A pass through the site's FHIR server throughput sizing widget accounts for the difference when the write ratio is entered explicitly.
Batch Writes Are Sneaky
A batch or transaction Bundle looks like one write on the ingress side but expands into N writes on the persistence side. A twenty-entry transaction Bundle is twenty inserts plus twenty index updates plus twenty subscription evaluations, all committed atomically.
Capacity plans that treat batch endpoints as one write per HTTP request under-size the database tier by an order of magnitude when transactional workflows dominate. For the specific batch expansion math, how batch endpoints inflate your effective FHIR RPS budget covers the accounting.
The Ratio That Actually Matters
The single number that separates a well-sized deployment from an under-sized one is the read/write ratio. A read-heavy workflow (analytics, reporting, chart review) tolerates a modest write tier and benefits from aggressive caching. A write-heavy workflow (ingestion, streaming ADT, order entry) needs the write tier sized for the peak burst rate.
Mixed workloads are the tricky case. When the ratio shifts across the day, the sizing has to hold at both extremes. For the mixed-workflow planning method, planning read/write ratio for a mixed FHIR workload walks through the tradeoffs.
Sizing Implications
The practical implications are three:
- Size the read tier for peak read RPS with cache hit ratios factored in.
- Size the write tier for peak write RPS plus batch amplification.
- Size the database persistence layer for the write cascade, not the write RPS alone.
Every capacity plan should carry these three numbers separately. Plans that report a single total RPS number hide the split and inherit the risk of under-provisioning the write path.
The Test That Reveals the Split
The test that surfaces the split is a synthetic load run at the actual expected read/write mix. Running only reads at 500 RPS says nothing about how the server behaves at 450 reads plus 50 writes. The two workloads exercise different parts of the stack, and the interaction is exactly where naive sizing gets caught out.
Naming the write side of the RPS budget as its own line item is the shortest path to a plan that survives the first month of production traffic.
Sources
- HL7 FHIR core specification of HTTP interactions covering - HL7 FHIR core specification of HTTP interactions covering create, update, and history semantics behind writes