FHIR DevDays and connectathon presentations are one of the few public sources of real production scaling numbers. Vendors talk about the peak RPS their platform handled at a specific customer, the workload mix that drove it, and the...

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...

Mixed FHIR workloads are the rule in US healthcare integrations. The same deployment carries chart review, order entry, ingestion feeds, and analytics extracts on the same hardware. Each of those has a different read/write ratio, and the...

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...

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...

Read RPS estimates for a FHIR API tend to arrive dressed as a single confident number. In practice the honest estimate is a product of a small set of inputs, and knowing which inputs matter is the difference between a sizing exercise that...

Every FHIR API sizing exercise runs into the same wall in the first week: nobody actually knows what production traffic will look like yet. The workflows are half-designed, the integration partners have not signed off on their access...