Mulûng LifeLine
Connecting hospitals and donors to reduce delays in emergency blood access.
Problem Statement
Emergency blood needs are time-critical, but coordination between hospitals and donors is often manual, slow, and geographically inefficient.
When hospitals face urgent blood shortages, they rely on phone calls, social media posts, and informal networks to find donors—introducing delays that can be life-threatening.
System Goal
Enable hospitals to broadcast urgent blood requests and match them with nearby, eligible donors in real-time—minimizing the time between need and availability.
Constraints Handled
Proximity
Donors must be within reasonable distance of the hospital. The system prioritizes location-aware matching to ensure feasible response times.
Availability
Donors may not always be reachable or able to respond immediately. The system accounts for notification delivery, donor eligibility windows, and response latency.
Connectivity
Operates under low or intermittent network conditions by caching critical data and queuing notifications for delivery when connectivity is restored.
Multi-actor coordination
Multiple hospitals and donors operate concurrently. The system prevents race conditions where donors commit to multiple requests or hospitals over-allocate responses.
Key Engineering Decisions
Geospatial indexing for proximity matching
Used spatial queries to efficiently match donors within configurable radius thresholds. This ensures that only relevant donors are notified, reducing noise and improving response quality.
State machine for request lifecycle
Blood requests move through defined states (pending → matched → fulfilled → closed). This prevents ambiguity and ensures that once a request is fulfilled, no further donor notifications are sent.
Offline-first notification queue
Notifications are queued and delivered when connectivity is available. This allows the system to function in environments where real-time delivery cannot be guaranteed.
Idempotent donor commitment logic
Donors can only commit to one active request at a time. This is enforced at the database level to prevent double-booking under concurrent operations.
Tech Context
Built with PostgreSQL for reliable state management and spatial queries using PostGIS extensions.
Used background workers to handle asynchronous notification delivery and retry logic.
Designed API contracts to support mobile clients with limited bandwidth—minimal payloads, efficient polling, and delta updates.
System Model
Actors
Hospitals, donors, system admins
Resources
Blood requests, donor profiles, commitments
Actions
Create request, match donors, commit to donate, fulfill request
Constraints
One active commitment per donor, proximity-based matching, state transitions must be valid