Systemarchitektur

Aller Verkehr betritt die Plattform über Traefik. Der Reverse Proxy terminiert TLS, erzwingt HTTPS und verteilt die Anfragen anhand des Hostnamens auf die Container dahinter. Kein Anwendungsdienst ist direkt aus dem Internet erreichbar.

Die drei Anwendungen darunter haben klar getrennte Aufgaben: Das Cockpit ist die Oberfläche für Winzer, die Storefronts sind die Shops für die Kundschaft, und Medusa ist die einzige Instanz, die tatsächlich mit der Datenbank spricht. Weder Cockpit noch Storefront haben eine Datenbankverbindung — sie kennen nur HTTP-Endpunkte.

Alle Dienste laufen als Docker-Container auf einem einzelnen Server. Die Ports in der Tabelle sind Container-Ports; nach außen sind nur 80 und 443 offen.

Root-Domain ist raspb.eu. Jeder Dienst bekommt eine eigene Subdomain, jedes Weingut eine Shop-Subdomain nach dem Muster shop-<slug>.raspb.eu — oder, sobald das Weingut umgestellt hat, die eigene Domain.

Storefronts und Cockpit melden sich über Docker-Labels bei Traefik an. Ein neuer Container trägt seine Route also selbst bei — es muss keine zentrale Konfigurationsdatei angefasst und kein Proxy neu geladen werden. Das Zertifikat holt Traefik beim ersten Aufruf über die TLS-Challenge und erneuert es danach automatisch.

Zwei Netzwerke trennen das, was von außen erreichbar sein muss, von dem, was es nicht sein darf. PostgreSQL und Redis liegen ausschließlich im internen Netz und haben keinen veröffentlichten Port.

Traefik ist der einzige Container, der beide Welten berührt: Er hängt im Netz web und ist als einziger von außen ansprechbar.

Drei Wege beschreiben praktisch alles, was in der Plattform passiert.

Alle Weingüter teilen sich eine Datenbank. Getrennt werden sie über den Sales Channel von Medusa — ein Konzept, das ohnehin für Vertriebskanäle vorgesehen ist und hier als Mandantengrenze dient.

Auf der Kundenseite

Jede Storefront kennt genau eine sales_channel_id und einen Publishable API Key, der auf diesen Channel eingeschränkt ist. Die Store API liefert damit ausschließlich Produkte dieses Kanals aus. Selbst wenn jemand die Produkt-ID eines fremden Weinguts errät, kommt mit dem falschen Key nichts zurück.

Auf der Winzerseite

Der Cockpit-Benutzer trägt seine sales_channel_id in den Metadaten. Jeder Lese- und Schreibzugriff über die Admin-Routen wird auf diesen Wert eingeschränkt — Weine, Bestellungen, Beiträge, Lagen, Rebsorten und das Winzer-Profil.

Was pro Mandant konfiguriert wird

• TENANT_BASE_URL — die Medusa-Instanz, für alle gleich
• TENANT_PUBLISHABLE_KEY — Store-API-Key des Mandanten
• TENANT_SALES_CHANNEL_ID — die Mandantengrenze
• TENANT_REGION_ID — Währung, Steuersatz, Lieferländer
• TENANT_SHOP_DOMAIN und TENANT_SHOP_NAME — Domain und Anzeigename
• TENANT_STRIPE_ACCOUNT_ID — das Stripe-Connect-Konto des Weinguts

Der ehrliche Stand — inklusive dem, was noch offen ist.

Heute läuft alles auf einem Server. Das ist eine bewusste Entscheidung: Bei einer einstelligen Zahl von Weingütern kostet verteilte Infrastruktur mehr Aufmerksamkeit, als sie einbringt.

Vertikal — der aktuelle Weg

Mehr RAM und CPU für den Host, dazu PostgreSQL-Tuning. Trägt komfortabel bis in den Bereich von etwa 20 bis 30 Mandanten.

Horizontal — der vorbereitete Weg

• PostgreSQL auf einen eigenen Server oder einen Managed Service
• Redis auf eine eigene Instanz
• Medusa mehrfach hinter einem Load Balancer
• Storefronts beliebig verteilen — sie sind zustandslos und nur über Umgebungsvariablen konfiguriert
• MinIO gegen einen S3-Anbieter tauschen; die Schnittstelle bleibt dieselbe

Portabilität

Ein Serverumzug besteht aus fünf Schritten: Datenbank per pg_dump sichern und einspielen, Images aus der Registry ziehen, .env übernehmen, Compose-Stack starten, DNS umstellen. Es gibt keine Bindung an einen Hoster.