score

Skalierbarkeit und Betrieb

Ein Artefakt, drei Betriebsprofile – von der einzelnen Schule bis zum Landesbetrieb.

score wird als ein Satz Container-Images ausgeliefert. Ob eine Privatschule es auf einem Server betreibt oder ein Land in einem Rechenzentrum, entscheidet Konfiguration und Anzahl der Instanzen.

Betriebsprofile

Klein Mittel Land
Zielgröße eine Einrichtung, bis ca. 1.000 Konten Träger mit einigen Dutzend Schulen z. B. M-V: ca. 620 Schulen, 450.000 Konten, 3.000–5.000 gleichzeitig
Laufzeit ein Host mit docker compose, score-api im Modus all mehrere Instanzen hinter einem Load Balancer, eigener Worker horizontal skaliert, Worker getrennt, Lese-Replikat für die Einsicht
Identität lokale Konten in Keycloak, Eltern per Einladung Träger-IdP oder lokale Konten Landes-IdP über Keycloak
Stammdaten Eingabe, Import als JSON oder CSV Import aus der Verwaltungssoftware Adapter zur Landes-Schulverwaltung
Dateien lokales Volume S3 S3 mit Object Lock
Schlüssel lokal lokal oder Vault KMS oder HSM

Die Mandantentrennung per Row-Level Security gilt in jedem Profil, auch wenn nur eine Einrichtung darin liegt.

Zielbild Landesprofil

Fokus
Zielbild Landesprofil: horizontal skaliert, Engpass Datenbank
Zielbild Landesprofil: horizontal skaliert, Engpass DatenbankArchitekturdiagramm mit 10 Komponenten und 10 Verbindungen in 2 Grenzen. Rechenzentrum in Deutschland: Reverse Proxy, LB, score-web × n, score-api × n, score-api × m, Keycloak, Datenzone. Datenzone (in Rechenzentrum in Deutschland): PostgreSQL, Lese-Replikat, S3. Hauptweg: 450.000 Konten → Reverse Proxy, LB → score-web × n → score-api × n → PostgreSQL. 450.000 Konten (Person): verbunden mit Reverse Proxy, LB (HTTPS). score-api × m (Dienst): verbunden mit PostgreSQL (Jobs, SKIP LOCKED) und S3 (Zeugnis-PDF, Archiv). Reverse Proxy, LB (Sicherheit): verbunden mit score-web × n (verteilt). S3 (Speicher): keine ausgehende Verbindung. score-web × n (Dienst): verbunden mit score-api × n (/v1). score-api × n (Dienst): verbunden mit PostgreSQL (schreibt), Lese-Replikat (liest) und Keycloak (OIDC). Keycloak (Sicherheit): verbunden mit Landes-IdP (brokert). PostgreSQL (Datenbank): verbunden mit Lese-Replikat (repliziert). Lese-Replikat (Datenbank): keine ausgehende Verbindung. Landes-IdP (externes System): keine ausgehende Verbindung.Rechenzentrum in DeutschlandDatenzone450.000 Konten → Reverse Proxy, LB: HTTPSReverse Proxy, LB → score-web × n: verteiltscore-web × n → score-api × n: /v1score-api × n → PostgreSQL: schreibtscore-api × n → Lese-Replikat: liestPostgreSQL → Lese-Replikat: repliziertscore-api × m → PostgreSQL: Jobs, SKIP LOCKEDscore-api × m → S3: Zeugnis-PDF, Archivscore-api × n → Keycloak: OIDCKeycloak → Landes-IdP: brokertHTTPSverteilt/v1schreibtliestrepliziertJobs, SKIP LOCKEDZeugnis-PDF, ArchivOIDCbrokert450.000 Konten – 3.000–5.000 gleichzeitig450.000 Konten3.000–5.000 gleichzeitigReverse Proxy, LB – TLS 1.3, WAFReverse Proxy, LBTLS 1.3, WAFscore-web × nscore-web × nscore-api × n – Modus apiscore-api × nModus apiscore-api × m – Modus workerscore-api × mModus workerKeycloakKeycloakPostgreSQL – Primär, vertikal skaliertPostgreSQLPrimär, vertikal skaliertLese-Replikat – Einsicht Schüler, ElternLese-ReplikatEinsicht Schüler, ElternS3 – Object LockS3Object LockLandes-IdPLandes-IdP

Quelle: score, Zielbild Landesprofil (Lese-Replikat und S3 noch nicht gebaut)

Diagrammdaten anzeigen
Daten zu Zielbild Landesprofil: horizontal skaliert, Engpass Datenbank
KomponenteArtGrenzeVerbunden mit
450.000 KontenPersonReverse Proxy, LB (HTTPS)
score-api × mDienstRechenzentrum in DeutschlandPostgreSQL (Jobs, SKIP LOCKED), S3 (Zeugnis-PDF, Archiv)
Reverse Proxy, LBSicherheitRechenzentrum in Deutschlandscore-web × n (verteilt)
S3SpeicherRechenzentrum in Deutschland › Datenzone
score-web × nDienstRechenzentrum in Deutschlandscore-api × n (/v1)
score-api × nDienstRechenzentrum in DeutschlandPostgreSQL (schreibt), Lese-Replikat (liest), Keycloak (OIDC)
KeycloakSicherheitRechenzentrum in DeutschlandLandes-IdP (brokert)
PostgreSQLDatenbankRechenzentrum in Deutschland › DatenzoneLese-Replikat (repliziert)
Lese-ReplikatDatenbankRechenzentrum in Deutschland › Datenzone
Landes-IdPexternes System

Das Landesprofil ist ein Zielbild; der Lasttest dafür steht noch aus. Die Annahmen:

  • score-web und score-api sind zustandslos. Sitzungen liegen in PostgreSQL; jede Instanz kann jede Anfrage bedienen.
  • Der Engpass ist PostgreSQL. Er wird vertikal skaliert; lesende Einsicht von Schülern und Eltern kann auf ein Replikat.
  • Regeln kosten keinen Netzwerkweg. Die Regel-Engine läuft im Prozess von score-api.
  • Sammelvorgänge sind Jobs. Zeugnisdruck, Import und Export laufen im Worker über eine Queue-Tabelle in PostgreSQL (SKIP LOCKED), ohne zusätzlichen Message-Broker.
  • Kein Modul setzt Landesinfrastruktur voraus. Replikat, S3 und getrennter Worker sind Optionen, keine Voraussetzung.

Lastmessung im kleinen Profil

Gemessen mit k6 am 08.10.2026 auf einem Rechner: alle Dienste in einer Docker-VM mit 4 vCPU und 6 GiB, Keycloak im Entwicklungsmodus, Demo-Daten der drei Schulen. Ziel war p95 unter 2 s.

Szenario Ergebnis
3.000 Anmeldungen in 30 s, jede vollständig über Keycloak alle erfolgreich, p95 156 ms
3.000 gleichzeitige Nutzer mit 10–30 s Denkpause 58.377 Seitenaufrufe, keine Fehler, p95 19,8 ms
5.000 gleichzeitige Nutzer, ebenso 96.917 Seitenaufrufe, keine Fehler, p95 18,6 ms

Grenzen der Messung: sechs Testkonten statt 450.000, kleiner Datenbestand, nur lesende Seitenaufrufe. Ein frisch gestarteter Keycloak brach bei 100 Anmeldungen je Sekunde ein; das Szenario wärmt ihn deshalb 30 Sekunden lang auf. Aussagen über das Landesprofil erlaubt erst ein Lauf auf dessen Infrastruktur.

Topologien

  • Gemeinsame Instanz für mehrere Auftraggeber, getrennt per Row-Level Security.
  • Instanz je Land mit eigener Datenbank, eigenen Schlüsseln und eigenem Keycloak-Realm.

Beides entsteht aus demselben Artefakt.

Portabilität

Damit ein Umzug zwischen Rechenzentren nur Konfiguration ist:

  • OCI-Images, Konfiguration über Umgebungsvariablen
  • nur Standard-PostgreSQL ab Version 16, keine Erweiterungen, die verwaltete Angebote nicht haben
  • Dateien nur über die S3-API, Identität nur über OIDC
  • Logs als JSON auf stdout
  • Migrationen abwärtskompatibel, damit Updates ohne Ausfall möglich sind