One commerce platform, many storefronts

Imagine two shops using the same commerce platform. One sells clothes. The other sells shoes.

Both need products, a cart, checkout and an order dashboard. They can share the software, but the clothing shop must never receive the shoe shop's orders.

I worked on a platform like this with my company and team. Building it helped me think about storefronts as a series of decisions: identify the shop, check access, then keep every action connected to that shop.

1. Give every shop an identity

A tenant is one business or workspace inside a shared application. In a commerce platform, it might be a merchant with one or more stores.

A store's identity connects its address, catalog, settings and orders. Its logo helps customers recognise it; its identity helps the system load the right records.

A shopper opens Store A → the platform identifies Store A → the shopper sees Store A's products.

There are several ways to identify the storefront from its address:

Option A: A path under the platform's address

Each store gets a named section of one website. This is simple to introduce, but the platform name stays visible in the address.

Option B: A store subdomain

Each store gets its own address under the platform's domain. You need routing and certificate setup for those addresses.

Option C: A custom domain

A merchant uses a domain they own. You need to verify ownership and manage domain mapping and certificates.

These are routing choices. A custom domain can point to the same application that serves the other stores; it does not require a separate copy of the application.

2. Check who can use that store

Identifying the store and granting access are separate steps.

A shopper may be allowed to read a public catalog. A merchant changing a price needs permission to manage that store. An operator managing the platform may have broader access.

For example, signing in as a clothing merchant should not let someone change a shoe merchant's stock by selecting a different store in the browser.

The server has to check that permission. Hiding a button or filtering a list on the page only changes what the person sees.

3. Choose how to keep business data separate

Sharing a platform gives you several storage options too. You can share resources, dedicate resources to each business, or use a mixture. AWS's SaaS architecture guidance describes these as pool, silo and bridge models.

Shared storage

Businesses use shared storage, with access restricted to their own records. You have fewer resources to operate, but the data boundary needs consistent enforcement.

Dedicated storage

A business gets its own data store or other dedicated resources. This gives stronger resource separation and adds provisioning and maintenance work.

A mixed approach

Some resources are shared and others are dedicated. You gain flexibility and have more combinations to manage.

The address style does not decide the storage model. A store with a custom domain could still use shared storage. A store on a platform subdomain could have dedicated resources.

4. Keep the shop attached to the whole order

Now follow a shopper through the clothing shop:

1. They open the catalog and choose a shirt.
2. They add it to that shop's cart.
3. Checkout checks the product and stock in that shop.
4. The saved order belongs to that shop.
5. The clothing merchant sees it in their order dashboard.

The store identity needs to survive each step. It also needs to survive retries, background work and any cached responses used along the way.

Take a cache as an example. If the platform saves a product list and later reuses it for the wrong store, the database could be correctly separated while the storefront still shows the wrong products. The cache needs to distinguish the stores too.

This is a design check for a shared platform, rather than a claim that every platform uses the same caching technique.

5. Give shoppers and merchants different workspaces

The storefront helps a customer buy. The merchant console helps a business manage products, stock and orders. A platform console helps the operator manage the service across businesses.

In the platform I worked on, those areas have different responsibilities. Selecting a store in the merchant console also needs to select the context used for its operations.

A merchant with several stores should be able to switch between them deliberately. They should be able to tell which store they are editing before changing stock or a price.

An example to use when reviewing your design

Picture two stores selling an item with the same name. Each has different stock and a different price.

Ask whether a shopper sees the correct version, whether their cart stays with that store, and whether the order reaches the correct merchant. Then check whether a merchant from the other store can read or change that order.

Those questions follow the customer journey and the access boundary together. They are a useful starting point whenever you add a feature to a platform that serves several businesses.