Hospital Information System (HIS) - Technical Architecture

The billing service operates as a downstream consumer of clinical events. It ensures financial integrity through idempotent event processing and late-bound PII enrichment.

The gateway is built on Spring Cloud Gateway (WebFlux / Project Reactor). All route definitions live in application.yml. There is no service discovery — routes are statically configured to Docker Compose service names.

Circuit breakers guard all outbound REST calls from appointment-service to patient-service and doctor-service. Configuration is identical for both:

# appointment-service / application.properties

resilience4j.circuitbreaker.instances.patientService
  sliding-window-size                    = 10
  failure-rate-threshold                 = 50      # % failures to open
  wait-duration-in-open-state            = 10s
  permitted-calls-in-half-open-state     = 3
  minimum-number-of-calls               = 5

resilience4j.retry.instances.patientService
  max-attempts                           = 3
  wait-duration                          = 500ms

State transitions: CLOSED → (failure rate exceeds threshold) → OPEN → (wait 10s) → HALF_OPEN → (3 probe calls pass) → CLOSED. In OPEN state, all calls immediately hit the fallback method which returns false, causing the appointment creation to fail with CustomNotFoundException rather than timing out.

patient-service also configures a circuit breaker around its Kafka producer to prevent Kafka broker unavailability from blocking HTTP request threads.

Every service exposes a /actuator/prometheus endpoint via Micrometer. Prometheus scrapes all 6 services on a 5-second interval. Grafana reads from Prometheus and serves a pre-provisioned dashboard.

Metrics tracked per service

Load testing

Three k6 scripts cover different load profiles: low-stress.js (10 VUs, 30s), medium-stress.js (ramp to 50 VUs), intense-stress.js (ramp to 200 VUs). appointments-stress.js runs a full setup phase — registers a user, creates 50 patients and 50 doctors, then hammers appointment creation at 100 req/s constant arrival rate for 30 seconds. Thresholds: P95 < 2000ms, error rate < 1%.

Each service has its own GitHub Actions workflow triggered on push to master when files under its directory change. This prevents unrelated service rebuilds.

# Per-service workflow pattern
on:
  push:
    branches: [master]
    paths:
      - 'appointment-service/**'

# Kubernetes workflow uses matrix strategy across 6 services
strategy:
  matrix:
    service:
      - { name: api-gateway,          port: 4004 }
      - { name: appointment-service,   port: 8084 }
      - ...

The kubernetes-register.yml workflow builds multi-platform images (linux/amd64,linux/arm64) using Docker Buildx, pushes to GHCR, runs Trivy vulnerability scanning, and updates image tags in Kubernetes manifests. Dockerfile uses a two-stage build: Maven builder image + slim eclipse-temurin:21-jdk runner. JVM flags: -XX:MaxRAMPercentage=75.0 -XX:+UseG1GC -XX:+ExitOnOutOfMemoryError.

The system is designed for high observability and fault isolation. Each microservice follows a standard set of cross-cutting paradigms to ensure operational reliability.

The system provides a unified developer portal. The API Gateway aggregates Swagger/OpenAPI documentation from all downstream services, exposing them through a single ingress point.