Why Traditional Webhooks Break Under RPM Load

Om Jariwala — Fri, 02 Oct 2026 05:32:03 +0000

A webhook works fine when your system is small.

But when you start handling FHIR data, RPM devices, patient observations, alerts, and hundreds of events, the simple:

Device → Webhook → API → Database

model can become a problem.

The issue isn't the webhook itself.

It's making the webhook responsible for everything.

RPM Device
    ↓
Webhook
    ↓
Validate
    ↓
Transform to FHIR
    ↓
Save Data
    ↓
Run Clinical Rules
    ↓
Send Alert

Now imagine hundreds of devices doing this at the same time.

One slow dependency can hold up the entire request.

A better approach

Use the webhook for ingestion and move the heavy work into an event-driven pipeline.

RPM Device
    ↓
API / Webhook
    ↓
Message Queue
    ↓
Workers
    ↓
FHIR Processing
    ↓
Clinical Rules
    ↓
FHIR Server / Database
    ↓
Notifications

The queue gives your system somewhere to hold events when traffic spikes or a downstream service is temporarily unavailable.

It also makes retries much easier.

Don't forget duplicate events

Distributed systems can deliver the same event more than once.

So your pipeline should be idempotent.

Receive Event
      ↓
Check Event ID
      ↓
Already Processed?
   ↙          ↘
 Yes           No
 ↓             ↓
Ignore       Process

The goal is simple:

Processing an event twice should not create incorrect clinical data.

What about FHIR?

An RPM reading might become a FHIR Observation:

{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "8480-6",
      "display": "Systolic blood pressure"
    }]
  },
  "valueQuantity": {
    "value": 142,
    "unit": "mmHg"
  }
}

But creating the FHIR resource is only one part.

You still need to handle:

Patient and device identity
Duplicate events
Out-of-order events
Retries
Validation
Clinical rules
Auditability

The real question

Don't ask only:

“Does my webhook work?”

Ask:

“What happens when 10x the events arrive, the FHIR server goes down, or the same event arrives twice?”

That's where architecture starts to matter.

A webhook should tell your system:

“Something happened.”

It shouldn't necessarily be responsible for everything that happens next.

For RPM and FHIR systems, separating ingestion from processing gives you a much stronger foundation for scaling and reliability.

DEV Community: Om Jariwala

Why Traditional Webhooks Break Under RPM Load

A better approach

Don't forget duplicate events

What about FHIR?

The real question