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 failure modes they saw along the way. Read as war stories, the talks are entertaining. Read as capacity-planner reference material, they are a shortcut past a lot of expensive learning.
The trick is knowing what to pull out of a talk and what to ignore. For related planning reading, the digital health FHIR primer collects the surrounding pieces.
The Numbers That Actually Transfer
Not every number in a scaling talk applies to a different workload. Total RPS is the least transferable metric; it tells you what one deployment handled, not what a different one will. Read/write ratio, batch amplification factor, cache hit ratio, and chattiness multiplier are more transferable because they describe the workload shape rather than the absolute throughput.
Pull the ratios and multipliers out first; treat the absolute numbers as bounds only. A pass through the site's FHIR server throughput sizing widget can turn a set of ratios into a sizing bracket without borrowing the presenter's total number.
The Workflow Descriptions
The workflow description is often more valuable than the numbers. When a presenter says "we scaled ADT ingestion to five hundred writes per second and observed X", the workflow ADT ingestion is what tells you whether that number applies to your case. If your workflow is chart review, the ADT number is a data point about a different problem.
Read the workflow description first, then decide whether the numbers are relevant. Talks that spend two minutes on the workflow and thirty seconds on the numbers are usually the ones worth trusting.
The Failure Modes Section
Every good scaling talk has a section on what broke. Cache stampedes, subscription cascades, transaction lock contention, index bloat. These are the sections that pay for the whole talk.
Failure modes transfer more reliably than success modes. A cache stampede that hit one team will hit another team eventually. Extract the failure mode and the fix, add both to your operational runbook before the deployment ever needs them. For the chatty-client failure mode specifically, when RPS estimates lie: the cost of chatty FHIR clients covers the pattern in its own piece.
The Hardware and Config Baseline
Talks that name their hardware and configuration baseline let you calibrate against your own. A talk that reports numbers on a specific database engine and a specific server tier is far more useful than one that reports numbers on unspecified infrastructure.
If the baseline is not named, treat the numbers as directional only.
What to Ignore
Ignore the marketing framing. Ignore the future-roadmap slides. Ignore the customer testimonials, which are almost always speaking about a different workflow than the one you are sizing.
Focus on the sections that describe the workload, the ratios, and the failure modes. Those are the sections that answer capacity questions.
Building a Reading Habit
The habit that pays off is quarterly reading through the newest talks in the community. Twenty minutes of skimming, notes on the ratios and failure modes, a short update to the internal capacity model. The compounding effect over a year is meaningful; the compounding effect over three years is enormous.
For the workflow-to-RPS translation that turns the reading into a plan, translating clinical workflow into FHIR API load is the accompanying method. Reading DevDays talks as a planner is one of the highest-return uses of an hour a quarter can buy.
Sources
- FHIR DevDays canonical session library housing community - FHIR DevDays canonical session library housing community scaling talks and connectathon reports