Blog
Strategien und technische Lösungen, um Power Pages mit modernen Webframeworks und Cloud-Technologien zu erweitern und komplexe Geschäftsprozesse umzusetzen
Ich habe den Stack so umgebaut, dass Browser und Extension nur noch Traefik sehen. Der Rest läuft über zwei Docker Netze, klare Labels und keine direkten Host-Ports mehr.
Vor dem Launch habe ich meine Architektur nicht nur auf Skalierung geprüft, sondern auch auf stillschweigende Sicherheitsannahmen. Dabei sind mir zwei kleine Lücken aufgefallen, die in Produktion sehr schnell teuer werden können.
Ich habe gelernt, dass ein Docker Named Volume in Produktion nicht automatisch auf einem Hetzner Volume landet. Erst wenn ich den Pfad bewusst steuere, weiß ich wirklich, wo Qdrant, Redis und Zertifikate geschrieben werden.
Ich behandle die Wahl des Embedding-Modells nicht als austauschbare Umgebungsvariable. In Qdrant schreibt sie sich direkt in jede Collection ein. Wer lokal und in Produktion auf unterschiedliche Vektorräume setzt, baut sich eine teure Migration in die Zukunft ein.
Ein sequenzielles await-chain im DELETE-Account-Endpoint bedeutet: wenn Qdrant fehlschlägt, bleiben S3-Daten und die Zitadel-Identität erhalten. Das ist ein DSGVO-Art.-17-Risiko. Die Lösung ist Promise.allSettled mit strukturierter Fehlerrückgabe. Gleichzeitig: wie ein OOM-Crash im Export-Endpoint durch Batching verhindert wird.
Ohne Rate Limiting kann ein einzelnes Skript den AI-Provider-Key innerhalb von Minuten leerlaufen lassen. Die Lösung sind zwei unabhängige Schichten: Traefik begrenzt auf IP-Ebene, express-rate-limit mit Redis-Backing begrenzt pro authentifiziertem Nutzer. Warum beide Schichten nötig sind und wie der TypeScript-Tücke beim Redis-Adapter umgangen wird.
