Projekt: Overtime

Damit die Inhalte in diesem Wiki nicht abstrakt bleiben, beziehen sich alle Entscheidungen auf ein fiktives Referenzprojekt namens Overtime: eine mandantenfähige (Multi-Tenant) B2B-Team-Kollaborationsplattform für Unternehmen – im Charakter vergleichbar mit Slack oder Microsoft Teams.

Overtime bietet Text-Chats in Channels, direkte Nachrichten, Video-Calls, Datei-Uploads und Nutzerverwaltung. Daraus ergeben sich einige der technischen Herausforderungen, die in den ADRs immer wieder auftauchen:

• Echtzeit-Daten: Hohes Aufkommen an WebSocket-Verbindungen und WebRTC für Video-Telefonie – latenzkritisch und operativ überwachungsbedürftig.
• Unstrukturierte Daten: Massiver Speicherbedarf für hochgeladene Dateien, gelöst über S3-kompatiblen Object Storage (z.B. MinIO).
• PII-Gefahr: Nutzer:innen tippen unkontrolliert sensible Daten (Telefonnummern, E-Mail-Adressen, Namen) in Chats. Diese Daten dürfen niemals ungefiltert im zentralen Log-System landen – strikte Einhaltung von DSGVO/GDPR und Zero-Trust-Prinzipien ist Pflicht, nicht Kür.

Da Overtime rein fiktiv ist und nicht existiert, kann ich hier offen über Architektur-Entscheidungen schreiben, ohne Rücksicht auf reale Kund:innen, Verträge oder Geschäftsgeheimnisse nehmen zu müssen.

Mir geht es bei diesem Projekt bewusst weniger um die Chat-Anwendung selbst, sondern um das Drumherum: Supply Chain, Cluster-Härtung, GitOps, Observability und Datenschutz. Die einzelnen Kategorien dieses Wikis (siehe Navigation) gehen jeweils vertieft auf einen dieser Bereiche ein.

Von der Theorie zur Praxis (PoC)

Die in den ADRs dokumentierten Entscheidungen sind keine reine graue Theorie. Um die Machbarkeit, die Trade-offs und die Sicherheitsaspekte real zu prüfen, habe ich die Kernkomponenten dieser Architektur in einer privaten Proof-of-Concept-Umgebung (PoC) funktional implementiert. Von den Buildah-Pipelines über den Kubernetes-Betrieb bis hin zur GitOps-Synchronisation via ArgoCD entspricht die Dokumentation dem real von mir deployten und evaluierten Setup.

Ziel: Unabhängigkeit von externen Diensten

Ein zentrales Ziel des Projekts ist, den Betrieb schrittweise so zu bauen, dass er vollständig ohne externe, gehostete Dienste läuft – also möglichst viel selbst betrieben und selbst gehärtet wird, statt auf verwaltete Cloud-Services zu setzen. Deswegen setze ich beispielsweise in der ersten Phase übergangsweise Sealed Secrets, die mit einem zentralen Schlüssel pro Cluster entschlüsselt werden, statt z.B. den Azure Key Vault oder AWS Secrets ein. Im nächsten Schritt ist ein eigener Betrieb von HashiCorp Vault geplant.

Warum Python / Django / Gunicorn als Backend?

Für das Overtime-Backend habe ich mich für Python mit Django und Gunicorn entschieden – nicht, weil das die naheliegendste Wahl für eine Real-Time-Kollaborations-Anwendung wäre, sondern weil sich damit die Themen, die mich eigentlich interessieren, gut abbilden und testen lassen (z.B. Structlog oder PII Scrubbing).

Für eine echte, auf viele gleichzeitige WebSocket-Verbindungen und niedrige Latenz optimierte Chat-Anwendung wäre in der Praxis eher Go oder Rust die naheliegendere Wahl: Beide bieten mit Goroutinen bzw. async/Tokio eine deutlich leichtgewichtigere Nebenläufigkeit pro Verbindung als Djangos klassisches, synchrones WSGI-Modell mit Gunicorn-Workern. Für dieses Lernprojekt überwiegt für mich aber der Vorteil, mit einem ausgereiften, gut dokumentierten Ökosystem an Observability- und Security-Tooling zu arbeiten – die Backend-Sprache selbst ist hier bewusst zweitrangig.

Infrastruktur: drei Cluster

Der Betrieb ist aktuell auf drei separate, CIS-gehärtete K3s-Cluster aufgeteilt – K3s primär, um in der privaten PoC-Umgebung Ressourcen zu sparen:

• Management-Cluster: overtime-management - zentrale Tools, u. a. ArgoCD, das von hier aus die Staging- und Produktionsumgebung ausrollt.
• Test-Cluster overtime-staging
• Produktions-Cluster overtime-production

Weil das Projekt bewusst klein anfängt, sind einige Komponenten, die man in einer echten Produktionsumgebung normalerweise hochverfügbar (HA) betreiben würde, aktuell bewusst vereinfacht – zum Beispiel die Cluster selbst, oder ein einfaches Helm-Chart statt eines Datenbank-Operators mit HA, oder lokale MinIO-Pods statt eines abgesicherten, externen S3-Dienstes. Diese Abstriche sind an den jeweiligen ADRs entsprechend als bewusste, dokumentierte Trade-offs markiert und keine übersehenen Lücken.

Das initiale Cluster-Setup geschieht im Moment mit Ansible statt anderer Infrastructure-As-Code-Alternativen, die besser für Cloud-Umgebungen geeignet sind.

GitOps: GitLab statt GitHub

Für dieses Projekt nutze ich GitLab (CI/CD-Pipelines, Container-Registry, GitOps-Repository), welches sich selbst hosten lässt. Die zugrunde liegenden Konzepte – Pipelines, GitOps mit ArgoCD, Registry-Integration – sind Plattform-agnostisch; ein Umbau auf GitHub (Actions statt GitLab CI) würde sich sehr ähnlich gestalten.

Aktueller Stand: Work in Progress

Overtime ist ein laufendes Lernprojekt, kein abgeschlossenes System. Offene Baustellen, an denen ich aktuell arbeite bzw. die noch anstehen:

• Dokumentation Cluster Setup
• Weitere Härtung der Cluster
• Namespace-Isolation
• Zentrales Logging
• HashiCorp Vault als zentrales Secret-Management
• Auditing
• Policy-Engines (z. B. Admission Control)
• und noch viel mehr, woran ich noch nicht gedacht habe

Diese Liste wird sich mit neuen ADRs in den jeweiligen Kategorien laufend erweitern.