Redundancy Is Not Reliability: What Healthcare Technology Gets Wrong About Distributed Systems

Healthcare organizations have spent years treating redundancy, having infrastructure in reserve, as a substitute for reliability. The two are related, but they describe different properties. Redundancy adds spare capacity or components; reliability is whether a system performs consistently under expected conditions. Whether it keeps working when a component fails is a separate question again, one of resilience and fault tolerance. A recurring pattern in healthcare IT is to add infrastructure without asking whether applications can isolate failures and recover cleanly. Clinical workflows can still collapse when a single upstream component degrades, not because infrastructure is thin but because the application was never built to absorb failure. A scheduling service slows, lab order visibility goes with it, and more hardware does not fix that.

The problem is architectural, not infrastructural. Many healthcare platforms are organized around business functions instead of around how components actually fail, so services that look separate can still depend on the same synchronous calls, shared integration layers, and transformation logic. When one component slows, retries pile up, adjacent workflows stall, and latency spreads before anyone can isolate the cause. That is why modernization programs do not automatically improve resilience. Moving workloads to the cloud or breaking a monolith into services will not reduce coupling if the critical dependencies stay tightly connected. A platform can become more distributed without becoming more resilient if its failure boundaries were never deliberately designed.

Tathagata Roy is a technology architect who has worked on distributed systems in operationally sensitive parts of healthcare technology, including service-based platforms for a large U.S. kidney care provider and health information exchange infrastructure connecting hospital networks and third-party clinical systems. In these environments, a poorly defined service boundary or a tightly coupled integration layer can affect care alerts, clinical workflows, or the accuracy of patient matching. Roy’s approach to healthcare reliability comes out of designing around those consequences directly, rather than treating them as engineering problems in isolation.

One example of this is Roy’s work modernizing a legacy electronic health record platform for a large U.S. kidney care provider. The system began as a monolithic desktop application, where scheduling, lab orders, treatment records, and patient search all shared the same runtime and failure boundary. When one component slowed under load, the effects spread into clinical workflows at dialysis centers. Roy’s view was that splitting the platform into services was the easy part. The harder discipline was deciding which components needed to fail independently to protect care delivery. That led to separate services for treatment scheduling, patient search, and lab order integration. Patient search used a Command Query Responsibility Segregation approach, letting read-heavy queries across a large clinical dataset run against a dedicated search index instead of competing with the transactional write path used for treatments. That kept search activity and lab-feed degradation from dragging down core scheduling. Roy applied the same principle to service communication, moving clinical events, including admissions, lab results, and treatment updates, onto an event-streaming backbone, so services could interact asynchronously and downstream consumers could recover without necessarily interrupting whatever produced the event. He also invested in production observability, on the reasoning that decoupling services without improving failure detection just makes fragility harder to find, not less real.

Healthcare integration is where Roy sees distributed-systems problems become most visible. Building health information exchange infrastructure across hospital networks and third-party clinical systems left him convinced that reliability depends not just on how individual services are designed, but on the agreements that govern how those services interact. He pushed teams to treat interface contracts as core engineering artifacts: document them, version them, and make them discoverable across teams. API gateways could then check those rules at runtime, while interoperability standards gave services a common basis for behavior. That combination gave distributed teams a clearer reference point and made integration failures easier to isolate. Roy also treats patient identity resolution as a reliability issue. When two systems fail to connect information to the correct patient, clinicians may not be able to act on it, and alerting workflows may not be able to route it, even if the underlying applications are running fine. For Roy, accurate patient matching across integration boundaries belongs next to uptime and latency in any real conversation about healthcare-system reliability.

His research has examined the same challenge from the perspective of healthcare data exchange. One of his papers, titled “A Cloud-Based PaaS for Secure and Interoperable Healthcare Data Exchange,” explores this area. In one study, Roy explored a cloud-based platform designed to bridge legacy healthcare data formats with modern, API-driven interoperability. The work focused on making clinical information easier to exchange across heterogeneous systems while maintaining security, identity management, auditability, and data integrity. Roy’s broader view, reflected in the research, is that healthcare platforms need dependable boundaries through which information can be exchanged and trusted, not just moved. The work also examined how cloud-native architecture could support the transformation of older document-based clinical data into more granular, standardized resources for modern applications.

The thread running through Roy’s work is that reliability in distributed healthcare systems gets built at the boundaries between components: service exchanges, system integrations, patient identity resolution, and the data pipelines behind AI-assisted clinical workflows. Spending more on infrastructure cannot substitute for that discipline, and moving a system to the cloud does not fix boundaries that were poorly designed to begin with. As healthcare organizations bring in more AI-assisted tools for clinical and operational work, isolating failures and keeping information trustworthy stops being a nice-to-have and becomes something the architecture has to handle from day one.