🚨 Urgent Medplum Performance Help We are running into significant performance degradation due to high-volume

_count

requests hitting our write cluster. We need a short-term fix to stabilize performance while we work on a long-term architecture change. The Problem Our application relies on inbox counts for

ServiceRequest

resources (a ServiceRequest can belong to multiple inboxes). We are polling periodically for these counts. * Impact: CPU spikes to 100% on the cluster, and all requests (not just counts) slow down/fail (Memory/IO are low/fine) * Load: We're generating Users X Inboxes X Polling Rate = hundreds of simultaneous

_count

requests Technical Details & Questions 1. Read Replica Utilization: Our cluster has one write and one underutilized read replica. All these

_count

requests are hitting the write replica * Q1: Is there a standard way to force these specific read-only requests (

_count

) to the read replica? Or read-request round-robin? 2. Medplum Version: We are on v2.1.4 (yes, we know 😬) * Q2: Can we expect a performance by prioritizing an upgrade? 3. Accuracy vs. Performance *

_total=accurate

is the culprit *

_total=estimate

is too inaccurate * Q3: Will the

accurateCountThreshold

setting help balance speed and accuracy for our specific issue? 4. GraphQL Aggregation: * Q4: Can we use a single GraphQL query to perform these count aggregations in one call, reducing the N-query problem to a 1-query problem? > Count Request Example: >

/fhir/R4/ServiceRequest?_count=0&_filter=authored%20pr%20false&_tag:not=archived,needs-review&_total=accurate&identifier=titan-intake::InboxStatus|registration

We appreciate any help!

Mike - can you post in #1094022380659155005 pls? 🙏

yup, will do!

no need!