Buchungssoftware, die
von allein läuft
Online-Termine, automatische Erinnerungen und Nachfass-Mails für Praxen. Entworfen und gebaut habe ich das Ganze selbst, von der Buchungsseite bis zum Scheduler, der die Erinnerungen verschickt.
Niemand hat diese Seite offen. Der Scheduler wacht von selbst auf, arbeitet ab, was ansteht, und schiebt jeden Termin weiter.
Was eine Praxis bekommt
Jede Praxis bekommt ihren eigenen Buchungslink, ihre eigenen Öffnungszeiten und ihre eigene Leistungsliste. Patienten wählen einen Termin, ohne anzurufen, die Bestätigung geht sofort raus, die Erinnerung zwei Tage vorher. Nach dem Termin fragt eine Nachfass-Mail nach einer Bewertung und lädt zur nächsten Buchung ein. Ich habe jede Ebene davon selbst geschrieben, die Oberfläche, die API, die Datenbank und die Jobs dazwischen.
Warum es ein Backend brauchte
Das ist das einzige meiner Projekte, das ein System ist und keine Website. Das Backend gibt es wegen vier Dingen, die im Browser nicht passieren können.
Ein freier Termin muss berechnet werden
Die Öffnungszeiten dieses Wochentags, die Schließtage, die Dauer der gewählten Leistung und jeder Termin, der schon steht. Frei ist, was nach allen vieren übrig bleibt, und das stimmt nur, wenn der Server es ausrechnet.
Die Erinnerung geht zwei Tage vor dem Termin raus
Das kann nicht in einem Browser-Tab laufen. Ein Scheduler wacht von selbst auf, gibt die Arbeit an eine Queue, ein Worker verschickt sie. Ein Versand kann scheitern, ohne dass jemand danebensteht, also werden Fehlschläge wiederholt.
Der Status eines Termins wandert von allein
Offen, erinnert, bestätigt, abgeschlossen. Jeder Übergang wird sofort in einer History-Tabelle festgehalten, damit nachvollziehbar bleibt, was das System getan hat, auch lange nach der Sitzung, die es angestoßen hat.
Jede Praxis muss von den anderen abgeschottet sein
Ein Deployment bedient viele Praxen, jede mit eigenem Link, eigenen Leistungen und eigenen Zeiten. Jeder geschützte Request löst auf, welcher Praxis der Aufrufer gehört, und begrenzt die Abfrage darauf. Ein Fehler dabei würde die Patientenliste einer Praxis im Dashboard einer anderen auftauchen lassen.
Was tatsächlich läuft
Sechs Container. Das Nuxt-Frontend reicht die Anfragen an die API weiter, statt sie aus dem Browser aufzurufen, so verlässt das Session-Cookie nie den Server. Postgres hält die Daten, Redis ist die Queue, dahinter zwei Celery-Prozesse, ein Worker, der verschickt, und ein Scheduler, der entscheidet wann. Nichts startet, bevor das, wovon es abhängt, gesund ist.
Migrationen, Tests und Rate Limits
Schema-Änderungen laufen über Migrationen statt von Hand, damit die Datenbank sich von null neu aufbauen lässt und immer im selben Zustand landet. Zehn Test-Suites decken die Routen, die Terminberechnung, das Scheduling und die Rate Limits ab, dazu Komponenten- und Composable-Tests im Frontend. Die öffentlichen Endpunkte sitzen hinter einem Rate Limit, weil ein Buchungsformular für jeden im Internet erreichbar ist.
Der Stack
- Nuxt 4
- Vue 3
- TypeScript
- Tailwind 4
- PrimeVue
- Firebase Auth
- FastAPI
- Python
- SQLAlchemy
- Alembic
- PostgreSQL
- Redis
- Celery
- Docker
In der Liste steht PrimeVue, das diese Seite hier nicht benutzt. Was du siehst, ist von Hand in Tailwind nachgebaut. Eine ganze Komponentenbibliothek mitzuschleppen, um sechs Karten zu zeichnen, wäre ein merkwürdiger Tausch.
Warum kann man es nicht kaufen?
Weil der nächste Schritt ein juristischer ist und kein technischer. Wer die Patientendaten fremder Praxen verarbeitet, braucht Verträge und eine Auftragsverarbeitungsvereinbarung, und das ist Sache eines Anwalts, nicht die eines Wochenendes. Die Software ist deployt und läuft. Was fehlt, ist das Papier.
Deployt und bewusst geparkt.