Mandantenfähiges Laravel für Marktplätze und Mehrmarken-Einzelhandel: Architektur-Abwägungen

Mandantenfähiges Laravel deckt zwei wirklich verschiedene Probleme ab, die als eines diskutiert werden.

Ein Marktplatz hat viele unabhängige Händler, die einander nicht vertrauen, extrem ungleichmäßige Nutzung, Onboarding im Self-Service und eine einzige öffentliche Storefront. Eine Einzelhandelsgruppe mit mehreren Marken hat eine Handvoll Mandanten unter einem Eigentümer, vergleichbare Nutzung, bewusstes Onboarding und eine eigene Storefront je Marke. Gemeinsam ist ihnen das Wort Mandant und fast nichts sonst.

Die Architektur richtig zu treffen heißt, sich darüber im Klaren zu sein, welches von beiden Sie bauen — denn mehrere Entscheidungen kehren sich zwischen ihnen um.

Mandantenauflösung: die Entscheidung, an der alles hängt

Wie die Anwendung erfährt, zu welchem Mandanten eine Anfrage gehört. Es gibt drei praktikable Antworten, und sie sind nicht gleichwertig.

• Domain oder Subdomain — brand-a.example.com oder vollständig getrennte Domains. Die richtige Antwort für den Mehrmarken-Einzelhandel, wo jede Marke ihre eigene Identität, ihre eigene SEO-Präsenz und ihre eigenen Zertifikate braucht.
• Pfad-Präfix — /sellers/acme/. Einfach, günstig, und alles bleibt auf einer Domain — was zu einem Marktplatz passt, bei dem die Marke des Marktplatzes zählt.
• Kontext des angemeldeten Nutzers — gar kein Mandant in der URL. Richtig für Backoffice-Anwendungen, falsch für alles mit öffentlicher Storefront, weil dieselbe URL für verschiedene Nutzer unterschiedlich gerendert wird und Caching zur Gefahr wird.

Lösen Sie den Mandanten einmal auf, in einer Middleware, bevor irgendetwas anderes läuft, und binden Sie ihn in den Container. Jeder nachfolgende Code sollte fragen können, wer der aktuelle Mandant ist, ohne zu wissen, wie das ermittelt wurde — genau das erlaubt Ihnen, die Antwort später zu ändern.

Datenisolation

Die drei Mandantenmodelle — Shared Schema, Schema pro Mandant, Datenbank pro Mandant — und ihre Wirtschaftlichkeit haben wir im Vergleich der Mandantenmodelle behandelt. Hier zählt die Laravel-spezifische Mechanik.

Für Shared Schema, das für die meisten Marktplätze richtig ist:

• Erzwingen Sie die Mandantentrennung global, nicht je Abfrage. Laravels Global Scopes funktionieren, doch die stärkere Kontrolle ist Row-Level Security in der Datenbank — denn einen Global Scope kann ein Entwickler in Eile entfernen, eine Datenbank-Policy nicht.
• Machen Sie die Abfrage ohne Mandanten laut. Lassen Sie Ihr Basismodell eine Exception werfen, wenn kein Mandant gebunden ist — dann scheitert ein Job, der den Kontext vergessen hat, sofort, statt alles zu lesen.
• Achten Sie auf rohe Abfragen und Reporting-Code. Aufrufe des Query Builders, die Eloquent umgehen, umgehen damit auch Ihre Scopes. Von dort kommen die Datenlecks.
• Indizieren Sie in zusammengesetzten Indizes zuerst auf tenant_id, sonst scannt jede Abfrage mehr als nötig.

Bei Datenbank pro Mandant — richtig für Mehrmarken-Gruppen mit echten Trennungsanforderungen — verschiebt sich die Mechanik: Wechsel der Verbindung in einer Middleware, Migrationen pro Mandant, die Teilausfälle über den gesamten Bestand hinweg verkraften müssen, und je ein Cache- und Queue-Präfix pro Mandant, damit nichts überläuft. All das ist gut ausgetreten; all das muss automatisiert sein, bevor Sie echte Mandantenzahlen haben, nicht danach.

An den Queues zerbricht die Mandantenfähigkeit

Der Teil, den die meisten Implementierungen falsch machen — und der die schlimmsten Vorfälle produziert.

1. Serialisieren Sie den Mandanten immer in den Job. Ein Job, der den Mandanten aus irgendetwas Umgebendem auflöst, läuft irgendwann im falschen Kontext — und der Fehler ist still und mandantenübergreifend.
2. Stellen Sie den Mandantenkontext zu Beginn jedes Jobs wieder her und brechen Sie hart ab, wenn er sich nicht herstellen lässt.
3. Isolieren Sie laute Mandanten. Ein Händler, der 200.000 Produkte importiert, darf nicht die Bestellbestätigungen aller anderen Mandanten verzögern. Mindestens getrennte Queues nach Art der Last — und Rate Limits pro Mandant, wo die Mandanten nicht vertrauenswürdig sind.
4. Lassen Sie geplante Befehle die Mandanten explizit durchlaufen, mit Fehlerisolation pro Mandant — die fehlerhaften Daten eines Mandanten dürfen den Lauf nicht für alle abbrechen.
5. Denken Sie an fehlgeschlagene Jobs. Eine Tabelle fehlgeschlagener Jobs ohne Mandantenkontext ist in der Breite unbrauchbar, und blindes Wiederholen ist der Weg zu mandantenübergreifenden Schreibvorgängen.

Probleme, die nur Marktplätze haben

Dinge, die eine Mehrmarken-Gruppe nie lösen muss:

• Zahlungsaufteilung und Payouts. Eine Bestellung über drei Händler ist eine Zahlung und drei Abrechnungen, mit korrekt zugeordneter Provision, Erstattungen, Chargebacks und Steuer. Das ist meist das schwierigste fachliche Problem im Projekt, und es gehört der Finanzabteilung, nicht der Technik.
• Onboarding und Prüfung der Händler. Self-Service bedeutet nicht vertrauenswürdige Eingaben in großer Zahl — Identitätsprüfung, Bankverifizierung, Betrugsprüfung.
• Qualitätskontrolle. Produktdaten, Bilder und Preise kommen aus Tausenden Quellen ohne gemeinsamen Standard. Wer die Katalogqualität verantwortet, verantwortet das Kundenerlebnis.
• Faire Verteilung. Jede gemeinsam genutzte Ressource — Queues, Suchindizierung, API-Rate-Limits, Reporterstellung — braucht eine Fairness-Regel, sonst verbraucht der größte Mandant die Plattform.
• Analytics für Händler, die schnell und isoliert sein müssen und nichts über einen anderen Händler preisgeben dürfen.

Diese Form haben wir mehr als einmal gebaut — der Multi-Vendor-Marktplatz von Scout Arabia und PriceGuru gehören beide hierher, auf einem anderen Stack, aber mit identischen strukturellen Problemen. Die Commerce-Plattform ändert sich; der Abgleich der Payouts nicht.

Probleme im Mehrmarken-Einzelhandel

Die umgekehrte Liste:

• Gemeinsamer Katalog mit Überschreibungen je Marke. Ein Produkt, verkauft von drei Marken, zu drei Preisen, mit drei Beschreibungen — und eine Änderung am Basisprodukt muss sich vorhersehbar fortpflanzen.
• Konsolidiertes Reporting über alle Marken hinweg, während jede Marke nur sich selbst sieht.
• Gemeinsame Kundenidentität — oder bewusst keine. Das ist zuerst eine rechtliche Frage und erst dann eine technische, und sie fällt je nach Rechtsraum anders aus.
• Theming je Marke, das nicht zu fünf Codebasen wird. Die Disziplin heißt gemeinsame Komponentenbibliothek mit Marken-Tokens, nicht abgezweigte Templates.
• Gemeinsamer Bestand über alle Marken hinweg — je nachdem, wie das Unternehmen tatsächlich arbeitet, entweder ein großer Vorteil oder eine Quelle ständiger Konflikte.

Was Sie entscheiden sollten, bevor Sie Code schreiben

1. Kann ein Nutzer zu mehr als einem Mandanten gehören? Das nachträglich in ein Auth-Modell einzubauen, das vom Gegenteil ausging, gehört zu den schmerzhafteren Refactorings überhaupt.
2. Ist die Mandanten-ID öffentlich? Sobald sie in URLs und APIs auftaucht, bauen Kunden dagegen, und Sie können sie nicht mehr ändern.
3. Wo liegt die Konfiguration pro Mandant — in den Daten des Mandanten oder in einer zentralen Registry? Beides funktioniert; eine Mischung nicht.
4. Was passiert, wenn Mandanten zusammengeführt oder aufgeteilt werden? Selten und brutal. Marktplätze übernehmen einander; Markengruppen strukturieren sich um.
5. Wie verlässt ein Mandant die Plattform? Vollständiger Export und vollständige Löschung sind in den meisten Märkten vertragliche Pflichten — und deutlich schwerer nachzurüsten.

Das ist die Arbeit, die unser Laravel-Team leistet, bevor ein Projekt beginnt, und sie gehört zu unserem breiter aufgestellten Bereich Laravel-Plattformen. Für Einzelhandelsgruppen ist die Mehrmarken-Form die übliche; für Plattformen in Logistik und Finanzen liegt sie meist näher am Marktplatz.

Zuerst das Modell richtig wählen

Mandantenauflösung, Isolation und Queue-Kontext sind billig zu entscheiden und teuer zu ändern. Wir prüfen Ihre Entscheidungen gegen die Form, die Sie tatsächlich bauen. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.