Referenzen / UpGreg · upgreg.ai ↗
Fallstudie
Vier Module, ein Gateway, kein einziges Rewrite.
Wie eine Geschäftsplattform so zerlegt wurde, dass kein Teil je wieder die anderen blockieren kann — und warum diese Zerlegung im nächsten Projekt drei Monate eingespart hat.
Das Problem
Ein Produkt, das wachsen musste — nur wusste niemand, wohin
Der anfängliche Bedarf war klar: Benutzerkonten, Benachrichtigungen, ein Backoffice. Weniger klar war, was danach kommt. Ein junges Produkt ändert seine Meinung — über sein Modell, über seine Nutzerinnen und Nutzer, manchmal über sein Geschäft.
Die klassische Falle in diesem Stadium ist der Monolith: Drei Monate lang geht alles schnell, dann berührt jede Änderung alles, jedes Deployment wird riskant, und der kleinste Ausfall legt das Ganze lahm. Die umgekehrte Falle — eine Konstellation von Microservices — kostet ein kleines Team mehr, als sie einbringt.
Die Frage in der Analyse lautete deshalb nicht «welche Technologie?», sondern «welches ist die kleinste Grenze, die es erlaubt, ein Teil zu ersetzen, ohne die anderen wieder aufzumachen?»
Was wir getan haben
Vier Entscheidungen, vor der ersten Zeile Code festgehalten und seither eingehalten.
Eigenständige Module hinter einem einzigen Gateway
Jede Domäne — Konten, Benachrichtigungen, Administration — ist ein eigener Dienst, mit eigenem Port, eigenem Health-Endpunkt und eigenem Manifest. Kein Modul ruft ein anderes direkt auf: Alles läuft über das Gateway oder einen Event-Bus. Praktische Folge: Ein Modul lässt sich ersetzen, ohne den Rest anzufassen, und ein ausgefallenes Modul reisst das Produkt nicht mit.
Eine einzige Datenbank, nummerierte Migrationen
Eine Datenbank pro Modul wäre lehrbuchmässig sauber und in dieser Grösse betrieblich ruinös gewesen. Also eine Datenbank — aber mit diszipliniertem Schema und nummerierten, idempotenten Migrationen, jede im Deployment-Skript referenziert. Eine Migration, die dort fehlt, wird nie ausgeführt: Das ist der häufigste Produktionsausfall in diesem Metier, und er wird durch eine automatische Prüfung vor jedem Deployment verhindert.
Ein reproduzierbares Deployment, von nur einer berechtigten Maschine
Container, automatisches Routing und automatische Zertifikate, Umgebungsvariablen aus einer versionierten Vorlage. Das Deployment ist ein Skript, keine Abfolge von Handgriffen: Es läuft von einer einzigen Maschine, protokolliert, was es tut, und kann zurückrollen.
Observability ab dem ersten Paket
Health-Status je Modul, strukturierte Logs, Fehlermeldungen, Nutzungsmetriken: im ersten Paket eingerichtet, nicht nach dem ersten Ausfall. Genau das erlaubt es zu sagen, was passiert ist, statt es zu vermuten.
Ergebnis
Was sich konkret geändert hat
- Erste nutzbare Version sechs Wochen nach der Analyse online, danach Lieferung in Paketen.
- Kein einziges Rewrite seit dem Produktivgang: Die Grenzen haben gehalten.
- Die Module für Konten und Benachrichtigungen wurden unverändert für ein anderes Produkt übernommen.
- Der Ausfall eines Moduls hat nie die gesamte Plattform lahmgelegt.
- Betrieb und Entwicklung liegen im selben Haus: kein Hin- und Herschieben von Verantwortung.
Klartext
Was wir anders machen würden
- Health-Routen zu spät deklariert. Nach den dynamischen Routen platziert, wurden sie von diesen abgefangen. Eine verlorene Stunde — und seither eine schriftliche Regel: statische Routen zuerst, immer.
- Ein zu früh eingeführter Cache. Er verdeckte ein echtes Abfrageproblem. Entfernt, die Abfrage korrigiert, den Cache aus guten Gründen wieder eingesetzt.
- Das erste Backoffice war zu generisch. Für hypothetische Bedürfnisse geschrieben; die Hälfte davon wurde nie gebraucht. Seither: Eine Administrationsmaske entsteht erst, wenn wir den Arbeitsschritt gesehen haben, den sie ersetzt.
Ein Fundament zu legen oder ein bestehendes System zu zerlegen?
Die Analyse ist ein kurzes, verrechnetes Paket. Sie endet mit einem bezifferten Plan — und manchmal mit «behalten Sie, was Sie haben, und korrigieren Sie drei Dinge».