GlobeCura — Clinic Appointment Platform

Overview

GlobeCura is an appointment booking platform for healthcare clinics, launching with a single clinic and one doctor in Sri Lanka. The brief was unusual in its emphasis: build the smallest thing that validates the booking workflow, but do not let the small version foreclose the large one. Every structural decision was made against a future of many clinics, many doctors, and doctors working across several clinics. The system spans a Java backend and three frontend applications sharing one design system, one API contract and one set of TypeScript types.

Problem

Small clinics run appointments on paper diaries and phone calls. That produces double bookings, no record of who cancelled and when, and no way for a patient to see genuine availability before committing to a visit. The obvious fix — a simple booking form — usually collapses the moment a second doctor or second location appears, because scheduling has been modelled against the doctor rather than against the doctor's working relationship with a specific clinic.

Business Requirements

• Patients can see genuine, real-time doctor availability
• Patients can book, reschedule and cancel appointments online

Solution

We built a centralized inventory platform with a Next.js front end and a Django REST API, giving every location real-time visibility into stock levels and automated reorder alerts.

Architecture

Modular monolith on Spring Modulith. Ten modules — iam, clinic, doctor, patient, schedule, appointment, notification, audit, payment, common — each with web / app / domain / repo layers and a published API package. Cross-module references are by ID only; a JPA association crossing a boundary would be a future service extraction you could no longer perform. audit and notification are event sinks: nothing depends on them, they subscribe.

Key Features

• Real-time availability with breaks

Technology Stack

Challenges

The hardest problem was preventing double bookings under genuine concurrency. Fifty simultaneous requests for the same slot must produce exactly one appointment and forty-nine clean conflict responses. Application-level checks cannot deliver this — there is always a window between "is it free" and "insert" where a second transaction slips through.

Engineering Decisions

Double booking is prevented by a PostgreSQL GiST exclusion constraint over tstzrange rather than a unique index on start time. A unique index only works while every appointment is the same length; the first time a clinic wants 30-minute consultations alongside 15-minute follow-ups, a 09:00 half-hour booking stops conflicting with a 09:15 one and you get silent double-bookings. The exclusion constraint costs the same to write today. A second constraint stops a patient booking themselves into two places at once. Conflicts surface as a 409 — a real business outcome, never retried, because the patient must choose again.

Results

• Worth flagging honestly: there's no pilot data yet, and the backend has not been run against a live database — the integration and concurrency suites still need a machine with Maven and Docker access. I'd avoid metrics here entirely rather than invent them. Capability statements are defensible; percentages are not.