Appointment scheduling platform for healthcare practitioners

Context

A healthcare practitioner wants patients to book appointments from their own website, and to manage services, schedules, appointments and patients from a back office.

Problem and constraints

• Slots computed from schedules and services, not a fixed grid.
• No double booking: a chosen slot is held temporarily, then confirmed.
• Optional online payment, and a product able to serve several countries and organisations.

Architecture decisions and trade-offs

Twelve architecture decisions are recorded. The main ones:

• A modular monolith with a hexagonal architecture, designed to split into services if the business requires it, without paying that cost up front.
• PostgreSQL as the source of truth for bookings: transactional consistency wins over a cache or a message queue for this data.
• A dynamic availability model: slots are derived from rules, not stored.
• A REST API with standard Problem Details errors, and transactional events that decouple side effects (notifications) from the database write.
• Routing per organisation and per country, with display labels configurable per organisation.

Security and delivery

• Jenkins pipeline: secret scanning, static analysis, backend tests, OpenAPI contract check, back-office build, images, image scan, publication.
• Merging into the main branch is a pipeline step: nothing gets there without passing the checks.
• Delivery split into 13 documented phases, each with its own record in the repository.

Data

The schema evolves through versioned migrations (24 migration files). Patient access to their own appointments has its own architecture decision.

Results and current state

• In production: public API and back office online, release v1.0.0.
• 402 Java files, 82 test files and 12 architecture decisions in the repository.