Skip to content
Deependra Vishwakarma

2022 · Telemedicine platform · Mind Frame India Advertising & Creative Pvt. Ltd. · Backend developer

Immunomate

A telemedicine app with real-time video consultations, launched to 500+ registered users.

I built the backend of a telemedicine web application with real-time video consultations, doctor–patient chat and appointment scheduling, using Laravel, Firebase Firestore and WebRTC, and cut API response times with Redis caching.

500+

registered users

How this is measured

Registered users of the Immunomate telemedicine app.

40%

reduction in API response time after Redis caching

How this is measured

Reduction in API response time after adding Redis caching.

The constraint

A healthcare startup making consultations accessible online: patients book, meet the doctor on video and follow up in chat.

Reliable real-time video and chat, appointment scheduling, and careful handling of patient information.

The architecture

  • Laravel for the core API: accounts, appointments and records.
  • Firebase Firestore for real-time chat and presence.
  • WebRTC for peer-to-peer video consultations.
  • Redis caching in front of the busiest API endpoints.
Architecture of ImmunomatePatients and doctors use a Laravel API for accounts, appointments and records, with Redis caching its busiest endpoints; chat and presence run on Firebase Firestore, and video is peer to peer over WebRTC.video, peer to peer (WebRTC)bookrecordscachechatchatPatientDoctorLaravel APIaccounts, appointments,recordsRedisbusiest endpointsFirestorechat and presence
the hot path asynchronous
The diagram as text

Patients and doctors use a Laravel API for accounts, appointments and records, with Redis caching its busiest endpoints; chat and presence run on Firebase Firestore, and video is peer to peer over WebRTC.

  • Patient → Doctor: video, peer to peer (WebRTC)
  • Patient → Laravel API: book
  • Doctor → Laravel API: records
  • Laravel API → Redis: cache
  • Patient → Firestore: chat (asynchronous)
  • Doctor → Firestore: chat (asynchronous)

Trade-offs

  • Firestore for real-time features instead of self-hosted sockets: faster to ship and scale, at the cost of vendor lock-in for that part of the system.
  • Peer-to-peer video keeps latency and server cost low, but needs fallbacks for restrictive networks.

Results

  • Launched with real-time video consultations and chat.
  • Redis caching cut API response times by 40%.
  • Three responsive web views delivered for patients, doctors and administrators.

What I'd do again

  • Real-time features are easiest to ship on managed infrastructure. Keep the core data in your own database.
  • In healthcare, privacy and access control come first. Design them in from the start.

Stack

  • Laravel
  • Firebase Firestore
  • WebRTC
  • Redis
  • REST APIs

Need something like this?

A short brief is enough to start. I’ll reply with questions, a suggested first step and when I could begin.