Scaling a Multi-Brand Commerce Platform: One Backend, Many Storefronts

When a single company operates multiple distinct consumer brands, you eventually face an infrastructure dilemma. You can either spin up completely separate e-commerce instances for each brand (which leads to a maintenance nightmare), or you can build a multi-tenant system where one backend powers everything.

Recently, I built a multi-brand commerce platform designed precisely for this. The goal was simple: one central admin dashboard for the factory/operations team to manage products and orders, but entirely separate, customized storefronts for each consumer brand.

Here are some field notes on the architecture and how we solved the brand isolation problem.

The Architecture: Centralized Logic, Distributed Presentation

The core philosophy of the system is: One backend, many frontends.

Instead of duplicating the database and server for every new product line, we use a single API backend. Every storefront is a separate application that talks to this same central API.

1. The Centralized Backend

The brain of the operation is a centralized API application connected to a single relational database. It exposes two distinct API surfaces:

• Public API (Brand-Scoped): Used by the storefronts. Every request here strictly requires a brand identifier. If Brand A requests products, the backend ensures it never leaks Brand B's data.
• Admin API (Protected): Used by the factory and operations team. It allows global management of all brands, products, variants, and order fulfillment.

We heavily rely on strict request/response schema validation, ensuring no malformed data ever touches the database.

2. The Admin Dashboard

For the operations team, we built a responsive Single Page Application (SPA). This dashboard is role-aware. A FACTORY user only sees operational data (like processing and shipping orders), while an ADMIN has full access to create new brands and manage product catalogs.

Order state transitions are strictly validated. An order flows logically: PENDING_PAYMENT → PAID → PROCESSING → SHIPPED → COMPLETED. The dashboard prevents invalid state jumps, forcing the operational workflow to remain consistent.

3. The Independent Storefronts

This is where the multi-brand strategy shines. Each brand gets its own domain and its own custom-designed frontend application.

Consumer storefronts need to be fast and SEO-friendly. We utilize Server-Side Generation (SSG) to ship pure, lightweight HTML for product pages, complete with per-product meta tags, while keeping cart and checkout interactivity strictly isolated.

Taming the Codebase with a Monorepo

Having a dozen different repositories for one platform would slow down development. Instead, we structured the entire platform as a Monorepo.

The structure looks roughly like this:

• backend/ (Central API)
• frontend/admin/ (Operations Dashboard)
• frontend/brand-a/ (Storefront)
• frontend/brand-b/ (Storefront)
• packages/commerce/ (Shared headless commerce logic)
• packages/cta/ (Shared UI components)

The Power of Shared Packages

When you have multiple storefronts, you inevitably end up with duplicated logic—cart state management, API client wrappers, and UI widgets.

By extracting these into shared internal packages, we write the code once. For example, we built an embeddable floating support widget. It's just a self-contained component wired into every brand's layout. If we need to fix a bug in the cart calculation logic, we fix it in the shared package, and all storefronts inherit the fix instantly on their next build.

Strict Brand Isolation

The biggest risk in a multi-tenant architecture is data leakage. We solved this at the database schema and middleware level.

Every relevant table in the database (Products, Orders, Customers) has a brandId foreign key. On the backend, a custom middleware intercepts every public API request, extracts the brand identifier, looks up the internal brandId, and securely injects it into the request context.

From there, every database query is strictly scoped by this identifier. This guarantees that a storefront can only ever interact with its own catalog and its own customers.

Handling Third-Party Integrations & Communications

In the real world, a commerce platform isn't an isolated island; it needs to talk to external services. Handling these in a multi-tenant system introduces unique architectural challenges.

1. Payment Gateways: When a customer checks out, the transaction state must be synced. The central API must map incoming payment callbacks (webhooks) to the correct internal brandId and order, ensuring payment state transitions are secure and completely isolated from other brands.
2. Shipping & Logistics: Integrating aggregators (like Komship) requires pushing order data to external APIs and listening for tracking updates. The backend acts as a central dispatcher: it routes shipping webhooks, translates external AWB (Airway Bill) tracking events, and triggers internal state changes for the specific brand's operational dashboard.
3. Branded SMTP: When an order state changes, the customer expects a notification. However, the system cannot send an email from a generic "Central Company" address. The backend dynamically resolves the brandId, pulls the corresponding SMTP credentials and HTML templates, and dispatches the email. Brand A's customers receive an email from support@brand-a.com, while Brand B's customers get a completely different experience—all orchestrated by the same central background worker.

Wrapping Up

Building a centralized backend with decoupled frontends requires a bit more upfront architectural thinking, but the long-term payoff is massive. When the company decides to launch a new brand tomorrow, we don't need to spin up new servers or databases. We just scaffold a new storefront, point it to the existing API with a new brand identifier, and it's ready to go.