MABEA/arbeitskacheln/19_satelliten_server.md

Epic 19 — Satelliten-Server

Details zu SAT-001 (Platzhalter/Architektur-Vorbereitung). Übernommen aus arbeitskarten/13_satelliten_server.md (Karte 13) — die größte gefundene Lücke im 16-Epic-Backlog: eine bereits "entschieden" gewertete Architektur-Erweiterung mit konkreten Datenmodell-Konsequenzen, die in keinem der 16 ursprünglichen Epics erwähnt war.

---

SAT-001 — Hauptserver mit Satelliten-Servern

• Ziel: Zusätzlich zum Hauptserver können Satelliten-Server existieren, die lokal (Einsatzort/Wache) laufen und temporär vom Hauptserver getrennt sind — für KatS- Einsatzlagen ohne Internet, Wachen mit dauerhaft schlechter Anbindung, oder reinen Ausfallschutz.
• Beschreibung: Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon (gleiche Software/API/DB), kein reiner Cache — mehrere Mitarbeiter können gleichzeitig am Satelliten arbeiten. Autark-Dauer bewusst nicht zeitlich begrenzt (Stunden bis Tage). Konfliktvermeidung statt Konfliktlösung: jedes Objekt ist während einer Trennung fest genau einem Server zugeordnet (Haupt- oder ein bestimmter Satellit), am jeweils anderen für Schreibzugriffe gesperrt — dadurch strukturell kein "wer gewinnt"-Problem.
• Benutzerwert: Betrieb bleibt auch bei längerem/vollständigem Verbindungsverlust einsatzfähig, ohne Datenkonflikte beim späteren Zusammenführen.
• Abhängigkeiten: FOUND-002, ASSET-003, MOBILE-003 (Abgrenzung: Satellit ist die Lösung für ganze Standorte über längere Zeit, MOBILE-003 für Kurzzeit-Netzlücken innerhalb einer einzelnen Kontrolle)
• Datenmodell: Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder Satelliten-ID), änderbar nur durch bewussten Auslagerungs-/Rückhol-Vorgang. IDs systemweit eindeutig von Anfang an (kein lokal generierter, kollisionsanfälliger Schlüssel) — Voraussetzung für widerspruchsfreies Zusammenführen. Sync überträgt neu entstandene Datensätze per Insert und geänderte bestehende Zeilen (offene Fehlbestände, aktive Mindermengen-Genehmigungen, Objektpositionen) per Upsert.
• Backend: Auslagerungs-/Rückhol-Endpunkte, Sync-Logik (Insert+Upsert), Schreibsperre für ausgelagerte Objekte am Hauptserver
• Frontend: Admin-UI zum Auslagern/Zurückholen
• Mobile: kein Unterschied — Satellit spricht dieselbe API
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: zeigt ggf. aktuellen Server-Zuordnungsstatus
• Rechte: Auslagerung/Rückholung: Administrator
• Audit: Auslagerung/Rückholung geloggt, Sync-Vorgänge nachvollziehbar
• Akzeptanzkriterien: Objekt an Satellit auslagern → am Hauptserver für Schreiben gesperrt; nach Rückholung sind alle am Satelliten entstandenen/geänderten Daten korrekt im Hauptserver.
• Tests: Sync-Test (Insert neuer Datensätze + Upsert geänderter bestehender Zeilen), Schreibsperre-Test während Auslagerung.
• DoD: DECISION REQUIRED zum Umsetzungszeitpunkt — Nutzer-Entscheidung aus früherer Session: "erstmal nur mit Hauptserver", also bewusst zurückgestellt. Offene Punkte vor Umsetzung: technischer Auslöser der Auslagerung (manuell vs. automatisch bei Verbindungsverlust), Vorab-Bestückung des Satelliten mit Stammdaten, Verhalten bei laufender Kontrolle während Auslagerung/Rückholung, Hardware-Anforderung.

---

MABEA-Ist-Stand-Abgleich: nicht umgesetzt, bewusst zurückgestellt (Nutzer-Entscheidung "erstmal nur mit main server gemacht"). Diese Epic-Datei existierte bislang nicht — reine Nachdokumentation der bereits getroffenen Architektur-Entscheidung, damit sie im Backlog nicht verloren geht, bis ein konkreter Bedarf zur Umsetzung führt.

Referenzen

Alte Arbeitskarte (übernommen, Karten-Datei gelöscht): Karte 13 Hauptserver mit Satelliten-Servern. Weiterhin gültige Detail-Referenz (nicht gelöscht, eigenständiges Prompt-Ergebnisdokument): ergebnisse/17_mobile_offline.md Abschnitt 7, ergebnisse/20_datenbank_schema.md Punkt 10.