We’re now running both virtual consultations and physical clinic sites at TIBU Health, serving thousands of patients across Nairobi. The challenge isn’t just building features - it’s coordinating complex workflows where events happen asynchronously: a patient books online, a nurse updates vitals at a clinic, a driver accepts a home visit request, a doctor completes a prescription remotely.
Traditional request-response architecture doesn’t handle this well. You end up with tightly coupled services, polling databases, and race conditions when multiple staff interact with the same patient record simultaneously.
What is event-driven architecture?
Instead of Service A calling Service B directly and waiting for a response, services communicate by publishing and consuming events.
An event is just a fact: “Patient checked in,” “Lab result available,” “Driver assigned to home visit.” Services that care about those events subscribe to them and react independently.
Key benefits for healthcare:
- Decoupled services: Our queue system doesn’t need to know about our logistics system. It just publishes “consultation complete” and the logistics service reacts if it’s a home visit.
- Resilience: If one service is down, events queue up and process when it recovers.
- Auditability: Every state change is an event with a timestamp, creating an audit trail automatically.
- Real-time responsiveness: Staff see updates immediately without polling.
Practical example: Home visit workflow
Old approach (request-response):
- Patient books home visit through portal
- Portal API calls Scheduling Service → Scheduling assigns appointment
- Scheduling calls Driver Service → Driver Service finds available driver
- Driver Service calls Notification Service → SMS sent to driver
- Driver accepts → Notification Service called again → Patient notified
If any service fails mid-chain, the whole flow breaks.
Event-driven approach:
- Patient books home visit → HomeVisitRequested event published
- Scheduling Service listens → assigns appointment → publishes AppointmentScheduled
- Driver Service listens → finds driver → publishes DriverAssigned
- Notification Service listens to both → sends appropriate SMSs
- Driver accepts → DriverConfirmed event → Notification Service reacts
Each service is independent. If SMS fails, the appointment still exists and can retry later.
Queue management with events
Our clinic queueing system is event-driven:
- PatientCheckedIn → patient added to queue
- VitalsRecorded → patient status updated, doctor notified
- ConsultationStarted → queue position changes, next patient alerted
- ConsultationCompleted → patient moves to payment, queue advances
Clinic staff, patients on mobile apps, and dashboard screens all subscribe to relevant events and update in real-time. No manual refreshing, no stale data.
Logistics coordination
When we expanded to home visits, logistics became complex: driver availability, route optimisation, supply inventory (test kits, medications). Events let us coordinate without tight coupling:
- HomeVisitScheduled → Logistics Service checks driver availability
- DriverEnRoute → Patient notified with ETA
- ServiceCompleted → Inventory Service updates stock levels
- PaymentReceived → Accounting Service updates financials
Tools we use
- Message broker: RabbitMQ for event distribution (Kafka would work too, but it’s overkill for our scale)
- Event schema: JSON with strict validation - events are contracts between services
- Monitoring: Centralised logging to trace events across services (critical for debugging)
Challenges
- Eventual consistency: Events aren’t instant. A patient might check in but take 200ms to appear in the queue. We show “Processing…” states in the UI.
- Debugging distributed flows: When something breaks, you trace events across multiple services. Good logging is mandatory.
- Event versioning: When you change an event schema, old services still consume it. We version events (HomeVisitRequested.v2) and support both during transitions.
Event-driven architecture isn’t a silver bullet, but for coordinating clinic operations, home visits, and logistics across multiple locations, it’s been transformative. Our systems are more resilient, easier to extend, and respond in real-time.