One Order, Many Sellers — Split in the Database
A multi-vendor grocery marketplace where shoppers buy from several sellers in one basket, each seller fulfils only their own share, and the order's status is derived by the database rather than reconciled in the browser.
Industry
E-Commerce
Solution
Multi-Vendor Marketplace
Type
Reference Build
Scope
4 Roles · 11 Tables
A Reference Build, Not a Storefront
This one is ours. There is no client behind it — we built it to work out how a multi-vendor marketplace should actually be put together, because the hard part of a marketplace is not the shop front.
The hard part is what happens after checkout, when one payment has to become several independent fulfilment jobs and still behave like a single order to the person who placed it. The checkout flow here runs end to end with a simulated payment step; no gateway is wired, and no banking API is integrated.
The Problems It Sets Out to Solve
These are engineering problems, not a client's pain points — and each one is the sort that only bites in production, which is exactly why it is worth solving in a reference build first.
One basket, several independent sellers, one payment
Order status drifting out of sync across items, sub-orders and the parent
No backend to trust — anything enforced in React is enforced nowhere
Stock going negative when two shoppers buy the last unit at once
Sellers and admins finding out about a new order by refreshing
The Database Does the Thinking
With a backend-as-a-service and no custom server, every rule that matters has to live in Postgres. That constraint turned out to make the design better, not worse.
Per-Seller Order Splitting
Every order is split into per-seller sub-orders at checkout, with the seller stamped onto each line item — so a seller's dashboard shows their slice of the order and nothing else.
Status Derived, Not Assigned
A trigger propagates status upward — item to sub-order to parent — computing the parent as the furthest-behind active item, and handling the all-cancelled and all-delivered cases. The client never computes it, so it cannot race.
Defence in Depth
Row-level security on every table backed by privileged role-check helpers, with route guards in the client as convenience rather than as the control. The database has the last word.
Stock That Cannot Go Negative
Inventory is decremented inside a database function clamped at zero, so a concurrent checkout can fail to reserve stock but can never drive it below it.
What the Platform Does
Storefront
A landing page with featured products and categories, and cart, wishlist and notifications always one click away.
Product Catalogue
Browse, search, filter and sort across every seller's listings, with ratings, per-unit pricing and discount badges.
Product Detail
A single product view with add-to-cart, wishlist, and the reviews other buyers left.
Seller Storefronts
A per-seller page showing only that seller's products — the shop within the marketplace.
Cart & Wishlist
A persistent cart and wishlist with a live subtotal, delivery charge, tax and a free-delivery threshold.
Checkout
Delivery address, coupon codes and a simulated card payment. The flow is complete; the payment is not real, and the page does not pretend otherwise.
Order Splitting
One customer order becomes one sub-order per seller, each independently fulfilled, with the parent status derived from its children.
Order Tracking
Status tracking per order, computed by the database rather than assembled by the client.
Invoices
A printable invoice per order, generated from the order itself.
Seller Workspace
Product and inventory management, incoming orders, low-stock alerts, revenue and rating — all behind an approval gate.
Commissions & Payouts
Per-seller commission rates, a payouts ledger, stored bank details, and a payout flag on each settled sub-order.
Admin Console
Users, products, categories, orders, coupons, reviews, payments, refunds and returns, with analytics over the lot.
Realtime Notifications
Sellers and admins are pushed new-order and payment events over a realtime subscription rather than polling for them.
Store Settings
A single row controlling open/closed state, delivery charge, minimum order value and the delivery areas served.
No Custom Server, All the Rules in Postgres
Frontend
Backend Logic
Data & Auth
Realtime & UX
Schema-First, Trigger-Driven
- 1
Schema & Security First
Eleven tables, four roles, and row-level security written alongside the schema — not bolted on once the interface worked.
- 2
Storefront & Cart
Catalogue, search, product detail, cart and wishlist over a context-driven client with no state library.
- 3
Order-Splitting Engine
The sub-order model and the trigger that keeps item, sub-order and parent statuses consistent under any update order.
- 4
Seller Workspace
Approval-gated product management, inventory, fulfilment of a seller's slice of each order, and low-stock alerts.
- 5
Admin & Payouts
Platform oversight of users, products, orders and categories, plus the commission and payout ledger with charted analytics.
- 6
Realtime Layer
Postgres change subscriptions surfaced as a live notification bell, filtered per user and per admin.
What Was Built
4
User Roles
11
Database Tables
14
Page Modules
3
Order-Hierarchy Levels
One customer order splits into per-seller sub-orders automatically, and each seller only ever sees their own slice.
Order status is computed by a database trigger from the items beneath it, so it cannot drift and cannot race the client.
Row-level security on every table means a crafted request cannot read another buyer's orders or approve its own seller account.
No client, no production traffic, and a simulated payment step — this is a reference build, and the page says so.
Frequently Asked Questions
Yes — that is exactly what this build models. Every order is split into per-seller sub-orders at checkout, with the seller stamped onto each line item, so each seller fulfils only their own share while the buyer still sees one order. A seller's dashboard shows their slice of the order and nothing else.
Services Behind This Build
Explore Other Case Studies
Building a marketplace or multi-vendor store?
We design the order model, the security model and the payout model before the first screen — because that is what decides whether it scales.
Talk to a Delivery Expert