When a health interoperability startup asked me to design their data exchange system for African hospitals, I discovered something most tech companies refuse to acknowledge: the problem isn't the technology - it's the infrastructure.
This article is just a condensed version of my case study which can be found here: https://www.methuselah.site/case-studies/building-a-health-data-router-that-works-when-the-internet-doesn-t
The Reality Check
Picture this: You're building a health information exchange to connect hospitals across Africa. On paper, it's straightforward - route patient data between facilities using modern cloud architecture.
Then you learn the actual conditions:
- Internet uptime is below 40% in many facilities
- Bandwidth is frequently under 2 Mbps
- Power interruptions are constant
- Doctors share lab results via WhatsApp because it's more reliable than their "official" systems
Your beautiful microservices architecture? Useless when 60% of service calls timeout.
Your centralized cloud hub? A bottleneck that makes the entire system collapse during outages.
What I Designed Instead
I designed a Distributed Edge Routing Architecture that works on a simple principle:
"Routing intelligence lives at the edge, governance lives at the hub."
Here's how it works:
The Edge Router (At Each Facility)
A lightweight service - running on whatever hardware the facility has - that:
- Makes routing decisions locally (sub-5ms latency)
- Queues messages when the internet is down using PostgreSQL
- Syncs automatically when connectivity returns
- Guarantees zero data loss during outages
The Central Hub (Cloud)
Handles governance, not routing:
- Aggregates audit logs for compliance
- Manages configurations and updates
- Provides monitoring dashboards
- Offers OpenHIM-compatible API for regulators
Critical insight: Facilities continue operating even when the hub is unreachable. Messages queue locally, routing happens instantly, and everything syncs when connectivity returns.
Why This Works (And Microservices Don't)
I evaluated three architectural approaches:
Microservices: Technically elegant, practically catastrophic. Service meshes break under unreliable links. Kubernetes adds overhead that rural clinics can't support. Rejected.
OpenHIM (Traditional HIE): Strong on compliance, weak on reliability. Depends on stable networks and becomes a single point of failure. Partially viable.
Distributed Edge Router: Highest real-world resilience. Local queuing prevents message loss. Routing decisions are instant. Supports offline operation. Selected.
The experiments confirmed it: local queuing works reliably under network failures, messages safely accumulate and flush during reconnection, and routing latency stays under 5ms.
The Three-Layer Decision Model
Layer 1 (Fast Path): Hash-based routing from an in-memory table. Microsecond-level decisions.
Layer 2 (Dynamic): Configurable rules for transformations and destination routing.
Layer 3 (Fallback): Internet down? Queue locally. Period.
The 4-Week Proof of Concept
Week 1: Basic HTTP router + PostgreSQL. Routes live messages when online, queues when offline.
Week 2: Fast-layer hash lookups. Measure performance (<5ms target).
Week 3: Sync worker with exponential backoff. Push queued messages to the central receiver.
Week 4: The critical test - disconnect the internet for 10 minutes, reconnect, and verify zero message loss.
Success criteria: No message loss. Queue persists through downtime. Full state restoration after reconnection. Local routing remains intelligent with the hub unreachable.
What This Actually Solved
✓ Works in 40% uptime environments
✓ Maintains audit trails and compliance
✓ Minimal facility disruption
✓ Scales to thousands of clinics
✓ Reduces operational overhead
✓ Integrates with existing systems (EMRs, DHIS2, lab systems)
The Real Lesson
Technology is only effective when grounded in the realities of the environment it serves.
Microservices optimize for hyperscale cloud environments, not African clinical environments. They're the wrong tool for this context.
A system with 99.9% uptime in a Silicon Valley data center might have 40% uptime in a rural clinic. If you design assuming connectivity, you've already failed.
Results
The engagement ended earlier than planned, but the work produced:
- A validated architectural direction that outperformed all alternatives
- Complete technical blueprint with diagrams, component specs, and governance structure
- Working PoC design proving zero message loss during full internet outages
- Rigorous comparative analysis documenting why existing approaches fail
- Week-by-week implementation roadmap
Most importantly: a demonstration that offline-first, edge-based routing is the only architecture that directly addresses African infrastructure constraints.
This project reinforced a fundamental truth: designing for Africa means designing for variability, unpredictability, and resilience. The most sophisticated architecture in the world is worthless if it doesn't work in the actual conditions your users face.
This article is just a condensed version of my case study which can be found here: https://www.methuselah.site/case-studies/building-a-health-data-router-that-works-when-the-internet-doesn-t