Case Study

Hospital Management System

Backend Developer · Crystal Technology BD

  • Microservices
  • Spring WebFlux
  • Project Reactor
  • R2DBC
  • gRPC
  • RabbitMQ
  • PostgreSQL
  • Liquibase
  • Keycloak
  • Kong API Gateway
  • Redis
  • Apache ZooKeeper

Overview

A high-throughput, enterprise-grade digital healthcare automation platform built to orchestrate clinical and administrative operations across multiple departments. Worked across the entire system rather than a single module: outpatient and inpatient lifecycle management, doctor scheduling, electronic medical records (EMR), laboratory diagnostic investigations, pharmacy billing and emergency admissions, together with the reactive microservice architecture underneath them — service boundaries, inter-service communication, schema migrations and the shared authentication layer — delivered with zero clinical downtime.

Problem

A patient moves through admission, consultation, diagnostics, pharmacy and billing, and each department had its own record of them. The same details were re-entered at every desk, clinical decisions could be made against a stale copy, and nobody could see the whole journey. A hospital also cannot be asked to stop while the system catches up.

My role

Backend developer across the whole platform rather than a single module — every clinical and administrative area, from admissions and electronic medical records through laboratory orders and pharmacy to multi-department billing, together with the microservice layer underneath them. I wrote the reactive services and their R2DBC repositories, defined the gRPC contracts between them, and set up the Keycloak realm and Kong routes that front them.

Architecture

Every request enters through Kong, which terminates the edge and forwards only what carries a valid Keycloak token. Behind it the services are non-blocking Spring WebFlux, built on Project Reactor, so a request waiting on the database does not hold a thread. Services call each other over gRPC when they need an answer, and publish to RabbitMQ when they do not — which keeps slow work such as notifications and report generation off the request path. Persistence is R2DBC over PostgreSQL, reactive end to end, with Liquibase versioning the schema across environments. Redis caches the reads that repeat, and ZooKeeper coordinates the instances that must not act twice.

Hospital Management System request and data flow A client request enters Kong API Gateway, which validates the caller against Keycloak. Kong routes to three Spring WebFlux services that call one another over gRPC. The services publish asynchronous work to RabbitMQ and read and write through R2DBC to PostgreSQL, with Redis for caching and Apache ZooKeeper coordinating service instances. Client · Web & Mobile Kong API Gateway Keycloak Spring WebFlux service Spring WebFlux service Spring WebFlux service Apache ZooKeeper RabbitMQ PostgreSQL Redis validates gRPC gRPC publish coordinate R2DBC cache
Solid lines carry a request and wait for a reply. Dashed lines hand work off and do not.

Key challenge

Staying non-blocking the whole way down. A thread-per-request stack stalls when diagnostics, pharmacy and billing all push at once, so the reactive choice goes all the way to the database through R2DBC — which means no blocking JDBC call can be left anywhere, identity has to propagate across reactive boundaries where a thread-local does not survive, and schemas have to migrate across independently deployed services without a window where two of them disagree.

Result

Clinical and administrative operations run on one platform across every department, with services deployable independently behind the gateway and a single identity path in front of them — delivered with no clinical downtime.