NoBaxx · FallstudieSeit 03/2026

Azure-Zielarchitektur für eine Multi-Tenant-SaaS-Plattform

Zielarchitektur für antibaxx360, ein mandantenfähiges SaaS-ERP auf Azure: Container Apps, in der Datenbank erzwungene Mandantentrennung und tiefe Microsoft-Integration von Entra ID bis Graph.

86
Tenant-isolierte Tabellen unter RLS: 44
Domain-Module im NestJS-Monolithen: 22
Architecture Decision Records: 12
BullMQ-Queues im Worker

antibaxx360-Zielarchitektur auf Azure, vereinfachter Ausschnitt

Rolle

Lead Software Engineer: Ende-zu-Ende-Verantwortung für die Lösungsarchitektur, Engineering-Standards und Führung eines Teams von fünf Entwicklern.

Kontext

NoBaxx betreibt antibaxx360, ein SaaS-ERP für die Schädlingsbekämpfung, ausgelegt auf rund 10.000 Kunden und etwa 8.000 Standorte. Die Plattform läuft heute als Dev- und Beta-Umgebung auf Hetzner und ist per Architekturentscheidung von Anfang an für den Produktivbetrieb auf Azure Container Apps gebaut.

Aufgabe

Aus 22 Architecture Decision Records und der realen Codebase soll eine belastbare Azure-Zielarchitektur entstehen: geschäftskritischer Betrieb, verlässlicher Außendienst und revisionssichere Dokumentation auf einer Plattform, deren Mandantentrennung die Datenbank selbst erzwingt.

Rahmenbedingungen

Mandantentrennung muss die Datenbank erzwingen: Row-Level-Security mit FORCE-Policies auf 86 Tabellen, abgesichert durch ein eigenes CI-Gate
Das Chromium-PDF-Rendering im Worker braucht ein eigenes Skalierungs- und Speichermodell (2 bis 4 GB RAM)
EU-Datenresidenz und DSGVO-Löschpfade für HACCP- und IFS-auditierte Kunden
Kleines Team von fünf Entwicklern: Managed Services statt Eigenbetrieb, Umstieg als Konfiguration statt Umbau

Architekturansatz

Ein Ingress, zwei Compute-Workloads, drei Managed-Data-Services: Azure Front Door Premium mit WAF am Edge, drei React-SPAs aus Static Web Apps, der NestJS-Monolith und der BullMQ-Worker als Container Apps im VNet, dahinter Azure Database for PostgreSQL (Flexible Server, zonenredundante HA), Azure Cache for Redis und Blob Storage mit Defender-Malware-Scan, erreichbar ausschließlich über Private Endpoints.

Skalierung folgt der Arbeit: Die API skaliert über HTTP-Concurrency, der Worker über KEDA anhand der Redis-Queue-Länge, das PDF-Rendering bekommt sein eigenes Speicherprofil. Ein Migrate-Job (Prisma plus RLS-SQL) läuft als Gate vor jeder neuen Revision.

Sicherheit in sieben Schichten: WAF und Rate-Limits am Edge, JWT und OIDC-SSO, Row-Level-Security als primäre Mandantentrennung, App-Layer-Kryptografie, ein manipulationsevidentes Audit-Log mit Hash-Kette, Private Endpoints im Netz und EU-Datenresidenz in Germany West Central.

Tief in der Microsoft-Plattform: Entra ID für OAuth und Kunden-SSO, produktiver Zwei-Wege-Outlook-Sync über Microsoft Graph, Exchange Online für den CRM-Posteingang, Key Vault und Managed Identity für Secrets, Application Insights für Observability. Deployt wird über GitHub Actions in die Container Registry, provisioniert per Infrastructure as Code.

Zentrale Entscheidungen

Modularer Monolith statt Microservice-Zoo

44 Domain-Module in einem NestJS-Monolithen mit vier sauber getrennten API-Surfaces: ein Deployment, klare Grenzen, passend zur Teamgröße (ADR-001).

Mandantentrennung erzwingt die Datenbank

PostgreSQL Row-Level-Security mit FORCE-Policies auf 86 Tabellen, ein Laufzeit-User ohne Bypass-Recht und ein CI-Gate, das jede ungeschützte Tabelle blockiert: Isolation ist erzwungen, nicht Konvention.

Skalierung auf Arbeit, nicht auf Traffic

KEDA skaliert den Worker anhand der Redis-Queue-Länge, unabhängig von der API; genau das Modell, das das Chromium-PDF-Rendering mit seinem Speicherprofil braucht (ADR-006).

Cloud-Portabilität von Anfang an

Identische Container-Images für Dev und Produktion und ein pluggables Storage-Interface mit fertigem Azure-Blob-Provider: Der Azure-Umstieg ist Konfiguration statt Umbau (ADR-009, ADR-022).

Azure, weil das Produkt bereits Microsoft spricht

Der Outlook-Kalender-Sync über Microsoft Graph läuft produktiv, Kunden-Identitäten liegen oft in Entra ID, und die EU-Region ist für auditierte Kunden ein Türöffner: Hosting, Identität und Integration rücken in eine Plattform zusammen.

Technologien & Schwerpunkte

Azure: Front Door Premium + WAF, Static Web Apps, Container Apps + KEDA, Container Apps Jobs, PostgreSQL Flexible Server, Azure Cache for Redis, Blob Storage + Defender, Key Vault, Managed Identity, Application Insights, VNet + Private Endpoints, Container Registry, Azure DNS
Microsoft-Integration: Microsoft Entra ID (OAuth, SSO), Microsoft Graph (Outlook-Sync), Exchange Online, Azure Communication Services (E-Mail)
Engineering: NestJS, React, Flutter, PostgreSQL + PostGIS, Row-Level-Security, Prisma, BullMQ + Redis, GitHub Actions, Bicep/Terraform

Status & Ergebnis

Laufend seit 03/2026. Die Azure-Zielarchitektur ist aus 22 ADRs und der realen Codebase abgeleitet; der Migrationspfad von der Hetzner-Dev-Umgebung nach Azure ist in sieben Schritten definiert, inklusive ehrlich benannter Lücken vor dem Go-Live.