Microservice-Umbau Wabenhain: Schnitt nach Lastprofil (web/api/worker), offen #30

New Issue

2026-10-16T05:59:26Z

Nick.Rosenloecher commented

2026-10-16 05:59:26 +00:00

Ziel

Wabenhain lässt sich im RKE2-Cluster in Teilen verwalten, anpassen und skalieren, ohne die knappe Cluster-CPU mit Dauer-Pods zu belasten.

Umgesetzt

Ist-Analyse vom 2026-10-10: Next.js-16-Monolith mit 23 API-Routen, 25 Server-Action-Dateien und 64 Dateien in app//components/ mit direktem Prisma-Zugriff; Rate-Limiter im Speicher (deshalb replicas: 1, Recreate); ffmpeg im Web-Request
Für ApiCore ist Option A entschieden (ein Image, Rollen api/worker/job, Event-Outbox); für Wabenhain steht die Entscheidung aus
Vorarbeiten, die schon erledigt sind: Upload- und Rechnungs-PVCs im Cluster RWX (Voraussetzung für mehrere Pods), Hintergrundarbeit als Skripte im Werkzeug-Image (wabenhain-tools)

Offen

Inhaber klärt das Hauptziel: ausfallfrei deployen, Lastspitzen abfangen oder wiederverwendbares Shop-Backend
Spec mit Schnitt nach Lastprofil (Tendenz: web/api/worker statt Fachdomänen), danach Umsetzungsplan
Rate-Limiter auf einen gemeinsamen Store umstellen (Voraussetzung für replicas > 1)
ffmpeg-Transcode aus dem Web-Request in einen Job verlagern
Danach RollingUpdate statt Recreate und mehr als eine Replica

Abhängigkeiten / Blocker

Wartet auf die Entscheidung des Inhabers zum Hauptziel.

Offene Entscheidungen

Hauptziel des Umbaus; ob Wabenhain dem ApiCore-Muster (Option A) folgt.

Grundlage

Memory „microservice-umbau-wabenhain-apicore“; ApiCore-Repo docs/superpowers/specs/2026-10-12-plattform-rueckgrat-und-fahrplan-design.md. Verwandt: #8, #11, #29.

Status

Code: nein · Geprüft: nein · Gemergt: nein · Produktiv: nein
Stand: 2026-10-16 (Quelle: git origin/main 35e7c84, Cluster-Abfrage nur lesend am 2026-10-16, Session-Status, Memory)

## Ziel Wabenhain lässt sich im RKE2-Cluster in Teilen verwalten, anpassen und skalieren, ohne die knappe Cluster-CPU mit Dauer-Pods zu belasten. ## Umgesetzt - [x] Ist-Analyse vom 2026-10-10: Next.js-16-Monolith mit 23 API-Routen, 25 Server-Action-Dateien und 64 Dateien in `app/`/`components/` mit direktem Prisma-Zugriff; Rate-Limiter im Speicher (deshalb `replicas: 1`, `Recreate`); ffmpeg im Web-Request - [x] Für ApiCore ist Option A entschieden (ein Image, Rollen api/worker/job, Event-Outbox); für Wabenhain steht die Entscheidung aus - [x] Vorarbeiten, die schon erledigt sind: Upload- und Rechnungs-PVCs im Cluster RWX (Voraussetzung für mehrere Pods), Hintergrundarbeit als Skripte im Werkzeug-Image (`wabenhain-tools`) ## Offen - [ ] Inhaber klärt das Hauptziel: ausfallfrei deployen, Lastspitzen abfangen oder wiederverwendbares Shop-Backend - [ ] Spec mit Schnitt nach Lastprofil (Tendenz: web/api/worker statt Fachdomänen), danach Umsetzungsplan - [ ] Rate-Limiter auf einen gemeinsamen Store umstellen (Voraussetzung für `replicas > 1`) - [ ] ffmpeg-Transcode aus dem Web-Request in einen Job verlagern - [ ] Danach `RollingUpdate` statt `Recreate` und mehr als eine Replica ## Abhängigkeiten / Blocker Wartet auf die Entscheidung des Inhabers zum Hauptziel. ## Offene Entscheidungen Hauptziel des Umbaus; ob Wabenhain dem ApiCore-Muster (Option A) folgt. ## Grundlage Memory „microservice-umbau-wabenhain-apicore“; ApiCore-Repo `docs/superpowers/specs/2026-10-12-plattform-rueckgrat-und-fahrplan-design.md`. Verwandt: #8, #11, #29. ## Status Code: nein · Geprüft: nein · Gemergt: nein · Produktiv: nein Stand: 2026-10-16 (Quelle: git origin/main 35e7c84, Cluster-Abfrage nur lesend am 2026-10-16, Session-Status, Memory)

Nick.Rosenloecher added the art/technik blockiert prio/mittel status/offen labels 2026-10-16 05:59:26 +00:00

Nick.Rosenloecher referenced this issue

2026-10-16 05:59:34 +00:00

Inhaber-Aufgaben (Sammelliste) #33

Nick.Rosenloecher referenced this issue

2026-10-16 05:59:38 +00:00

Projektstand und Übersicht (Stand 2026-10-16) #34

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Nick.Rosenloecher/Wabenhain#30