Marketplace architecture: The core components explained

Founders planning a marketplace hear the vocabulary long before they see the picture: Payment splitting, vendor dashboards, escrow, order orchestration, KYC. Each term arrives in a different sales call, and somehow the sum never assembles into a diagram you could draw on a whiteboard.

This article is that diagram. Platform-agnostic, no code, just marketplace architecture: What a two-sided marketplace is actually made of, how money and data move through it, and, because this is what the vocabulary is really hiding, where the complexity and cost concentrate. By the end, “we’d need a custom payout flow” should sound like a specific, sizable object, not fog.

Founders who skip this step tend to scope their build off the wrong analogy: They picture an online store with a few extra fields, then discover eighteen months in that the vendor dashboard alone was a second product. Getting the picture right before you write a line of code, or a line of a request for proposal, is the cheapest hour you’ll spend on the whole project. It’s also the difference between a founder who can push back on a vendor’s estimate and one who has to take it on faith.

What is marketplace architecture?

Marketplace architecture is the set of systems that lets three parties, buyers, sellers, and the platform operator, transact safely in one place: a commerce core (catalog, cart, orders), a vendor layer (onboarding, dashboards, permissions), a transaction engine (split payments, commissions, payouts), discovery (search, matching, curation), and a trust and operations layer (reviews, disputes, moderation).

What separates a marketplace from an online store is not more pages. It’s that almost every component must work per vendor while feeling unified per buyer. A shopper adding three items from three different sellers to one cart should never notice the seams; the seams are exactly what the architecture underneath has to manage, quietly, every time.

The six core components of marketplace architecture

1. The commerce core. Catalog, cart, checkout, orders, the machinery every ecommerce site has. In a marketplace it carries one extra, defining burden: a single buyer action (one cart, one payment) must fan out into per-vendor consequences (multiple orders, shipments, payouts). Get this boundary right and everything downstream inherits it cleanly; get it wrong and every future feature re-implements vendor logic by hand. We’ve covered how the split is designed in practice in our multi-vendor architecture guide.

2. The vendor layer. Everything sellers touch: onboarding and verification (KYC where money is involved), product and inventory management, order handling, earnings visibility. Two facts founders consistently underestimate: this layer is effectively a second product with its own UI, permissions, and support burden, and no platform’s operator admin doubles as a vendor dashboard out of the box. In budgets, the vendor layer is where the surprises live: a “simple” seller dashboard can easily be a third of the entire build.

3. The transaction engine. The heart, and the component that most separates marketplace architecture from store architecture. One payment in; commission computed and recorded; funds split across vendors; payouts scheduled; refunds that claw back correctly across the split. Two rules save years here: commission is order logic (computed and stored at a defined moment), while payouts are money movement (executed from recorded data, typically through a licensed provider like Stripe Connect rather than your own accounts, which keeps you outside payment-regulation perimeters in most jurisdictions).

Refunds are where the transaction engine is tested hardest. A single-seller store reverses one payment; a marketplace has to reverse the commission, the vendor payout (or claw it back if it already went out), and the buyer’s original charge, in the right order, without leaving any party holding money that isn’t theirs. Teams that treat refunds as an afterthought usually rebuild this part twice.

4. Discovery. Search, filtering, categories, and, in mature marketplaces, matching and ranking logic. The infrastructure is a solved, buyable problem, dedicated search engines exist precisely because building one is a poor use of your budget. The logic, who surfaces first, how relevance reflects your market’s real preferences, is often the platform’s actual moat, and the one component where “build” routinely beats “buy” at the logic level even while buying the infrastructure underneath.

5. Trust and safety. Reviews and ratings, dispute resolution, content moderation, fraud controls. Structurally simple, operationally heavy: every trust feature creates an ongoing human workflow (who arbitrates the dispute, who removes the listing). Architect the tooling for those workflows early, support teams inherit whatever you skip. A marketplace that launches without a dispute queue usually builds one in a panic, three weeks after the first buyer and seller disagree publicly.

6. The operations layer. Reporting that speaks both languages (marketplace totals for finance, per-vendor detail for ops), notifications, and the admin tooling the platform team lives in. Unglamorous, and the difference between a platform that scales operationally and one that runs on exported spreadsheets six months after launch. Finance wants one number for the month; a vendor wants their own number, on demand, without emailing support to ask for it.

How the pieces connect: one purchase, traced

The fastest way to see the architecture is to follow one transaction through it, from the buyer’s first search to the vendor’s payout:

BUYER                    PLATFORM                      VENDORS
browse/search ────────► Discovery
one cart, 3 vendors ──► Commerce core
one payment ──────────► Transaction engine
|- order SPLIT ─────────► 3 vendor orders
|- commission computed
|     & recorded per order
`- funds held by licensed
payment provider
Vendor layer ─────────────► each vendor fulfills
delivery ◄──────────────────────────────────────────'
review ───────────────► Trust layer
Transaction engine ────────► payouts released
Operations: reporting: one purchase for the buyer,
three orders + three payouts inside

Every arrow above is a design decision, not a default. The three that shape everything downstream: where the order splits (early, at checkout, not retroactively in reporting), when commission locks (at a defined order moment, stored, auditable), and who holds the money (a licensed provider, in almost all cases, rather than the platform’s own bank account). Get those three arrows wrong early and every component downstream has to route around the mistake for the life of the platform.

Where complexity and cost actually concentrate

Not all six components are equally hard, and knowing the gradient is half of budgeting a marketplace project well. From the platforms we build: the transaction engine and vendor layer carry most of the irreducible complexity, they’re marketplace-specific, hard to rent well, and where estimates most reliably go wrong (the vendor dashboard alone is routinely the most underestimated line item in a proposal).

The commerce core and discovery infrastructure are largely solved problems, frameworks and search services exist so you don’t rebuild them, as we cover in our multi-vendor architecture guide. Trust and operations are cheap to build and expensive to run, their cost is headcount, not code, which is easy to miss in a build budget that only counts engineering hours.

That gradient is exactly why “build vs buy” is best decided per component rather than per platform, a framework we’ve written about in our custom marketplace development guide, and why cost conversations that start with a single number, rather than with your transaction flow, aren’t estimates at all.

The stack question, briefly

“What tech stack should a marketplace use?” is mostly the wrong first question, the architecture above can be implemented on many stacks, from a fully custom build to a framework like Medusa.js. The right first questions are which components you’ll own versus rent, and whether your platform’s constraints will fit your model as it grows (the signals when they stop fitting are recognizable, as we cover in our guide on marketplace platform limitations).

Stack choice then follows from those answers, your team’s skills, and your region’s realities, not from a benchmark chart someone shared in a Slack channel. Two teams with identical requirements can make opposite, equally defensible stack choices once you factor in what they already know how to run in production, and what their region’s payment rails actually support.

Plan your marketplace architecture before you build it

Six components, three defining arrows, one gradient of cost, that’s the whole picture, and it fits on a page. We’ve turned it into the same planning checklist we run at the start of every marketplace build, and you can request a copy of it here.

One more pattern worth naming: teams that get this right rarely start with a blank canvas. They start from an existing commerce foundation and add the marketplace-specific pieces (vendor layer, transaction engine, discovery logic) on top, rather than building all six components from zero. It’s usually faster, and it means the parts that are genuinely solved problems stay solved.

FAQ