Scalable Architecture

Skalierbarkeit heißt für uns saubere Trennung von Zuständigkeiten, Dienste, die man vervielfachen kann, und Datenzugriffe, die auch unter Last schnell bleiben. Der wichtigste Teil davon ist der letzte, weil er am häufigsten unterschätzt wird: Eine Abfrage, die bei tausend Datensätzen sofort antwortet, kann bei zwei Millionen sekundenlang brauchen. Das merkt man nicht beim Entwickeln, sondern im Betrieb.

Deshalb messen wir. In der Geoplattform brauchte eine strukturierte Adresssuche ursprünglich rund 1,4 Sekunden, weil sie die Tabelle durchlaufen musste. Nach der Umstellung auf eine normalisierte, indexgestützte Suche liegt sie bei etwa 6 Millisekunden — das Ergebnis von messen, gezielt ändern, wieder messen.

Beim Blättern durch große Ergebnismengen merkt sich der Server, wo weitergelesen wird, statt Zeilen zu zählen. Der Unterschied zeigt sich erst bei Last: Ein Sprung auf „Seite 500“ per Zeilennummer zwingt die Datenbank, alle vorherigen Zeilen zu überspringen, und die Ergebnisse verrutschen, wenn sich die Daten währenddessen ändern.

Die andere Richtung gehört dazu: Wir überbauen nicht. In einem Projekt ist die Verwaltung der Echtzeit-Verbindungen bewusst einprozessig und im Arbeitsspeicher gehalten, mit der ausdrücklichen Festlegung in der Architekturdokumentation, dass die verteilte Variante nicht Teil des ersten Wurfs ist.

Am weitesten treiben wir das in der Bauvorgabe für unsere eigene Mandanten-Plattform. Dort steht ein eigenes Kapitel „Annahmen und Auslegungsgrenzen“ (Stand 11.09.2026): Jede Dimensionierung gilt für definierte Zahlen der ersten Ausbaustufe — bis 50 Mandanten, bis 5.000 Konten, 50 Anfragen pro Sekunde nachhaltig mit 200 im Spitzenfall, alles auf einem einzigen Server-Verbund. Fast jede Grenze hat einen Auslöser, ab dem die nächste Stufe greift, etwa eine Antwortzeit über 400 Millisekunden im 95. Perzentil über sieben Tage.

Die Zahlen beschreiben einen Verbund, nicht die Plattform insgesamt: Weil jeder Mandant eine eigene Datenbank bekommt, kommen weitere Verbünde dazu. Dasselbe System ist außerdem als eigene Instanz für eine einzelne Organisation angelegt — aus derselben Codebasis, auf einem gemieteten Server ihrer Wahl oder im eigenen Haus. Festgelegte Richtung, kein Angebot.

Der Start läuft bewusst als modularer Monolith: Module intern strikt getrennt, aber gemeinsam gebaut, getestet und ausgeliefert. Microservices, Kubernetes und ein Nachrichtenbus sind ausdrücklich nicht Teil der ersten Stufe — mit der Bedingung, wann sie neu zu bewerten wären.