Einfach zu skalieren

Wir wissen, dass eng gekoppelte Systeme fragile Systeme sind. Mikro-Module oder servicebasierte Strukturen werden auch bei Monolithen verwendet. Die Gruppierung erfolgt nach Funktionen/Domänen, nicht nach technischen Schichten (Domain-Driven Design lite). Frontend und Backend sind über API-Verträge (OpenAPI, GraphQL) entkoppelt. Vorteile: Einfaches Isolieren, Skalieren oder Ersetzen von Modulen, ohne das gesamte System zu brechen.

Wir wählen skalierbare, überall lauffähige Laufzeiten (hauptsächlich Node.js) für das Backend. PostgreSQL, cloud-kompatible PostgreSQL-Datenbanken, Supabase, Firebase werden bei Bedarf verwendet. Redis wird für hohen Leseverkehr oder Caching integriert. Cloud-native Infrastruktur und Docker werden verwendet: AWS / GCP / — mit Unterstützung für automatisches Skalieren. Obskure Werkzeuge, die nicht horizontal skalieren können oder an Community-Unterstützung mangeln, werden vermieden.

Wir wissen, dass nicht alles in Echtzeit geschehen muss. Lang laufende oder Hintergrundaufgaben (E-Mails, Bildverarbeitung, Abrechnung) werden an Warteschlangen usw. ausgelagert. Beispiel: Nach der Anmeldung eines Benutzers wird die Abrechnung/E-Mail im Hintergrund verarbeitet, nicht inline. Dies hilft für bessere Leistung und Skalierbarkeit.

Wir wissen, dass ein schlechtes Schema = zukünftige Nacharbeit bedeutet. Versionierte APIs (/api/v1/...) werden verwendet, um brechende Clients zu verhindern. UUIDs werden gegenüber inkrementellen IDs bevorzugt (z.B. für das Zusammenführen von Daten über Regionen hinweg). Multi-Tenancy ist geplant (insbesondere in SaaS): Zeilenebene vs. Schemaebene Trennung, tenant_id früh hinzufügen.

Wir wissen, dass man nicht skalieren kann, was man nicht sehen kann. Tools wie Sentry werden für das Frontend-Fehlertracking verwendet; Prometheus für die Backend-/Infrastrukturbeobachtbarkeit; PostHog, Google Analytics für die Produktanalyse; fortlaufende Überprüfungen für die Überwachung von Ausfallzeiten. Warnungen (Slack/E-Mail) sind für Abstürze, Warteschlangenrückstände, DB-Spitzen usw. eingerichtet.

Wir wissen, dass Monolithen skalieren können, aber zustandslose Dienste besser skalieren. Das Speichern von Benutzersitzungen im lokalen Speicher wird vermieden — Redis/Sitzungsspeicher werden verwendet. Server werden zustandslos gemacht, damit sie leicht dupliziert werden können. Containerisierung wird verwendet: Docker + Orchestratoren (Cloud-Anbieter). Dies ermöglicht Autoscaling ohne sticky sessions oder Engpässe im gemeinsamen Speicher.

Wir wissen, dass mehr Benutzer = mehr Angriffsfläche bedeutet. RBAC/ABAC-Muster (rollenbasierte Zugriffskontrolle) sind eingerichtet. Ratenbegrenzung, Eingangsvalidierung und Sicherheitsheader werden angewendet. Geheimnisse werden in Tresoren aufbewahrt und rotiert.

API-Schicht: Ratenbegrenzung, Paginierung, GraphQL-Föderation (falls erforderlich) sind implementiert. Frontend: Lazy Loading, CDN-Hosting, Code-Splitting werden verwendet. Autoscaling wird eingesetzt. Datenbank: Indizes werden neu indiziert, Sharding ist geplant, falls erforderlich, und so weiter.