Performance & Scalability
TL;DR / Key Takeaways
- •Default: 2 × Fargate tasks (1 vCPU / 2 GB each) across 2 Availability Zones — auto-scales to 4.
- •Target Tracking auto-scaling on 70% CPU with 300-second cooldowns.
- •Scale vertically up to 4 vCPU / 16 GB per task, or horizontally to 16+ tasks — via a CloudFormation parameter change.
- •SQS message buffering recommended for high-volume inbound feeds to decouple ingestion from processing.
- •External EHR response time — not ConnectHealth — is the dominant latency factor in most workflows.
Healthcare integration sits on the critical path between hospital systems, EHR vendors, and clinical applications. When a 500-bed hospital's ADT feed spikes during morning shift change, or a remote monitoring program pushes thousands of observations per hour, your integration layer must keep up without dropping messages.
This page provides a transparent, technical overview of our infrastructure, how it scales, and where the real bottlenecks lie.
1. Default Infrastructure Profile
ConnectHealth deploys into your own AWS VPC via a single CloudFormation template. The default baseline is designed to be cost-efficient for evaluation, development, and standard production workloads — you only pay for the compute you use. Every resource is HIPAA/SOC 2-tagged and encrypted at rest with KMS.
| Component | Default Specification |
|---|---|
| Compute | AWS ECS Fargate (serverless containers) |
| Task Size | 1 vCPU (1,024 CPU units), 2 GB RAM |
| Min Running Tasks | 2 (across 2 Availability Zones) |
| Max Running Tasks | 4 (auto-scaling) |
| Networking | Private subnets, NAT Gateway, ALB with TLS termination |
| Storage | Encrypted EFS (AES-256 via KMS), shared across tasks |
| Container Insights | Enabled — CPU, memory, network metrics to CloudWatch |
| Log Retention | 365 days (ops), 6 years (HIPAA audit trail) |
| Health Checks | HTTP /api/healthCheck every 60s, 5-min startup grace, 5 retries |
All values above are taken directly from our production CloudFormation template. Nothing is estimated.
2. What Happens to Every Message
Understanding capacity requires understanding the layers each message passes through. ConnectHealth is built on a high-concurrency, event-driven runtime with an embedded visual Workflow Engine.
Inbound HTTP/REST Workflows (FHIR webhooks, API triggers)
Inbound HTTPS → ALB (TLS termination)
→ CORS → Correlation ID → Auth (JWT / API key via Secrets Manager)
→ Workflow Engine routes to configured flow
→ Custom nodes execute (FHIR read, transform, deliver)
→ Audit log → Response returned
Inbound HL7v2/MLLP Workflows (real-time ADT feeds)
Inbound TCP (port 2575) → MLLP frame validation
→ HL7v2 Parser (MSH validation, JSON structuring)
→ Liquid Template Mapper → FHIR R4 bundle
→ Auth Backend (OAuth token, cached)
→ FHIR Create/Update → HL7 ACK (AA/AE) returned
→ Audit log written
Key Architecture Points
Event-Driven Architecture
Our non-blocking, event-driven runtime handles many concurrent connections efficiently. CPU-bound transforms (large templates) are the main limiter.
EFS Token Storage
OAuth tokens stored on encrypted EFS as JSON files. Synchronous writes ensure immediate cross-container availability.
Async Audit Logging
CloudWatch writes are non-blocking and batched. Audit does not impact message latency.
3. Where the Bottlenecks Actually Are
We believe transparency builds trust. Here is where the real capacity limits sit:
| Layer | Type | Impact |
|---|---|---|
| Workflow Engine runtime | CPU-bound | Determines max throughput for transform-heavy flows |
| OAuth token acquisition | Network I/O | First call per token lifecycle is slow (200–1,000ms); subsequent use cache |
| FHIR server response | External | Downstream EHR is almost always the dominant latency factor |
| Token storage writes | Disk I/O | Sync writes add ~1–5ms per operation |
| Secrets Manager lookups | Network I/O | ~10–50ms on first request, then cached in-memory |
| Template rendering | CPU-bound | Scales with template complexity and payload size |
Key insight: For most real-world healthcare workflows, the external EHR system's response time — not ConnectHealth — determines end-to-end latency. If Epic's FHIR endpoint responds in 300ms, your pipeline will take ~300ms + processing overhead regardless of ConnectHealth's internal speed.
4. Auto-Scaling Behavior
ConnectHealth uses AWS Application Auto Scaling with Target Tracking on ECS service CPU utilization.
| Parameter | Value |
|---|---|
| Metric | ECSServiceAverageCPUUtilization |
| Target | 70% |
| Scale-Out Cooldown | 300 seconds (5 min) |
| Scale-In Cooldown | 300 seconds (5 min) |
| Min Capacity | 2 tasks |
| Max Capacity | 4 tasks (configurable) |
Steady state: 2 tasks across 2 AZs, CPU at ~10–30%.
Load spike: Average CPU crosses 70% → ECS provisions a 3rd task (~2 min to pass health checks).
Sustained peak: CPU stays above 70% after cooldown → 4th task launches.
Load subsides: CPU drops below target → tasks scale back in after cooldown, never below 2.
Zero-downtime scaling: The ALB waits for new tasks to pass health checks before routing traffic. Existing tasks continue serving during scale events.
5. Best Practice: SQS Message Buffering for High-Volume Feeds
For enterprise deployments handling high-volume inbound feeds (real-time ADT from multi-facility hospital systems, bulk RPM device streams, or HIE-level event firehoses), we recommend placing an Amazon SQS queue in front of the Workflow Engine as a message buffer.
Source System (HL7/FHIR/webhook)
→ Amazon SQS Queue (encrypted, KMS)
→ ConnectHealth Workflow Engine polls and processes
→ Dead-letter queue captures failed messages for retry
Why SQS?
Decoupled Ingestion
Source systems can fire-and-forget. SQS absorbs burst traffic even if the Workflow Engine's auto-scaling hasn't caught up yet — zero message loss.
Backpressure Management
If a downstream EHR endpoint slows down, messages queue safely in SQS instead of timing out at the source. Processing resumes automatically when capacity frees up.
Dead-Letter Queue (DLQ)
Failed messages automatically route to a DLQ after configurable retry attempts. No message is silently dropped — every failure is captured for investigation.
Built-In Encryption
SQS queues use the same customer-managed KMS key as the rest of your ConnectHealth stack. Messages containing PHI are encrypted at rest and in transit.
ConnectHealth's IAM task role already includes full SQS permissions (
sqs:CreateQueue,sqs:SendMessage,sqs:ReceiveMessage,sqs:DeleteMessage, etc.) scoped to the project namespace. No additional IAM configuration is needed.
This pattern is especially relevant when:
- Your source system sends > 100 messages/second at peak and you cannot tolerate dropped messages.
- You need guaranteed delivery across maintenance windows or deployment updates.
- Multiple source systems feed into the same workflow, and you want to normalize ingestion through a single queue.
6. Scaling Beyond Defaults
The default baseline keeps costs low while handling standard production workloads comfortably. When your volume grows — multi-facility rollouts, high-frequency RPM feeds, or HIE-level ingest — our team works with you to right-size the infrastructure for your specific workload. Every parameter is a CloudFormation override, no code changes required.
Vertical Scaling (Bigger Tasks)
| Tier | CPU | Memory | Best For |
|---|---|---|---|
| Default | 1 vCPU | 2 GB | Development, low-traffic production |
| Medium | 2 vCPU | 4 GB | Single hospital, moderate ADT + FHIR volume |
| Large | 4 vCPU | 8 GB | Multi-facility, high-frequency RPM feeds |
| XL | 4 vCPU | 16 GB | Large bulk exports, batch transforms |
Fargate supports up to 16 vCPU / 120 GB per task if needed.
Horizontal Scaling (More Tasks)
Increase MaxCapacity in the CloudFormation stack:
| Max Tasks | Use Case |
|---|---|
| 4 (default) | Standard single-facility workloads |
| 8 | Multi-site health systems |
| 16+ | HIE-level ingest or high-frequency RPM at scale |
7. What to Monitor
| Metric | Where | Action Threshold |
|---|---|---|
| CPU utilization | Container Insights | Sustained > 70% → scale vertically or horizontally |
| Memory utilization | Container Insights | Sustained > 80% → increase ContainerMemory |
| Processing latency | Application logs | > 100ms → workflow too CPU-heavy; optimize or scale |
| SQS queue depth | CloudWatch SQS metrics | Growing backlog → add more tasks or increase task size |
| EHR response time | Workflow audit logs | > 500ms → bottleneck is external; contact EHR vendor |
8. Pre-Production Recommendations
1. Run a Load Test
Use Artillery or k6 against your specific workflow endpoints. Measure actual throughput under your payloads and templates.
2. Size Your Stack
Observe CPU and memory under expected peak load, then select the appropriate task tier from the table above.
3. Monitor Processing Latency
This is the leading indicator of workflow bottlenecks in the first week of production. Sustained latency spikes mean your workflow is too CPU-heavy for the current task size.
4. Add SQS for High-Volume Feeds
If your source sends burst traffic or you need guaranteed delivery across deployments, front the workflow with an SQS queue.
We partner on infrastructure tuning during onboarding. The default baseline is designed to get you running quickly and cost-effectively. When you're ready for production-grade volume, our team helps you benchmark your specific workflows, select the right task tier, and configure auto-scaling thresholds — so you're never over-provisioned or under-prepared.
What's Next?
- Security Architecture — Zero-trust deployment, encryption, and AI guardrails
- Workflow Builder — Visual workflow engine, node catalog, and pipeline design
- HIPAA Compliance — BAAs, audit trails, and compliance controls