Multi-Tenant Laravel for Marketplaces and Multi-Brand Retail: Architecture Trade-offs

Multi-tenant Laravel covers two genuinely different problems that get discussed as one.

A marketplace has many independent sellers who do not trust each other, wildly uneven usage, self-service onboarding and a single public storefront. A multi-brand retail group has a handful of tenants under one owner, comparable usage, deliberate onboarding and a separate storefront per brand. They share the word tenant and almost nothing else.

Getting the architecture right means being clear which one you are building, because several decisions invert between them.

Tenant Resolution: The Decision Everything Hangs Off

How the application knows which tenant a request belongs to. There are three practical answers and they are not equivalent.

• Domain or subdomain — brand-a.example.com, or fully separate domains. The right answer for multi-brand retail, where each brand needs its own identity, its own SEO surface and its own certificates.
• Path prefix — /sellers/acme/. Simple, cheap, and it keeps everything on one domain, which suits a marketplace where the marketplace brand is the one that matters.
• Authenticated user context — no tenant in the URL at all. Correct for back-office applications, wrong for anything with a public storefront, because the same URL renders differently for different users and caching becomes a hazard.

Resolve the tenant once, in middleware, before anything else runs, and bind it into the container. Every subsequent piece of code should be able to ask who is the current tenant without knowing how that was determined — which is what lets you change the answer later.

Data Isolation

We have covered the three tenancy models — shared schema, schema per tenant, database per tenant — and their economics in the tenancy model comparison. The Laravel-specific mechanics are what matters here.

For shared schema, which is right for most marketplaces:

• Enforce scoping globally, not per query. Laravel's global scopes work, but the stronger control is row-level security in the database — because a global scope can be removed by a developer in a hurry, and a database policy cannot.
• Make the tenantless query loud. Have your base model throw when no tenant is bound, so a job that forgot to set context fails immediately rather than reading everything.
• Watch raw queries and reporting code. Query builder calls that bypass Eloquent bypass your scopes with them. This is where leaks come from.
• Index on tenant_id first in composite indexes, or every query scans more than it should.

For database per tenant, right for multi-brand groups with real separation requirements, the mechanics shift: connection switching in middleware, per-tenant migrations that must be resilient to partial failure across the estate, and a cache and queue prefix per tenant so nothing bleeds. All of it is well-trodden; all of it needs automating before you have real tenant numbers rather than after.

Queues Are Where Multi-Tenancy Breaks

The part most implementations get wrong, and the part that produces the worst incidents.

1. Serialise the tenant into the job, always. A job that resolves the tenant from anything ambient will eventually run in the wrong context, and the failure is silent and cross-tenant.
2. Restore tenant context at the start of every job, and fail hard if it cannot be established.
3. Isolate noisy tenants. One seller importing 200,000 products must not delay every other tenant's order confirmations. Separate queues by workload type at minimum, and per-tenant rate limits where the tenants are untrusted.
4. Make scheduled commands iterate tenants explicitly, with per-tenant failure isolation — one tenant's bad data must not abort the run for everyone.
5. Think about failed jobs. A failed-jobs table without tenant context is unusable at scale, and retrying blind is how you get cross-tenant writes.

Marketplace-Specific Problems

Things a multi-brand group never has to solve:

• Split payments and payouts. An order spanning three sellers is one payment and three settlements, with commission, refunds, chargebacks and tax attributed correctly. This is usually the hardest domain problem in the build and it belongs to finance, not engineering.
• Seller onboarding and verification. Self-service means untrusted input at scale — identity checks, bank verification, fraud screening.
• Quality control. Product data, imagery and pricing arrive from thousands of sources with no shared standard. Whoever owns catalogue quality owns the customer experience.
• Fair scheduling. Every shared resource — queues, search indexing, API rate limits, report generation — needs a fairness policy, or the largest tenant consumes the platform.
• Seller-facing analytics that must be fast, isolated and unable to reveal anything about another seller.

We have built this shape more than once — Scout Arabia's multi-vendor marketplace and PriceGuru both live here, on a different stack but with identical structural problems. The commerce platform changes; the payout reconciliation does not.

Multi-Brand Retail Problems

The inverse set:

• Shared catalogue with per-brand overrides. One product, sold by three brands, at three prices, with three descriptions, and a change to the base product must propagate predictably.
• Consolidated reporting across brands while each brand sees only itself.
• Shared customer identity — or deliberately not. This is a legal question before it is a technical one, and it varies by jurisdiction.
• Per-brand theming that does not become five codebases. The discipline is a shared component library with brand tokens, not forked templates.
• Shared inventory across brands, which is either a major advantage or a source of constant conflict depending on how the business actually operates.

What to Decide Before Writing Code

1. Can a user belong to more than one tenant? Retrofitting this into an authentication model that assumed otherwise is one of the more painful refactors available.
2. Is the tenant identifier public? Once it appears in URLs and APIs, customers build against it and it stops being yours to change.
3. Where does per-tenant configuration live — in the tenant's own data, or a central registry? Both work; mixing them does not.
4. What happens when tenants merge or split? Rare and brutal. Marketplaces acquire each other; brand groups restructure.
5. How does a tenant leave? Full export and complete deletion are contractual obligations in most markets, and they are far harder to add later.

This is the work our Laravel team does before a build starts, and it sits inside our wider Laravel platform practice. For retail groups the multi-brand shape is the common one; for logistics and finance platforms it is usually closer to the marketplace end.

Get the Model Right First

Tenant resolution, isolation and queue context are cheap to decide and expensive to change. We will review yours against the shape you are actually building. Talk to our team; we reply within a business day.