How to architect a multi-vendor marketplace with React in 30K lines

Building a multi-vendor marketplace isn’t like launching a simple online store. Tutorials often teach you how to list products and handle a cart, but they skip the hard part: giving customers, sellers, and admins their own secure spaces inside one application while letting them interact in real time without mixing up data.

That’s the challenge Faiz Ullah, full-stack developer and founder of DG Technology, set out to solve with Ecommerce, a React-based platform that now spans over 30,000 lines of code. Along the way, he learned lessons that can help anyone building marketplaces with multiple user roles and live interactions.

Three apps, one codebase, zero conflicts

A single-vendor store is essentially one application focused on buyers and products. A multi-vendor marketplace, by contrast, is three applications sharing the same backend infrastructure:

• Customers who browse inventory, place orders, and chat with sellers
• Sellers who manage their own storefronts, process orders, and request payouts
• Admins who moderate the platform, review seller applications, and release payments

Trying to manage all three roles through a single App.js file with scattered if (role === 'admin') checks quickly becomes messy. Instead, Ullah separated the workflows from day one by building three independent authentication systems. Each user type has its own protected route guard that validates session state independently:

<Route element={<ProtectedCustomerRoute />}>
  <Route path="/store" element={<StoreLayout />} />
</Route>

<Route element={<ProtectedSellerRoute />}>
  <Route path="/dashboard" element={<SellerDashboard />} />
</Route>

<Route element={<ProtectedAdminRoute />}>
  <Route path="/control-panel" element={<AdminPanel />} />
</Route>

This setup ensures a seller’s session can’t inadvertently leak into the admin interface, even if someone tries to manipulate the URL. Each guard checks its own session token, preventing role collisions and simplifying permission logic.

Real-time chat without spinning up a server

Live messaging between buyers and sellers was a core requirement, but Ullah wanted to avoid the complexity of managing a custom WebSocket server. Instead, he leveraged Firestore’s real-time listeners to handle in-app communication efficiently:

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

onSnapshot(
  query(messagesRef, orderBy('timestamp')),
  (snapshot) => {
    // Update UI instantly as new messages arrive
    setMessages(snapshot.docs.map(doc => doc.data()));
  }
);

This single pattern powers instant message delivery, unread-message indicators, and presence updates without requiring additional backend services. For a platform of this scale, this approach eliminated the need for a dedicated real-time service while keeping latency low.

Presence tracking that doesn’t lie

Showing whether a seller is "online" seems straightforward—until you consider edge cases like closing a laptop without logging out. A simple isOnline: true flag can leave users stuck in an "online" state indefinitely.

Ullah solved this with a heartbeat pattern that writes a lastSeen timestamp every few seconds while the browser tab is active. When the tab loses focus or closes, the heartbeat stops automatically:

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

Any visitor viewing a seller’s profile simply checks whether the most recent heartbeat is recent enough to be considered "live." This eliminates stale "online" ghosts and removes the need for server-side cron jobs.

Why media shouldn’t live in your database

Early versions of the platform stored image data directly in Firestore documents. This approach quickly hit limits—Firestore enforces document size constraints, and serving large base64 blobs slowed down page loads.

The solution was to route all uploads through Cloudinary using unsigned upload presets. This configuration keeps the API secret out of client-side code while enabling secure uploads:

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

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

Cloudinary then handles format conversion, automatic resizing, and CDN delivery. The database only stores the resulting image URL, improving performance and scalability.

The payout step most developers overlook

Letting sellers earn money is the easy part. Letting them safely withdraw those earnings is where real challenges begin. Ullah built a dedicated WithdrawalRequestsManager to enforce a manual checkpoint:

• Sellers submit withdrawal requests
• Requests enter a pending queue and funds remain locked
• An admin reviews each request before approving payouts

This human-in-the-loop process acts as a simple but effective fraud prevention mechanism. Automating payouts might sound efficient, but Ullah learned the hard way that manual review at the money boundary is the cheapest insurance against fraudulent activity.

Four guiding principles for your first marketplace

If you’re planning to launch a multi-vendor platform, these lessons from 30,000 lines of React code can save you months of refactoring:

• Isolate user roles from the start. Don’t try to retrofit role separation into a single authentication system later—it creates technical debt that compounds over time.

• Exhaust your database’s real-time features first. Firestore’s built-in listeners can replace entire real-time services if you design around them early.

• Offload binary media immediately. Never store images or videos in your primary database. Use dedicated media infrastructure from day one.

• Add a human checkpoint where money leaves the system. Automating withdrawals is tempting, but a manual review step at the payment boundary is a lightweight way to reduce risk.

The stack that powered this journey combined React with React Router for UI routing, Material UI for consistent design, and Firebase for database and authentication needs. Real-time presence relied on Firestore, while media handling was delegated to Cloudinary.

For developers embarking on similar projects, Ullah’s experience underscores a key insight: complexity in multi-user platforms isn’t just about features—it’s about managing boundaries between roles, data, and money flows without letting them collide.