Erfolgreich einen Multi-Vendor-Marktplatz mit React entwickeln: 30.000 Codezeilen Erfahrung

Ein einfacher Online-Shop mit Produktliste und Warenkorb ist schnell umgesetzt. Doch sobald drei verschiedene Nutzergruppen – Kunden, Verkäufer und Administratoren – mit individuellen Rechten und Echtzeit-Interaktionen integriert werden müssen, wird aus dem Projekt eine komplexe Herausforderung. Genau diese Erfahrung machte der Full-Stack-Entwickler Faiz Ullah mit Ecommerce, einem Multi-Vendor-Marktplatz, der auf über 30.000 Zeilen React-Code anwuchs. Seine Erkenntnisse zeigen, wie man solche Systeme strukturiert aufbaut – und welche Fehler man unbedingt vermeiden sollte.

Drei separate Anwendungen in einem System

Ein klassischer Einzelhändler benötigt eine einzige Anwendung. Ein Multi-Vendor-Marktplatz hingegen ist eine Kombination aus drei eigenständigen Anwendungen, die zwar dieselbe Datenbank nutzen, aber völlig unterschiedliche Funktionalitäten abdecken:

• Kunden durchsuchen Angebote, tätigen Käufe und kommunizieren direkt mit Verkäufern.
• Verkäufer verwalten ihr eigenes Shopfront-Design, bearbeiten Bestellungen und beantragen Auszahlungen.
• Administratoren überwachen das gesamte System, genehmigen neue Verkäufer, lösen Konflikte und setzen Auszahlungen frei.

Die naheliegende, aber riskante Lösung wäre, alle Rollen in einer einzigen App.js zu vereinen und mit Conditional-Logik wie if (userType === 'admin') zu steuern. Doch schon bald würde der Code unübersichtlich und fehleranfällig werden. Stattdessen entschied sich Ullah für eine getrennte Authentifizierung für jede Nutzergruppe und setzte auf geschützte Routen mit eigenen Guard-Systemen:

<Route element={<ProtectedCustomerRoute />}>
  <Route path="/customer/dashboard" element={<CustomerDashboard />} />
</Route>
<Route element={<ProtectedSellerRoute />}>
  <Route path="/seller/products" element={<SellerProductList />} />
</Route>
<Route element={<ProtectedAdminRoute />}>
  <Route path="/admin/users" element={<AdminUserManagement />} />
</Route>

Jede Route prüft unabhängig die Sitzungsdaten der jeweiligen Gruppe. Selbst wenn ein Angreifer versucht, durch Manipulation der URL Zugriff auf eine andere Rolle zu erlangen, bleibt das System sicher – denn die Sitzungen sind strikt voneinander getrennt.

Echtzeit-Kommunikation ohne eigenen Server

Eine der Kernfunktionen eines Marktplatzes ist die direkte Kommunikation zwischen Käufern und Verkäufern. Traditionell hätte man dafür einen WebSocket-Server einrichten müssen, der kontinuierlich Verbindungen verwaltet. Doch Ullah nutzte stattdessen die Echtzeit-Fähigkeiten von Firestore – eine Entscheidung, die sich als effizient und skalierbar erwies:

import { collection, query, orderBy, onSnapshot } from "firebase/firestore";

const messagesRef = collection(db, "messages");
const q = query(messagesRef, orderBy("timestamp"));

onSnapshot(q, (snapshot) => {
  snapshot.docChanges().forEach((change) => {
    // UI aktualisiert sich automatisch bei neuen Nachrichten
  });
});

Diese einzige Abfrage steuert nicht nur den Nachrichtenaustausch, sondern auch Funktionen wie ungelesene Nachrichten oder die Anzeige von Online-Status – ohne dass zusätzliche Serverinfrastruktur nötig wäre.

Der unsichtbare Knackpunkt: Der Online-Status

Die Anzeige, ob ein Verkäufer gerade aktiv ist, klingt simpel. Doch die Umsetzung birgt Fallstricke: Ein einfacher Schalter wie isOnline: true führt zu falschen Ergebnissen, sobald ein Nutzer sein Gerät schließt, ohne sich abzumelden. Der Verkäufer würde fälschlicherweise weiterhin als online gelten.

Die Lösung liegt in einem Herzschlag-Mechanismus (Heartbeat): Der Client aktualisiert regelmäßig einen lastSeen-Zeitstempel, solange die Browser-Tab aktiv ist. Sobald der Tab geschlossen oder in den Hintergrund wechselt, stoppt der Mechanismus automatisch:

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    stopHeartbeat(); // Herzschlag stoppen
  } else {
    startHeartbeat(); // Herzschlag starten
  }
});

Jeder, der den Profilstatus eines Verkäufers prüft, kann nun anhand des letzten Herzschlags zuverlässig erkennen, ob dieser tatsächlich online ist. Ein manuelles Cron-Job-System oder veraltete Statusangaben gehören damit der Vergangenheit an.

Medieninhalte richtig handhaben: Warum der Datenbank Speicherplatz fehlt

Ein häufiger Fehler in der frühen Entwicklungsphase ist das Speichern von Mediendateien direkt in der Datenbank. Firestore-Dokumente haben Größenlimits, und das Übertragen großer Base64-codierter Bilder bremst die Ladezeiten massiv aus.

Der Ausweg: Alle Uploads werden über Cloudinary geleitet – ein Dienst, der sich auf Bildverarbeitung und Content Delivery spezialisiert hat. Durch den Einsatz von unsigned Upload-Presets bleibt der API-Schlüssel sicher auf Serverseite, während der Client nur die Preset-ID benötigt:

formData.append('upload_preset', cloudinaryConfig.uploadPreset);

const response = await fetch(
  `
  {
    method: 'POST',
    body: formData
  }
);

Cloudinary übernimmt anschließend das Resizing, die Formatkonvertierung und die Bereitstellung über ein globales CDN. Die Datenbank speichert nur noch den generierten URL-Pfad – ein Ansatz, der Skalierbarkeit und Performance deutlich verbessert.

Die größte unsichtbare Hürde: Auszahlungen sicher gestalten

Der technische Aufbau eines Zahlungssystems ist relativ einfach. Doch die sichere Abwicklung von Auszahlungen an Verkäufer erfordert besondere Vorsicht. Ullah implementierte ein separates Modul namens WithdrawalRequestsManager, das den Prozess in kontrollierte Schritte unterteilt:

• Ein Verkäufer stellt einen Auszahlungsantrag.
• Der Antrag wird zunächst in einen „Ausstehend“-Status versetzt.
• Erst nach einer manuellen Prüfung durch einen Administrator wird das Geld freigegeben.

Diese manuelle Prüfung ist kein Zeichen von Ineffizienz, sondern eine kostengünstige Absicherung gegen Betrug. Automatisierte Systeme mögen zwar schneller sein, doch sobald das erste betrügerische Auszahlungsgesuch eintrifft, wird der Wert manueller Kontrollen offensichtlich.

Praxistipps für den Bau eines eigenen Marktplatzes

Basierend auf seinen Erfahrungen gibt Ullah folgende Empfehlungen an Entwickler weiter, die einen Multi-Vendor-Marktplatz planen:

• Trennen Sie die Nutzergruppen von Anfang an. Nachträgliches Hinzufügen von Rollen zu einem bestehenden Authentifizierungssystem führt zu technischem Schuldenberg.
• Nutzen Sie die Echtzeit-Fähigkeiten Ihrer Datenbank, bevor Sie einen eigenen Server aufsetzen. Dienste wie Firestore können viele Real-Time-Anforderungen ohne zusätzliche Infrastruktur abdecken.
• Speichern Sie niemals Binärdaten in der gleichen Struktur wie Ihre Anwendungsdaten. Medieninhalte gehören sofort in spezialisierte Dienste wie Cloudinary oder AWS S3.
• Fügen Sie an allen Stellen, an denen Geld das System verlässt, eine menschliche Prüfung ein. Dies ist die einfachste und effektivste Methode, um Betrug zu verhindern.

Die eingesetzte Technologie im Überblick

Frontend: React, React Router, Material UI (MUI) Datenbank: Firebase Firestore, Firebase Realtime Database (für Statusverwaltung) Authentifizierung: Firebase Authentication Medienmanagement: Cloudinary

Der Bau eines Multi-Vendor-Marktplatzes ist kein Projekt für Einsteiger – doch mit der richtigen Architektur und klaren Trennung der Verantwortlichkeiten lässt sich das Vorhaben strukturiert umsetzen. Wer ähnliche Herausforderungen meistern will, sollte frühzeitig auf Skalierbarkeit und Sicherheit achten. Die hier gesammelten Erfahrungen zeigen: Manchmal sind es die unscheinbaren Details wie der Online-Status oder die Auszahlungslogik, die über den langfristigen Erfolg entscheiden.