← Back to portfolio← Zurück zum Portfolio
Work in progressIn Arbeit
// Project — architecture & spec drafting// Projekt — Architektur & Spezifikation

🛡️ On-Prem Backend PlatformOn-Prem-Backend-PlattformGo

A fault-tolerant backend designed to run on a company's own hardware with automatic failover — or as managed SaaS, from a single codebase. It serves both strictly regulated organizations (finance, healthcare, government) and moderately security-conscious teams without forking. Ein ausfallsicheres Backend, das auf der eigenen Hardware eines Unternehmens mit automatischem Failover läuft — oder als Managed SaaS, aus einer einzigen Codebasis. Es bedient streng regulierte Organisationen (Finanzen, Gesundheit, Behörden) ebenso wie moderat sicherheitsbewusste Teams, ohne Fork.

GoKubernetes / k3setcd · Consul TauriEd25519Distributed Systems

The guiding principleDas Leitprinzip

Security- and operations-relevant decisions are made by IT admins, centrally and once. End users are never asked to make a choice that could weaken security — by mistake or otherwise. Every decision below follows from that rule. Sicherheits- und betriebsrelevante Entscheidungen treffen IT-Admins — zentral und einmalig. Endnutzer werden nie vor eine Wahl gestellt, die die Sicherheit schwächen könnte — weder versehentlich noch absichtlich. Jede Entscheidung unten folgt aus dieser Regel.

Decisions captured so farBisher getroffene Entscheidungen

01 — Language & stackSprache & Stack

GoGo

Compiles to a single static binary — trivial to hand to any IT team, no runtime to install. A mature distributed-systems ecosystem (etcd, Consul), strong built-in concurrency, near-C performance, and a lighter footprint than the JVM with a gentler learning curve than Rust. Kompiliert zu einer einzigen statischen Binärdatei — einfach an jedes IT-Team zu übergeben, kein Runtime nötig. Reifes Distributed-Systems-Ökosystem (etcd, Consul), starke eingebaute Nebenläufigkeit, Performance nahe C und ein leichterer Fußabdruck als die JVM bei flacherer Lernkurve als Rust.

02 — Failover topologyFailover-Topologie

Two nodes, a coordinator, a replicated DBZwei Nodes, ein Koordinator, eine replizierte DB

Two Go nodes behind a load balancer, a cluster coordinator (Consul or etcd) running independent health checks, and a database shared by both. On Kubernetes (or lighter k3s): a Service, a Deployment with 2+ replicas, and liveness/readiness probes cover most of it. Zwei Go-Nodes hinter einem Load Balancer, ein Cluster-Koordinator (Consul oder etcd) mit unabhängigen Health Checks und eine von beiden geteilte Datenbank. Auf Kubernetes (oder dem leichteren k3s): ein Service, ein Deployment mit 2+ Replicas und Liveness-/Readiness-Probes decken das meiste ab.

03 — Trust boundaryVertrauensgrenze

The client never decides securityDer Client entscheidet nie über Sicherheit

The desktop client (Tauri) must never present a free-text server-address field, an SSL on/off toggle, or an authentication-method picker. Any such UI is a leak point. The client asks the server which auth method is in effect and renders the matching login screen. Der Desktop-Client (Tauri) darf nie ein Freitext-Feld für die Serveradresse, einen SSL-Schalter oder eine Auswahl der Authentifizierungsmethode anbieten. Jede solche UI ist ein Leck. Der Client fragt den Server, welche Methode gilt, und rendert die passende Login-Maske.

04 — Enrollment configEnrollment-Konfiguration

A signed trust anchor, not just settingsEin signierter Vertrauensanker, nicht nur Einstellungen

A small, human-inspectable, versioned file carrying server.url, a cert_pin, fallback_urls, the auth method and an Ed25519 signature — but no secrets. Each organization holds its own signing key (decentralized, trust-on-first-use), so the vendor can never produce trusted config for a customer's network. Eine kleine, menschenlesbare, versionierte Datei mit server.url, einem cert_pin, fallback_urls, der Auth-Methode und einer Ed25519-signature — aber ohne Geheimnisse. Jede Organisation hält ihren eigenen Signierschlüssel (dezentral, Trust-on-First-Use), sodass der Anbieter nie vertrauenswürdige Konfiguration für das Netz eines Kunden erzeugen kann.

05 — UpdatesUpdates

Approval is server-side, not a spoofable flagFreigabe serverseitig, kein fälschbares Flag

“Approved” simply means the server will serve that version at all — no client-readable policy flag to spoof. On launch the client compares its stored state-digest to the server's; on a mismatch it pulls the full bundle fresh and signature-verifies it before trusting it. „Freigegeben“ heißt schlicht, dass der Server diese Version überhaupt ausliefert — kein client-lesbares Policy-Flag zum Fälschen. Beim Start vergleicht der Client seinen gespeicherten State-Digest mit dem des Servers; bei Abweichung lädt er das vollständige Bundle neu und prüft die Signatur, bevor er ihm vertraut.

06 — Offline behaviorOffline-Verhalten

Connected, degraded, refusedVerbunden, eingeschränkt, verweigert

Three states. Within an admin-set grace period the client is read-only against cached data, clearly flagged in the UI; past it, the app refuses to open normally. The countdown runs against wall-clock time since last contact, persisted to disk so relaunching can't reset it. Drei Zustände. Innerhalb einer admin-gesetzten Kulanzzeit ist der Client schreibgeschützt auf zwischengespeicherten Daten, klar gekennzeichnet; danach öffnet die App nicht mehr normal. Der Countdown läuft gegen die reale Zeit seit dem letzten Kontakt, auf Platte gespeichert, sodass ein Neustart ihn nicht zurücksetzt.

07 — Failover & idempotent writesFailover & idempotente Writes

Retry the same ID against whoever answersGleiche ID an den wiederholen, der antwortet

Session state lives in the shared DB, so a user reconnecting to the standby node is immediately back to normal. Every write carries a client-generated ID committed atomically with the write; if no response arrives, the client retries the exact same ID and walks fallback_urls — a node that already saw the ID returns the original result instead of reapplying. Der Sitzungszustand liegt in der geteilten DB, sodass ein Nutzer beim Reconnect zum Standby-Node sofort wieder normal arbeitet. Jeder Write trägt eine client-generierte ID, atomar mit dem Write committet; bleibt die Antwort aus, wiederholt der Client exakt dieselbe ID und läuft fallback_urls durch — ein Node, der die ID schon kennt, liefert das ursprüngliche Ergebnis, statt erneut anzuwenden.

08 — Permissions modelRechtemodell

Action-centric ladders, restrict-only overridesAktionszentrierte Leitern, nur einschränkende Overrides

Broad access comes from existing AD/LDAP/SSO groups; fine-grained limits are set in-app. Each action references a named, ordered “ladder” of groups. Per-user overrides can only narrow access, never grant it — so every grant traces to a real group, and any decision reduces to one of four short explanations. Breiter Zugriff kommt aus bestehenden AD-/LDAP-/SSO-Gruppen; feingranulare Grenzen werden in der App gesetzt. Jede Aktion referenziert eine benannte, geordnete „Leiter“ von Gruppen. Per-Nutzer-Overrides können Zugriff nur einschränken, nie gewähren — so lässt sich jede Gewährung auf eine echte Gruppe zurückführen und jede Entscheidung auf eine von vier kurzen Erklärungen reduzieren.

Open itemsOffene Punkte

Parked decisions, tracked so they aren't lost. None of them block the rest of the architecture. Geparkte Entscheidungen, festgehalten, damit sie nicht verloren gehen. Keine davon blockiert den Rest der Architektur.

Working draft — decisions captured to date. This page evolves as the spec does.Arbeitsentwurf — bisher festgehaltene Entscheidungen. Diese Seite wächst mit der Spezifikation.