Modernizing legacy clinical systems and cutting structural cost
An on-premise clinical platform (collecting and routing patient biometric data from connected medical devices to care teams) had hit the scaling and reliability limits of running as a single monolith on fixed hardware. This case study details how it was decomposed into managed, containerized services, alongside structural cost-reduction patterns applied across multiple engagements.
At a glance
- Problem
- An on-premise clinical platform past the scaling limits of fixed hardware, where heavy reporting queries competed with real-time device ingestion on the same database.
- Approach
- Containerized microservices on managed Kubernetes, an in-memory caching layer, and a streaming analytics pipeline so dashboards never touch the operational database.
- My contribution
- Application modernization & cost-aware infrastructure design
A monolith that couldn't scale with the data it was collecting
The platform ingests a continuous stream of biometric telemetry (vitals like blood pressure, pulse, glucose, and oxygen saturation) from thousands of connected patient devices, and routes it to clinical teams for real-time monitoring and historical trend review. It had been built and run as a single on-premise application, and that design was showing its limits in three specific ways:
- Fixed hardware couldn't absorb device growth. Every new batch of connected devices meant provisioning more physical capacity ahead of time, whether or not it was needed yet.
- Reporting queries competed with live ingestion. Clinical dashboards querying historical vitals ran against the same database handling real-time device writes, so heavy report load could visibly slow down live data ingestion.
- Deployment and disaster recovery were manual. Shipping a change or recovering from a failure both depended on a person following a runbook by hand, which put a ceiling on how fast either could happen.
Decomposing the monolith into managed, independently-scaled services
The application was re-architected into a set of containerized microservices running on managed Kubernetes, with a deliberate split between the two primary workload profiles: handling live device and portal traffic, and running analytics on the history of that data.
Ingress & application tier
Analytics & reporting tier
Network & access control
Multiple independent application APIs share one load balancer instead of provisioning one per service: a small decision that has a real cost effect once you're running more than a handful of services, covered in the outcome below.
Taking reporting traffic off the live database entirely
Rather than scaling the operational database up to absorb both live writes and heavy analytical reads, the architecture decoupled the two: vitals stream out of the application tier into a purpose-built real-time analytics pipeline, and clinical dashboards query that pipeline instead of the production database.
How a vitals reading reaches a clinician's dashboard
Applying the same discipline across several engagements
This pattern (right-sizing compute instead of running static, always-on fleets) wasn't unique to one platform. Across several client engagements during the same period, a consistent set of cost levers was applied:
| Lever | What it replaced |
|---|---|
| 1 | Dynamic, right-sized compute in place of statically-provisioned server fleets sized for peak load year-round. |
| 2 | Shared load balancers across grouped services instead of one dedicated load balancer per microservice. |
| 3 | Graviton-compatible node pools where workloads allowed it, alongside legacy-compatible nodes for what couldn't move yet. |
| 4 | Automated deployment and disaster-recovery pipelines in place of manual, runbook-driven processes. |
None of these are exotic individually: the value was in applying all of them consistently, with actual financial modeling behind each recommendation rather than a generic "move to cloud-native" pitch.
What changed
The clinical platform now scales its application tier independently of its analytics tier, absorbs new device growth without pre-provisioning hardware, and ships changes and recovers from failure through automation instead of a person following a checklist under pressure.
Questions about this case study?
I'm happy to go deeper on any part of this: the service decomposition, the analytics decoupling, or the cost-modeling approach.
anupojuprudhvi@gmail.com