01
SCP Health:
Technical Deep Dive
Date
July 2026
Presented by
Describe
02
SCP HEALTH · TECHNICAL DEEP DIVE
Meeting Agenda
01
Data Pipeline
02
Scalability
03
Architecture
Most of our time
04
Product
05
Team
06
Your Feedback
03
Agenda · 01
Data Pipeline
04
Data Pipeline
Questions regarding Snowflake
01
Which sources are being unified into Snowflake — QGenda, Athena, Salesforce?
02
What's the timeline, and what's completed so far?
03
Build direct integrations first, then migrate to reading from Snowflake?
04
Is API access to all three sources available now, or does it need to be set up?
05
Will facility-sourced metrics (e.g. LWOT) feed into Snowflake under this initiative?
05
Data Pipeline
The Data Center
A configurable ETL pipeline that ingests any operational metrics data and translates it into our unified schema — our solution to the ingestion problem.
Ingests
Shift · Visit / Encounter · RVU · Dispensing / Prescription · any operational metric
Formats: CSV, XLS, XLSX, SQL
Intake Methods
Direct application upload
SFTP to S3 (AWS Transfer Family)
API — JSON or FormData
Connectors
Live today
QGenda · ShiftAdmin · Athena · Tableau · Cerner · Epic
Custom builds for you
Salesforce · Snowflake · facility exports · your QGenda setup
06
Data Pipeline
Your data-unification goals
Aligning the payroll initiative with your Snowflake initiative is top-of-mind — we're 100% ready to support it.
01
We can write to Snowflake
Facility-sourced quality metrics not yet in Snowflake can be written back to it by us.
02
Unified schema either way
Payroll already requires mapping these sources onto one SQL schema via our Data Center.
03
Syncing approach
Proposed ideas for how syncing with Snowflake will work will be covered in the Architecture section.
07
Agenda · 02
Scalability
08
Scalability
Overview
The central concern is whether Describe can handle your scale. You are roughly 40x our largest payroll customer in clinician count. We'll address it from three angles.
01
Architecture
Where we'll start today.
02
Product
03
Team
09
Scalability
Storage
Dimension (annual, SCP volumes)
Engineered ceiling
Basis
Shift records incl. exceptions
0.5 GB
223 B/row measured; 9.1 shifts/provider/month
Encounter data
FLEX-105
6 GB
390 B/encounter fully indexed; 8M/yr
Pay ledger, true-ups, adjustments
REQ-805 · REQ-304
2–3 GB
Append-only corrections; estimate + actual + delta
Audit trail and lineage
REQ-803 · REQ-804
10–20 GB
Before/after row images on every change
Total database growth per year
25–30 GB
Dominated by audit instrumentation
Seven-year SOX retention
REQ-1106
200–250 GB
Cold history partitions and tiers to low-cost storage, auditor-retrievable throughout
10
Scalability
Compute & Concurrency
Measured today
160
ms / provider
A full monthly payroll run, that iterates through each shift, for 200 clinicians measured in production — 20.4 s
At 7,500 clinicians
~13
min single-threaded
Parallelizable across facilities →
under 1-minute
Concurrency
Payday spike, fully isolated
The payday spike load hits our always-on API tier under AWS Fargate (ECS), which scales by adding stateless replicas - separate from the calculation engine. Portal traffic can't slow a pay run, and a pay run can't slow the portal.
11
Agenda · 03
Architecture
12
Architecture
13
Architecture
Hardware
This is our starting configuration. Final sizing will be based on measured load;
re-sizing after go-live takes minutes, not a re-architecture.
RDS PostgreSQL · Multi-AZ
db · r6g / r7g · xlarge–2xlarge
4–8 vCPU · 32–64 GB RAM. ~310 GB 7-yr ceiling, working set far smaller.
Calc worker pool · Fargate
8–16 tasks × 4 vCPU / 2–4 GB
Scales with facility count.
API service · Fargate
2 tasks × 1–2 vCPU / 2–4 GB
Small always-on baseline, autoscaling on the payday spike.
Ingestion · Data Center
2 vCPU / 4 GB
Well-equipped for upper-bound ingestion load estimates.
Lambda · Outbox drainer
Per-invocation · 0.5–1 vCPU
Drainer is a small always-on Fargate task.
14
Architecture
Scaling
Horizontal
Calculation worker pool
Easy to parallelize. Adding workers increases throughput linearly.
API service
Stateless replicas autoscale on the payday spike, then scale back down.
Ingestion
One independent task per source - more sources, more concurrent tasks.
Lambda event tier
Approvals, exceptions, expenses invoke concurrently. AWS scales to demand.
Vertical
RDS PostgreSQL
A single primary is the right choice for a SOX-compliant transactional system of record. Resize in minutes; poolers keep connections flat under any fan-out. Plan for two orders of magnitude of headroom.
No event where "SCP growth" means "rearchitect." Everything is built to scale.
Known boundary
~50,000 clinicians
a config change at the queue
15
Architecture
16
Agenda · 04
Product
17
Product
Scaling
70
CORE — plan builder · ingestion / ETL · calc logic · payroll run & output · clinician view
30
BUILD — folds into core
Built for you, on the roadmap
Intelligent alerting
Eligibility & payout anomaly detection.
Approval chains
Feature-flagged, maintained in every release - existing clients want these too.
Expense management
Submission, review, and reimbursement in-flow with payroll.
Anything else
Whatever it takes for a 10/10 payroll process.
How we deliver it
Timeline unchanged
Custom work is already factored into the proposed plan to deliver accurate calculations by the end of month 3 and a full rollout by end end of month 6.
Long-term Support
—Access to all product updates
—1-2 dedicated engineers forever
—Scaled-up team involvement for events like a data-source migration
We iterate until we hit
100%
accurate payroll calculation
+ all other requirements from the PRD
18
Agenda · 05
Team
19
Team
Experience with scale
Safe reprocessing at volume
The payroll-defining problem: re-run computations over huge historical datasets when rules change, without breaking live ingestion. Every re-run idempotent.
Luiz — trade-marketing data platform ingesting and reprocessing ~1.2 TB/month; safe historical recomputation alongside ongoing ingestion. This is analogous to our true-up and 5-month-lookback problem.Correctness at volume
Money-moving flows where a single edge case is a real refund or a mispayment.
Marcos — payments, registrations, memberships across 1,500+ businesses; the discipline behind our zero-unexplained-variance parallel run.Large tables staying fast
The challenge isn't storing data, it's keeping queries performant as tables grow into tens of millions of rows.
Matheus — 50M-row log where dashboards had slowed to 4-second queries; diagnosed Postgres autovacuum behavior and brought them back to 450ms, no re-architecture. Why our audit ledger is partitioned and tiered from day one.Bursty, synchronized load
Traffic that surges predictably and must be provisioned according to peaks, not averages.
Matheus — queue-based checkout redesign for Black Friday spikes. Luiz — municipal education platforms, hundreds of thousands taking attendance in the same hour; provisioned for the peak.Mission-critical uptime
Systems where an outage is a financial event for someone else.
Matheus — municipal parking, 6M+ users, where downtime meant citizens ticketed and lost municipal revenue.20
Agenda · 06
Your Feedback
21
Your Feedback
Open discussion for feedback, questions, or concerns.
22