Kapazitaetsplanung: 1 Million Buecher / 100.000 Nutzer (und das Zehnfache)

Zielgruppe: Architektur/DevOps/Management. Beantwortet eine Frage, die alle bisherigen DevOps-Dokus bewusst offenlassen: docker-compose-guide.md, kind-cluster.md und kubernetes-guide.md beschreiben ausschliesslich Lern-/Test-Umgebungen auf einem einzelnen Laptop. Dieses Dokument nimmt die Rolle "was waere noetig, wenn dieses System echt 1 Mio. Buecher und 100.000 Nutzer bedienen muesste" bewusst als eigenstaendige Kapazitaets- und Lizenzplanung ein - kein Deployment-Ergebnis, sondern eine begruendete Rechnung und Empfehlung. Alle Annahmen sind explizit markiert, weil eine Kapazitaetsplanung ohne offengelegte Annahmen wertlos ist. Abschnitt 10-11 wiederholt dieselbe Rechnung fuer das Zehnfache (10 Mio. Buecher, 1 Mio. Nutzer) inkl. Kostenvergleich beider Groessenordnungen. Abschnitt 12 uebersetzt beide Groessenordnungen in konkrete Stuecklisten (Kerne/RAM/Speicher) fuer drei Betriebsmodelle - On-Premise/Bare-Metal, VM (eigener Hypervisor) und AWS Cloud - und rechnet in 12.5 jede Inventar-Zeile einzeln mit realen, recherchierten Listenpreisen durch (Stand August 2026). Abschnitt 13 ergaenzt das um Betriebs-/Personalkosten, die bei diesem System-Umfang die reinen Infrastrukturkosten deutlich uebersteigen.

1. Warum Annahmen zuerst, nicht Server-Groessen zuerst

Ein haeufiger Anfaengerfehler bei Kapazitaetsplanung: sofort mit Serverzahlen anfangen, bevor klar ist, WAS die beiden Zahlen "1 Mio. Buecher" und "100.000 Nutzer" ueberhaupt fuer Last bedeuten. Beide Zahlen allein sagen fast nichts - ein System mit 100.000 registrierten, aber inaktiven Nutzern ist trivial; eines mit 100.000 gleichzeitig aktiven Nutzern waere ein komplett anderes Projekt. Deshalb zuerst die Umrechnung von "Nutzerzahlen" in "Last", danach erst Infrastruktur-Dimensionierung.

1.1 Datenmenge: 1 Million Buecher

Die wichtigste Erkenntnis dieser Rechnung: 1 Million Buecher sind fuer eine relationale Datenbank kein Big-Data-Problem. 10-20 GB laeuft bequem auf einer einzelnen, nicht einmal besonders grossen Postgres-Instanz (siehe Abschnitt 3) - das ist um Groessenordnungen kleiner als z. B. ein durchschnittliches E-Commerce-Produktkatalog-System mit Bildvarianten, Preishistorie und Lagerbestand in Echtzeit. Ein haeufiger Anfaengerfehler ist, bei "1 Million" reflexhaft an Sharding, NoSQL oder Suchcluster als ZWINGENDE Voraussetzung zu denken - hier ist das eine bewusste, spaeter begruendete Ergaenzung (Abschnitt 3.3), kein struktureller Zwang.

1.2 Traffic: 100.000 Nutzer

Registrierte Nutzer sind NICHT gleich gleichzeitige Last - das ist die zentrale Umrechnung, die fehlt, wenn man nur die rohe Nutzerzahl nennt.

Zweite wichtige Erkenntnis: 20-30 Requests/Sekunde Spitzenlast ist fuer moderne Microservices-Infrastruktur eine kleine bis mittlere Last - jeder der neun Services aus diesem Projekt schafft das bereits auf einer einzigen, bescheiden dimensionierten Pod-Instanz (siehe die real gemessenen Boot-/Antwortzeiten in kind-cluster.md). Ein Bibliothekssystem fuer 100.000 Nutzer ist rechnerisch kein Hyperscale-Problem wie eine grosse E-Commerce-Plattform (die bei vergleichbarer Nutzerzahl oft 100-1000× mehr Requests/Sekunde sieht, weil Kaufabschluesse, Preisvergleiche und Werbe-Tracking viel haeufiger Requests ausloesen als Bibliotheksnutzung). Die eigentliche "Enterprise"-Komplexitaet bei dieser Groessenordnung entsteht NICHT aus rohem Durchsatz, sondern aus:

• Verfuegbarkeit: ein Ausfall betrifft 100.000 echte Nutzer, nicht ein paar Testkonten - Redundanz (Mehrfach-Instanzen, Multi-AZ) wird zur Pflicht, nicht zur Kuer.
• Betriebsreife: Backups, Monitoring-Alarmierung, Kapazitaets-Vorwarnung, Sicherheitsupdates muessen tatsaechlich zuverlaessig laufen, nicht nur einmal demonstriert werden.
• Spitzen-/Sondersituationen: ein initialer Bulk-Import von 1 Mio. Buchdatensaetzen (Migration aus einem Altsystem) ist ein separates, zeitlich begrenztes Lastprofil - siehe 1.3 - keine Dauerlast, aber bei falscher Dimensionierung ein einmaliger, aber realer Engpass.
• Compliance/DSGVO: 100.000 echte Personendatensaetze (Name, Adresse, Ausleihhistorie) unterliegen der DSGVO ernsthaft, nicht nur theoretisch - siehe Abschnitt 9.

1.3 Sonderfall: Initialer Massenimport

1 Million Buecher entstehen nicht organisch durch Nutzereingaben, sondern vermutlich durch einen einmaligen Import (Altsystem-Migration, Verbundkatalog-Abzug wie GVK/K10plus). Das ist ein separates Lastprofil: keine interaktive Latenzanforderung, aber hoher, anhaltender Schreibdurchsatz auf catalog-service. Empfehlung: Bulk-Import ueber einen eigenen Batch-Pfad (z. B. COPY-basiertes Postgres-Bulk-Loading statt 1 Million einzelner REST-Aufrufe), zeitlich ausserhalb der Kernnutzungszeiten, mit vorher testweise deaktiviertem oder gedrosseltem Kafka-Event-Versand (sonst erzeugt ein 1-Millionen-Zeilen-Import 1 Million BookRegistered-Events auf einmal - siehe ADR-0003 zur Event-getriebenen Architektur dieses Projekts).

2. Kubernetes-Cluster

Die Lernumgebungen dieses Projekts (kind fuer CI-Tests, der gescheiterte CRC/OKD-Versuch fuer "produktionsnah") laufen bewusst auf einem einzelnen Laptop. Fuer echte 100.000 Nutzer ist ein verwalteter Cloud-Kubernetes-Dienst (EKS/AKS/GKE) oder eine dedizierte OpenShift-Installation die richtige Wahl - kein Laptop-Cluster mehr, siehe Abschnitt 8 zur Lizenzfrage OpenShift vs. vanilla Kubernetes.

3. PostgreSQL

3.1 Instanzgroesse

Aus 1.1: ~10-20 GB Gesamtdatenvolumen ueber alle fuenf Datenbanken. Das ist mit einer einzelnen, moderaten verwalteten Postgres-Instanz je Service komfortabel zu betreiben (z. B. AWS RDS db.r6g.large/Azure GP_Standard_D2s Groessenordnung: 2-4 vCPU, 8-16 GB RAM) - der Flaschenhals ist auch hier nicht die Datenmenge, sondern gleichzeitige Verbindungen und Verfuegbarkeit:

3.2 Bulk-Import (siehe 1.3)

Fuer den initialen 1-Mio.-Buecher-Import: COPY-Kommando (Postgres-natives Bulk-Loading, um Groessenordnungen schneller als 1 Million einzelne INSERTs ueber JPA/Hibernate), Indizes waehrend des Imports temporaer entfernen und danach neu aufbauen (schneller als fortlaufend zu pflegen).

3.3 Katalogsuche: wann Postgres nicht mehr reicht

Postgres' eingebaute Volltextsuche (tsvector/GIN-Index) skaliert fuer 1 Mio. Buecher bei ~5-30 RPS Suchlast weiterhin gut. Ein dediziertes Suchsystem (OpenSearch/Elasticsearch) wird erst dann sinnvoll, wenn zusaetzlich Facettensuche (Filterung nach Verfuegbarkeit, Autor, Jahr, Standort gleichzeitig, mit Trefferzahlen je Facette), Relevanz-Ranking (Tippfehler-Toleranz, Gewichtung) oder deutlich hoehere Suchlast gefordert ist. Das ist eine bewusste Vertiefungsaufgabe fuer dieses Projekt (CQRS-Lesemodell: catalog-service bleibt Source of Truth, publiziert bereits Domain Events ueber Kafka - siehe ADR-0003 - die exakt die Grundlage waeren, um einen OpenSearch-Index nebenlaeufig zu befuellen), kein Umbau, der fuer die reine Zielgroesse "1 Mio. Buecher" bereits zwingend noetig waere.

4. Caching: Redis

Redis-Cluster-Modus (mind. 3 Master-/3 Replica-Knoten) fuer den bereits bestehenden Read-Through-Cache der Katalogsuche (siehe tech-stack.md). Datenvolumen im Cache ist klein (Suchergebnis-Seiten, keine vollstaendigen Buchdaten) - hier ist RAM-Groesse unkritisch (wenige GB reichen); der Grund fuer Cluster-Modus ist Verfuegbarkeit, nicht Kapazitaet: faellt der einzige Redis-Knoten der Lernumgebung aus, faengt common-observability/der Cache-Aspekt das nur dann sauber ab, wenn der Code bereits Cache-Ausfaelle toleriert (Fallback auf Postgres) - das im Produktivbetrieb bewusst zu pruefen, nicht als gegeben anzunehmen, ist Teil dieser Planung. Zur Lizenzfrage von Redis: siehe Abschnitt 8.2 - ein eigener Abschnitt, weil die Redis-Lizenzaenderung 2024 fuer viele Teams eine echte Ueberraschung war.

5. Messaging: Kafka und RabbitMQ

6. Identity: Keycloak

Keycloak selbst ist voll Open Source (Apache 2.0, CNCF-Projekt) - keine Lizenzkosten bei jeder Groesse. Bei 100.000 Nutzern wird die Betriebsarchitektur relevant, nicht die Lizenz:

• Keycloak-Cluster mit mind. 2-3 Instanzen, verteiltem Infinispan-Cache (Session-Replikation zwischen Instanzen) statt der Einzelinstanz aus der Lernumgebung.
• Externe, hochverfuegbare Postgres-Datenbank fuer Keycloak selbst (Realm-/Nutzerdaten) - separat von den fuenf Fachservice-Datenbanken.
• Wichtige Entlastung: JWT-Validierung (siehe common-security, Spring Security Resource Server) ist zustandslos - jeder Fachservice prueft Tokens lokal gegen die im Voraus gecachten JWKS-Schluessel, OHNE bei jedem Request zurueck zu Keycloak zu fragen. Keycloak-Last entsteht nur bei tatsaechlichem Login/Token-Refresh, nicht bei jedem der ~70.000 Tages-Requests aus 1.2 - Keycloaks Lastprofil ist also deutlich niedriger als das der Fachservices.

7. CDN und Objektspeicher

Aktuell nicht Teil dieses Projekts (Buchcover o. Ae. sind kein modelliertes Feature), aber bei echtem Betrieb relevant: Buchcover-Bilder und das gebaute Angular-Frontend (statische JS/CSS-Bundles) gehoeren nicht in Postgres oder in die Fachservices, sondern in einen S3-kompatiblen Objektspeicher (AWS S3, Azure Blob, oder selbstgehostet MinIO - Apache 2.0, frei) hinter einem CDN (CloudFront, Cloudflare, Azure CDN). Bei 1 Mio. Buechern mit angenommen ⌀ 50 KB je Cover ergaeben sich ~50 GB Objektspeicher - trivial im Vergleich zu den Datenbankgroessen aus Abschnitt 1.1, aber der Zugriffsmuster-Grund fuer ein CDN bleibt: Bild-Ausliefern skaliert am guenstigsten und schnellsten ueber Edge-Caching, nicht ueber die Fachservices.

8. Lizenzierung: was wirklich kostenlos ist und wo die Fallstricke liegen

Diese Sektion ist bewusst der detaillierteste Teil des Dokuments - Kapazitaetsplanung ohne Lizenzpruefung fuehrt regelmaessig zu boesen Ueberraschungen erst NACH dem Going-Live, wenn ein Anbieter eine rueckwirkende Nutzungspruefung ansetzt oder eine Lizenzaenderung greift, die beim urspruenglichen Technologie-Entscheid noch nicht galt.

8.1 Java/JDK: Oracle JDK vs. OpenJDK-Distributionen

Dieses Projekt nutzt bereits Eclipse Temurin (siehe library-platform/Dockerfile, FROM eclipse-temurin:21-jre-alpine) - eine reine OpenJDK-Distribution unter der GPLv2 mit Classpath-Exception, vollstaendig frei, ohne Zeitbeschraenkung. Das ist bereits die richtige Wahl fuer Produktivbetrieb und sollte bei Scale unveraendert bleiben. Der Fallstrick, den dieses Projekt damit bereits vermeidet, betrifft Oracle JDK:

• Seit September 2021 (Oracle No-Fee Terms and Conditions, NFTC) ist Oracles eigene JDK-Distribution fuer die JEWEILS AKTUELLE Version kostenlos nutzbar - auch produktiv.
• Der Fallstrick: die kostenlose Nutzung gilt nur fuer ein begrenztes Zeitfenster nach Erscheinen der naechsten LTS-Version. Danach braucht die weiterhin eingesetzte, aeltere Oracle-JDK-Version ein kostenpflichtiges "Oracle Java SE Universal Subscription"-Abonnement (inzwischen nach Mitarbeiterzahl der GESAMTEN Organisation lizenziert, nicht nur nach tatsaechlichen JDK-Nutzern - ein haeufiger Kostentreiber bei Audits).
• Empfehlung: bei dieser Groessenordnung (100.000 Nutzer, echtes Produktivsystem) explizit eine OpenJDK-Distribution mit langfristig kostenlosem Support-Commitment waehlen (Eclipse Temurin/Adoptium, Amazon Corretto, Red Hat build of OpenJDK) - alle bieten kostenlose Sicherheitsupdates ueber die volle LTS-Laufzeit, ohne die Oracle-Zeitfalle. Da dieses Projekt das bereits tut, ist hier keine Aenderung noetig, nur die bewusste Bestaetigung, warum das bei Scale wichtig bleibt.

Zur Groessenordnung des vermiedenen Kostenrisikos (Stand August 2026, oeffentliche Oracle-Listenpreise): Oracles "Java SE Universal Subscription" wird nach GESAMT-Mitarbeiterzahl der Organisation abgerechnet, gestaffelt von 15,00 USD/Mitarbeiter/Monat (1-999 Mitarbeitende) bis 5,25 USD/Mitarbeiter/Monat (40.000-49.999 Mitarbeitende) - NICHT nach Anzahl der JDK-Installationen. Eine Beispielrechnung zur Einordnung (Annahme: Traegerorganisation mit ca. 500 Mitarbeitenden gesamt, nicht nur das Plattform-Team - typische Bandstufe ~13-15 USD/Monat): 500 × ~14 USD × 12 Monate ≈ 84.000 USD/Jahr - ein Betrag, der anfiele, wuerde irgendwo im Unternehmen (nicht zwingend nur in diesem Projekt) unlizenziertes Oracle JDK jenseits des NFTC-Zeitfensters weiterlaufen. Durch die bereits getroffene Temurin-Entscheidung: 0 USD. Realer Marktkontext, nicht Panikmache: Verhandlungsspielraum von 20-40 % unter Listenpreis ist bei Mehrjahresvertraegen ueblich - der Punkt ist die Groessenordnung, nicht die exakte Zahl.

8.2 Redis: die Lizenzaenderung 2024 und Valkey

Redis (das Unternehmen, vormals Redis Labs) hat im Maerz 2024 die Lizenz ab Redis 7.4 von der BSD-3-Clause (klassisches Open Source) auf eine Doppellizenz aus RSALv2 (Redis Source Available License) und SSPLv1 geaendert - beide sind KEINE von der OSI anerkannten Open-Source-Lizenzen.

• Was die neue Lizenz konkret einschraenkt: im Kern nur, Redis selbst als konkurrierenden, gehosteten Cache-/Datenbank-Dienst an Dritte weiterzuverkaufen (also z. B. "Redis-as-a-Service" anzubieten). Internes Nutzen innerhalb der eigenen Anwendung (wie in diesem Projekt - Redis als Cache HINTER dem eigenen catalog-service) ist von dieser Einschraenkung nicht betroffen.
• Der eigentliche Fallstrick liegt woanders: viele grosse Cloud-Anbieter (AWS, Google Cloud) haben als Reaktion ihre verwalteten Redis-Angebote auf Valkey umgestellt - eine BSD-3-lizenzierte Fortfuehrung des letzten freien Redis-Standes, getragen von der Linux Foundation (u. a. mit AWS, Google, Oracle als Mitwirkenden). Wer verwaltete Cache-Dienste cloudseitig bucht, landet inzwischen haeufig ohnehin automatisch bei Valkey statt "echtem" Redis, ohne dass der Anwendungscode (das Redis-Protokoll ist identisch) etwas davon merkt.
• Empfehlung fuer dieses Projekt bei Scale: keine Code-Aenderung noetig (Redis-Client-Bibliotheken sprechen dasselbe Protokoll), aber bei der Wahl des VERWALTETEN Cache-Dienstes bewusst pruefen, ob "Redis" oder "Valkey" gebucht wird, und die aktuelle Lizenzlage zum Buchungszeitpunkt kurz gegenpruefen, da sich diese Landschaft seit 2024 weiterhin bewegt (z. B. hat Redis Inc. im Mai 2025 angekuendigt, mit Redis 8 wieder zu einer AGPLv3-Option zurueckzukehren - ebenfalls Copyleft, aber naeher an klassischem Open Source als RSALv2/SSPLv1).

8.3 Apache Kafka vs. Confluent Platform

Dieses Projekt nutzt laut tech-stack.md bewusst vanilla Apache Kafka (Apache 2.0, vollstaendig frei, keine Nutzungsbeschraenkung) im KRaft-Modus, OHNE Confluent-Erweiterungen. Das bleibt bei Scale die richtige, lizenzkostenfreie Wahl. Zur Abgrenzung, falls spaeter Confluent-Komponenten erwogen werden: Confluent Platform buendelt um Apache Kafka herum zusaetzliche, teils NICHT frei lizenzierte Komponenten (Schema Registry, ksqlDB, manche Connectoren stehen unter der "Confluent Community License" - kostenlos nutzbar, aber mit denselben "kein konkurrierender Managed Service"-Einschraenkungen wie RSALv2 oben, keine OSI-Lizenz). Confluent Cloud (vollstaendig verwaltetes Kafka-as-a-Service) ist ein separates, nutzungsbasiert kostenpflichtiges Angebot. Da dieses Projekt bereits das eigene, selbstgehostete Schema-Handling ueber ein manuelles schemaVersion-Feld loest (bewusste Entscheidung GEGEN Confluent Schema Registry, siehe ADR-0003 und tech-stack.md), entsteht hier auch bei Scale keine Lizenzkosten-Abhaengigkeit von Confluent.

8.4 RabbitMQ: Broadcom/VMware-Uebernahme

Die Lizenz selbst (Mozilla Public License 2.0) ist unveraendert vollstaendig frei. Relevant ist eine organisatorische, keine lizenzrechtliche Entwicklung: RabbitMQ wurde ueber Pivotal/VMware an Broadcom weitergereicht (Broadcoms VMware-Uebernahme 2023) - Broadcom ist bekannt fuer aggressive Kommerzialisierung uebernommener Produkte (siehe die parallele, vielzitierte Entwicklung bei VMware selbst). Bislang bleibt RabbitMQ Community Edition frei und aktiv weiterentwickelt (ein Teil des urspruenglichen Kernteams hat 2024 eine eigene Firma, "Cloud AMQP"/"CloudAMQP"-unabhaengig, sowie das RabbitMQ-Team ist teils zu einer neuen "Broadcom-unabhaengigen" Struktur gewechselt) - kein akuter Lizenz-Fallstrick, aber ein Beobachtungspunkt fuer eine langfristig geplante Produktivumgebung: bei kritischer Abhaengigkeit lohnt sich eine regelmaessige Neubewertung (Alternativen mit vergleichbarem Reifegrad: Amazon MQ als verwalteter Dienst, oder ein Wechsel auf ausschliesslich Kafka fuer beide bisherigen Einsatzzwecke - siehe die in ADR-0003 bereits diskutierte Abwaegung Kafka vs. RabbitMQ).

8.5 Kubernetes-Distribution: OpenShift-Subscription vs. OKD vs. verwaltetes Kubernetes

Direkt anschliessend an den in kubernetes-guide.md dokumentierten CRC/OKD-Versuch dieses Projekts - hier die Lizenzseite dieser Entscheidung:

Die grosse Preisspanne bei OpenShift ist bewusst so stehen gelassen, nicht auf eine Zahl verengt - reale Angebote haengen stark von Support-Tier (Standard/Premium), Vertragslaenge und Verhandlungsposition ab; 32.000-80.000+ USD/Jahr on top der reinen Compute-Kosten ist die richtige Groessenordnung fuer eine erste Abwaegung, kein Angebot.

Empfehlung fuer dieses Projekt bei echtem Scale: sofern keine bereits bestehende Red-Hat-Supportbeziehung/Enterprise-Anforderung vorliegt, ist verwaltetes vanilla Kubernetes (EKS/AKS/GKE) die kosteneffizienteste Wahl - das bereits vorhandene Helm-Chart (infra/helm/library-service) ist absichtlich plain-Kubernetes-kompatibel gehalten und laeuft dort unveraendert. OpenShift/OKD lohnt sich vor allem, wenn eine Organisation ohnehin schon Red-Hat-Infrastruktur betreibt oder regulatorisch striktere Standard-Security-Policies (SCC) braucht.

8.6 Container-Runtime auf Entwicklerarbeitsplaetzen: die Lizenzfrage

Dieses Projekt nutzt Podman (Red Hat, Apache 2.0) - rootless, daemonless, ohne Lizenzschwelle. podman compose und podman build lesen die vorhandenen docker-compose.yml/Dockerfile-Dateien unveraendert. Damit ist die unten beschriebene Docker-Desktop-Kostenfrage fuer dieses Projekt gegenstandslos - der Abschnitt bleibt als Kontext fuer Teams, die die Wahl noch vor sich haben.

Wichtig: Die Lizenzbedingungen betreffen ausschliesslich Docker Desktop auf Entwickler-Laptops, NICHT den Produktivbetrieb - Kubernetes-Cluster/CI-Runner nutzen containerd/buildkit bzw. Podman/Buildah direkt (Apache 2.0, immer frei).

• Docker Desktop ist kostenlos fuer Privatnutzer, kleine Unternehmen (< 250 Mitarbeitende UND < 10 Mio. USD Jahresumsatz), Bildung und Non-Profit-Open-Source-Projekte (genau die Kategorie, unter die dieses Lernprojekt faellt).
• Ein Unternehmen, das gross genug ist, um tatsaechlich 100.000 Nutzer/1 Mio. Buecher zu betreiben, ueberschreitet diese Schwelle in aller Regel deutlich - dann waere pro Entwickler eine kostenpflichtige Docker Business-Lizenz noetig. Oeffentlicher Listenpreis (Stand August 2026): grob 21-24 USD/Nutzer/Monat (jaehrliche Abrechnung, Mindestabnahme meist 5 Sitze). Fuer ein Entwicklerteam von 8 Personen (Groessenordnung fuer 9 Microservices + Frontend) waeren das grob 170-190 USD/Monat ≈ 2.000-2.300 USD/Jahr - genau der Posten, den dieses Projekt durch die Wahl von Podman von vornherein vermeidet.
• Kostenlose Alternativen zu Docker Desktop: Podman Desktop (Red Hat, Apache 2.0 - hier gewaehlt), Rancher Desktop (SUSE, Apache 2.0) oder OrbStack/Colima (macOS) - alle sprechen eine Docker-kompatible CLI/API und funktionieren mit den docker-compose.yml/Dockerfile- Dateien dieses Projekts ohne Aenderung.

8.7 Grafana: OSS vs. Enterprise, und die AGPLv3-Lizenz

Grafana selbst wechselte 2021 von Apache 2.0 auf AGPLv3 (Affero GPL, "Netzwerk-Copyleft"). Fuer die in diesem Projekt bereits etablierte Nutzungsart (Grafana intern betreiben, eigene Dashboards bauen, siehe observability.md) hat das keine praktische Auswirkung - AGPLv3 verlangt Quelloffenlegung nur, wenn man eine MODIFIZIERTE Version von Grafana selbst als Netzwerkdienst an Dritte anbietet, nicht beim reinen internen Betrieb. Grafana OSS deckt bei dieser Projektgroesse alles Benoetigte ab (Dashboards, Alerting, Datasources fuer Prometheus/Loki/Zipkin - alle bereits im Projekt verdrahtet). Grafana Enterprise (separates, kostenpflichtiges Lizenzmodell) wird erst relevant fuer Features, die dieses Projekt nicht braucht: Enterprise-SSO-Connectoren (SAML/LDAP jenseits der Basisvariante), erweiterte Reporting-/PDF-Export-Funktionen, oder vertraglicher Herstellersupport mit SLA.

8.8 Zusammenfassung: Lizenz-Ampel

Alle "0"-Eintraege sind reine Lizenzkosten - die zugehoerigen INFRASTRUKTUR-Kosten (Compute, Storage, verwaltete Dienste) fuer genau dieselben Komponenten stehen in Abschnitt 12.5, nicht hier. Beide Tabellen bewusst getrennt: Lizenz- und Infrastrukturkosten sind unabhaengige Entscheidungsachsen (man kann z. B. Apache Kafka - Lizenz 0 - trotzdem auf teurer verwalteter MSK-Infrastruktur betreiben).

9. Kurz angesprochen, bewusst nicht vertieft: DSGVO

Bei 100.000 echten Personendatensaetzen (Name, Adresse, Ausleihhistorie) greift die DSGVO real, nicht nur theoretisch - Auskunftsrecht, Recht auf Loeschung/"Vergessenwerden", Datenschutz- Folgenabschaetzung bei einem derart grossen, sensiblen Datenbestand. Das ist ein eigenstaendiges, rechtlich gepraegtes Thema und bewusst nicht Teil dieser rein technischen Kapazitaets-/Lizenzplanung - erwaehnt, damit es bei einem echten Vorhaben dieser Groessenordnung nicht uebersehen wird.

10. Skalierung auf das Zehnfache: 10 Millionen Buecher, 1 Million Nutzer

Dieselbe Rechnung wie Abschnitt 1, diesmal fuer die zehnfache Zielgroesse - mit derselben Annahmen-Methodik (keine neuen Verhaltensannahmen, nur die Basiszahlen skaliert), damit beide Groessenordnungen tatsaechlich vergleichbar sind.

10.1 Datenmenge im Vergleich

Storage bleibt weiterhin linear und unauffaellig - 150 GB ist immer noch kein Big-Data-Problem fuer Postgres. Die 75 Millionen Zeilen in loans sind aber ein echter Schwellenwert: nicht wegen der Groesse, sondern weil Wartungsoperationen (Index-Neuaufbau, VACUUM, Backups) auf einer derart grossen, ungepartitionierten Tabelle spuerbar langsamer werden und laenger blockieren koennen. Das ist der erste Punkt in diesem Dokument, an dem "einfach eine groessere Instanz buchen" nicht mehr die vollstaendige Antwort ist - siehe 10.3.

10.2 Traffic im Vergleich

Wichtiger Vorbehalt zur linearen Hochrechnung: diese Tabelle skaliert bewusst mit denselben Verhaltens-Verhaeltnissen wie Abschnitt 1 (gleiche Aktivitaetsquote, gleiche Session-Groesse) - das ist als Planungs-Baseline sinnvoll, aber real haeufig NICHT exakt linear. Groessere Nutzerbasen zeigen manchmal ueberproportional mehr Engagement (Netzwerkeffekte, mehr Bestand = mehr Grund zur Rueckkehr), manchmal unterproportional (ein grosser Anteil neuer Nutzer ist anfangs weniger aktiv als der urspruengliche Kernbestand). Die reale Zahl liegt vermutlich irgendwo um diese Baseline, nicht exakt darauf - fuer eine erste Kapazitaetsplanung ist die lineare Annahme trotzdem der richtige Ausgangspunkt (siehe 1. zur selben Begruendung).

~160-250 RPS Spitzenlast ist eine spuerbar andere Groessenordnung als die ~20-30 RPS aus Abschnitt 1 - das ist "mittlere" Web-Last, bei der einzelne Architekturentscheidungen (siehe 10.3) beginnen, tatsaechlich load-bearing statt nur "nice to have" zu sein.

10.3 Was sich NICHT nur durch groessere Server loesen laesst

Im Unterschied zu Abschnitt 1-9 (wo bei 1 Mio./100.000 fast alles mit "etwas grosszuegiger dimensionieren" erledigt ist) werden bei 10 Mio./1 Mio. einige der bisherigen "Vertiefungsaufgaben" faktisch zu Pflichtbestandteilen:

11. Kostenordnung im Vergleich (Cloud, monatlich)

Bewusst als GROESSENORDNUNG angegeben, nicht als Angebot - reale Preise haengen stark von Cloud-Anbieter, Region, Reserved-Instance-/Commitment-Rabatten und tatsaechlich verhandelten Konditionen ab. Beide Groessenordnungen nebeneinander, damit sichtbar wird, WAS ueberproportional waechst und was nicht.

Zwei Beobachtungen aus dem Vergleich:

1. Infrastrukturkosten wachsen bei diesem Sprung ungefaehr um den Faktor 3-3,5×, nicht 10× - trotz zehnfacher Buecher-/Nutzerzahl. Der Grund: ein guter Teil der Kosten bei 1 Mio./100.000 ist bereits Fixkosten fuer Verfuegbarkeit (Multi-AZ, mind. 3 Replikate/Broker/Nodes - siehe Abschnitt 2-6), die nicht linear mit der Nutzerzahl mitwachsen, sondern nur mit dem tatsaechlichen Durchsatz. Das bestaetigt die Kernaussage aus Abschnitt 1: die Nutzerzahl allein ist der falsche alleinige Massstab fuer Infrastrukturkosten.
2. Lizenzkosten wachsen NICHT gleichmaessig mit den Infrastrukturkosten: eine Container-Runtime-Lizenz auf Entwicklerlaptops (mit Podman = 0, mit Docker Desktop teamgroessenabhaengig) haengt gar nicht an Buch-/Nutzerzahl oder Infrastruktur, waehrend die OpenShift-Subscription (falls gewaehlt) ueberproportional mitwaechst, weil sie an der Cluster-Groesse/Core-Zahl haengt - der Rahmen aus Abschnitt 8 (welche Komponente ueberhaupt Lizenzkosten verursacht) bleibt bei beiden Groessenordnungen identisch, nur die konkreten Euro-Betraege einiger weniger Posten skalieren mit.

12. Inventarliste: konkrete Stueckzahlen je Betriebsmodell

Abschnitt 2-7 und 10 beschreiben Dimensionierung bewusst qualitativ ("HA-Datenbank mit Read-Replicas", "3-Knoten-Cluster"). Diese Sektion macht daraus eine konkrete Stuecklisten mit Kernen (vCPU), RAM und Speicher - je einmal fuer drei unterschiedliche Betriebsmodelle, weil sich die Antwort auf "wie viele Server brauche ich" grundlegend unterscheidet, je nachdem, ob eigene physische Hardware, eine eigene Virtualisierungsschicht oder Cloud-Dienste die Grundlage sind. Wie ueberall in diesem Dokument: Groessenordnung, kein Angebot - reale Beschaffung haengt von konkreten Server-/Instanzmodellen, Verhandlungsrabatten und der genauen Verfuegbarkeitsanforderung ab. Anders als Abschnitt 11 (bewusst anbieterneutral) wird hier AWS konkret benannt, weil explizit danach gefragt wurde - die Groessenordnung ist auf Azure/GCP sinngemaess uebertragbar, aber nicht einzeln durchgerechnet.

12.1 Die drei Betriebsmodelle

Wichtiger Befund vorab: reines Bare-Metal ohne jede Virtualisierung fuehrt zu auffaellig VIELEN physischen Servern (siehe 12.2) - die meisten Komponenten dieses Systems (Redis, RabbitMQ, Keycloak) nutzen die Kapazitaet eines modernen Servers bei weitem nicht aus, wenn sie ihn exklusiv fuer sich haben. In der Praxis wird das entweder durch eine Virtualisierungsschicht geloest (12.1 "VM") oder dadurch, dass zustandsbehaftete Komponenten wie Kafka ebenfalls ALS Kubernetes-Workload betrieben werden (ueber Operatoren wie Strimzi fuer Kafka statt dedizierter Maschinen) - hier trotzdem als eigene Spalte ausgefuehrt, weil danach gefragt wurde.

12.2 Inventarliste: 1 Million Buecher / 100.000 Nutzer

Hinweis zu Keycloak auf AWS: AWS bietet mit Amazon Cognito einen eigenen Identity-Dienst an, der aber ein ANDERES Produkt mit anderem Funktionsumfang ist (kein OIDC-Server mit Keycloaks Admin-Konsole/Realm-Modell) - ein Wechsel dorthin waere ein Architektur-Umbau, kein reiner Infrastruktur-Wechsel, und bewusst nicht Teil dieser Inventarliste.

12.3 Inventarliste: 10 Millionen Buecher / 1 Million Nutzer

Skaliert gemaess der in Abschnitt 10-11 hergeleiteten ~3-3,5-fachen Infrastruktur-Kostensteigerung (nicht 10-fach) - plus dem in 10.3 begruendeten neuen Suchcluster und der groesseren PostgreSQL-Instanz fuer die partitionierte loans-Tabelle:

12.4 Zur Nachvollziehbarkeit: Hypervisor-Hardware fuer die VM-Spalte (1 Mio./100.000-Fall)

Die 29 VMs aus 12.2 summieren sich auf ca. 190 vCPU und ~620 GB RAM Gesamtbedarf. Mit einer fuer gemischte Workloads ueblichen CPU-Ueberbuchung von 1,5:1 (RAM wird NICHT ueberbucht - ein haeufiger Fehler, der zu Swapping/OOM unter Last fuehrt) und einer N+1-Reserve (das System muss auch bei EINEM ausgefallenen Hypervisor-Host weiterlaufen):

• 4 physische Hypervisor-Hosts, je 2× 24-Kern-CPU (48 Kerne), 256 GB RAM, redundante Netzteile/RAID-Controller - fallen 3 der 4 Hosts weiter aus, tragen sie zusammen 144 Kerne/ 768 GB RAM, mehr als die 190 vCPU (bei 1,5:1-Ueberbuchung ≈ 127 physische Kerne noetig) und 620 GB RAM tatsaechlich gebraucht werden.

Das ist der konkrete, quantifizierte Vorteil von Virtualisierung gegenueber Bare-Metal in dieser Inventarliste: 29 logische Maschinen auf 4 statt 29 physischen Servern, mit weiterhin eingebauter Ausfalltoleranz.

12.5 Geschaetzte Kosten je Komponente (Bottom-up, mit realen Listenpreisen)

Abschnitt 11 schaetzt Kosten "top-down" nach Kategorie (grosszuegige Bandbreiten). Diese Sektion rechnet stattdessen "bottom-up" - je Inventar-Zeile aus 12.2/12.3 einzeln bepreist, mit am 08.2026 recherchierten oeffentlichen Listenpreisen (AWS On-Demand-Preise US-Standardregion ohne Reserved-Instance-/Savings-Plan-Rabatt, typischerweise 30-50 % guenstiger bei 1-3 Jahren Bindung; eu-central-1/Frankfurt liegt erfahrungsgemaess ca. 10-20 % darueber). Fuer On-Premise/VM gibt es keine vergleichbare oeffentliche Preisliste fuer Server-Hardware - dort sind es grobe Marktpreis-Annahmen (dual-socket Rack-Server, Standardausstattung), ausdruecklich keine Angebote. Alle Betraege in USD, da die AWS-/Oracle-/Red-Hat-Listenpreise USD-nativ sind.

Rechenweg On-Premise/VM: Kaufpreis linear ueber 5 Jahre abgeschrieben (60 Monate, uebliche Hardware-Nutzungsdauer) plus anteilige Colocation (Miete/Strom/Kuehlung/Anbindung, siehe 12.1 - recherchierter Richtwert 400-800 EUR/Monat pro Rack in einer deutschen Tier-1-Stadt, umgelegt auf die Server pro Rack). Betriebssystem bewusst mit 0 USD angesetzt (Linux-Distributionen wie Ubuntu Server/Rocky Linux sind kostenlos - passend zu den ohnehin containerisierten Workloads dieses Projekts).

1 Million Buecher / 100.000 Nutzer

10 Millionen Buecher / 1 Million Nutzer

Drei Beobachtungen aus der Bottom-up-Rechnung:

1. Sie bestaetigt die grob geschaetzten Bandbreiten aus Abschnitt 11 (2.250-6.000 USD bzw. 7.500-19.000 USD): 4.930 USD und 14.640 USD liegen beide innerhalb dieser top-down geschaetzten Spannen - zwei unabhaengige Rechenwege (Kategorie-Faustregeln vs. Instanz-fuer- Instanz-Listenpreise) kommen auf dieselbe Groessenordnung.
2. VM schlaegt sowohl Bare-Metal als auch AWS bei den reinen Infrastrukturkosten - der in 12.4 gezeigte Konsolidierungseffekt (29 bzw. 52 logische Maschinen auf wenige, grosse Hypervisor-Hosts) zahlt sich hier konkret in Dollar aus. Das ist absichtlich NICHT die ganze Geschichte - Punkt 3 relativiert das.
3. Diese Tabelle zeigt nur Infrastruktur, keine Betriebskosten (Personal) - genau das holt Abschnitt 13 nach. AWS' hoeherer Infrastrukturpreis gegenueber VM ist zu einem grossen Teil bereits eingepreister Betriebsaufwand (Patching, Hochverfuegbarkeits-Engineering, Backup-Automatisierung uebernimmt AWS) - beim On-Premise/VM-Betrieb faellt genau dieser Aufwand stattdessen als zusaetzliche Personalkosten an, siehe dort. Ein fairer Vergleich braucht beide Zahlen zusammen, nicht nur die Infrastruktur-Zeile.

Quellen der Listenpreise (oeffentliche Recherche, Stand 08.2026 - Momentaufnahmen, keine Angebote, Aenderungen durch die Anbieter jederzeit moeglich): AWS EC2/RDS/ElastiCache/MSK/Amazon MQ/OpenSearch On-Demand-Preisseiten und aggregierte Preisuebersichten (u. a. economize.cloud, instances.vantage.sh, cloudprice.net); Red-Hat-OpenShift-Listenpreis-Einordnungen (u. a. vendorbenchmark.com, faddom.com); Oracle "Java SE Universal Subscription Global Price List" (oracle.com); Docker-Business-Preisseite und Marktuebersichten (u. a. costbench.com); Colocation- Richtwerte deutscher Rechenzentren (telehouse-rechenzentrum.de, telemaxx.de); DevOps-Engineer- Gehaltsdaten fuer Deutschland (jobvector.de, stepstone.de, glassdoor.de).

13. Betriebskosten: Personal

Alle bisherigen Abschnitte behandeln Infrastruktur (Server/Dienste) und Lizenzen (Software-Nutzungsrecht) - eine dritte, in Kapazitaetsplanungen haeufig unterschaetzte Kostenachse ist Personal, das dieses System tatsaechlich betreibt: Deployments, Monitoring, Incident-Response, Kapazitaets-Nachsteuerung, Sicherheitsupdates. Bei den in Abschnitt 1 hergeleiteten, eher moderaten Traffic-Zahlen ist das keine akademische Fussnote - fuer ein System mit echten 100.000 (bzw. 1 Mio.) Nutzern reicht "das laeuft nebenbei mit" nicht mehr.

13.1 Teamgroesse (grobe Annahme, begruendet)

13.2 Grobe jaehrliche Personalkosten (Deutschland, Stand August 2026)

Recherchierte Marktdaten fuer DevOps-Engineer-Gehaelter in Deutschland (mehrere Quellen, Stand 08.2026): Median ca. 78.000 EUR brutto/Jahr, Spanne von ca. 45.000 EUR (Junior) bis 120.000+ EUR (Lead/Principal) - je nach Erfahrung und Region (Muenchen/Frankfurt tendenziell 10-15 % ueber dem Bundesdurchschnitt). Zum Bruttogehalt kommen bei einer Festanstellung in Deutschland ueblicherweise weitere ca. 20-25 % Arbeitgeber-Lohnnebenkosten (Sozialversicherung) hinzu - macht grob 95.000-100.000 EUR Arbeitgeber-Gesamtkosten pro FTE/Jahr bei einem mittleren Gehaltsniveau.

13.3 Die eigentliche Erkenntnis: Personal, nicht Infrastruktur, dominiert die Gesamtkosten

Vergleich mit den Infrastruktur-Summen aus 12.5 (auf EUR/Monat umgerechnet, grob 1 USD ≈ 0,92 EUR Stand 08.2026):

Das ist kein Nebeneffekt dieser speziellen Rechnung, sondern ein bekanntes Muster in der Branche: bei Systemen dieser Groessenordnung (nicht Hyperscale wie ein globaler Streaming-Dienst) dominieren ueblicherweise Personalkosten, nicht Infrastrukturkosten, die Gesamt-TCO - einer der Hauptgruende, warum verwaltete Cloud-Dienste (RDS statt Postgres-auf-VM, MSK statt selbstbetriebenem Kafka) trotz hoeherer Infrastruktur-Rechnung oft trotzdem die guenstigere Gesamtoption sind: sie verschieben einen Teil des sonst noetigen Personalaufwands (Patching, Failover-Engineering, Backup-Verifikation) in den bereits eingepreisten Dienst. Diese Rechnung ist bewusst grob (siehe 13.4) - die Groessenordnung des Verhaeltnisses (Personal dominiert) ist der eigentliche Punkt, nicht die exakte Zahl.

13.4 Was diese Personalkostenrechnung NICHT einschliesst

• Produktentwicklung: dieses Team betreibt das System, entwickelt es aber nicht inhaltlich weiter (neue Features) - dafuer waere ein separates, hier nicht mitgezaehltes Entwicklungsteam noetig.
• Bereitschaftsdienst-Zuschlaege: viele Unternehmen zahlen fuer Rufbereitschaft/Nachtdienst zusaetzliche Praemien - hier bewusst nicht extra eingerechnet, in der oberen Bandbreite der Gehaltsschaetzung implizit mit abgedeckt.
• Fluktuations-/Einarbeitungskosten, Tooling-Lizenzen fuer das Team selbst (IDEs, interne Zusammenarbeits-Tools) - klein im Vergleich zu den Gehaltszahlen, hier nicht separat gefuehrt.
• Standort-/Marktabhaengigkeit: die Zahlen gelten fuer den deutschen Arbeitsmarkt (Stand 08.2026) - ein Remote-First-Team mit Mitgliedern in guenstigeren Arbeitsmaerkten koennte spuerbar guenstiger sein, ein Team ausschliesslich in Muenchen/Frankfurt spuerbar teurer.

14. Bewusst ausserhalb des Scopes dieses Dokuments

• Tatsaechliche Lasttests in dieser Groessenordnung: die vorhandenen k6-Tests (siehe teststrategie.md) laufen bislang nur gegen die lokale Lernumgebung in Spielzeug-Groessenordnung - eine echte Verifikation der hier hergeleiteten RPS-Schaetzung erfordert einen dedizierten Lasttest gegen eine produktionsnahe Umgebung.
• Multi-Region-/Disaster-Recovery-Design: hier nur "Multi-AZ" innerhalb einer Region behandelt, nicht ein vollstaendiges Multi-Region-Failover-Konzept.
• Konkrete Server-/Instanzmodelle als Beschaffungsvorlage: die Angaben in Abschnitt 12 sind Groessenordnungen zur Orientierung, kein pruefbares Lastenheft - eine echte Beschaffung braucht Angebote konkreter Hersteller/Cloud-Kontingente.
• Tatsaechliche Umsetzung: dieses Dokument ist eine Planungsgrundlage, kein durchgefuehrtes Deployment - anders als der real durchgefuehrte (und an Ort und Stelle dokumentierte) kind-Cluster-Test in kind-cluster.md.