Architektur-Patterns

Architektur-Patterns

BFF-Pattern (Backend for Frontend)

Browser kommuniziert nie direkt mit dem Go-Backend. Alle API-Calls laufen serverseitig ueber TanStack Start Server Functions.

Browser → Cloudflare (fuegt CF-Header hinzu) → TanStack Start SSR → Go Backend

Das Frontend liest Cloudflare-Header (IP, Country, Ray-ID, User-Agent) und leitet sie als X-Headers an das Backend weiter. Das Backend baut daraus einen RequestContext fuer jeden UseCase.

Pages Function als Fassade

Kontaktformular und Analytics laufen ueber Cloudflare Pages Functions, die an AWS API Gateway weiterleiten. API Gateway ist nie direkt vom Client erreichbar.

Besucher → Pages Function → API Gateway → SQS

SQS als Puffer

Kontaktformular-Events und Analytics-Events werden in SQS geschrieben. CMS pollt asynchron. Tracking und Formulare funktionieren auch bei CMS-Downtime.

Medien Dual-Write

Upload geht nach Cloudflare R2 (Primary, EU Jurisdiction). CMS spiegelt async nach AWS S3-IA Frankfurt (Disaster Recovery, 3x Retry).

Asynchroner E-Mail-Versand

Dreistufiger, vollstaendig asynchroner Versand (nach BIS-Vorbild):

1. UseCase erstellt Business-Event
2. Preparation-Worker rendert Templates und erstellt Queue-Eintraege
3. Dispatch-Worker versendet via SES/SMTP

Entkoppelt, idempotent, mit Audit-Trail.

Audit-Pattern

Jede Business-Tabelle hat History-Tabelle + Trigger fuer:

• Temporal History (System-Time via row_period)
• Optimistic Locking (row_version)
• Soft-Delete-Log (audit_deletions)

Service-API (Astro ↔ CMS)

CMS stellt eine Service-API bereit, ueber die Astro beim Build Content abholt. Authentifizierung via X-Service-Token (nicht Cookie-basiert).

Endpoint	Beschreibung
POST /api/service/templates/sync	Template-Sync aus Astro
GET /api/service/sites/{siteId}/content?locale=de	Content fuer SSG