Building a B2B marketplace is one of the most architecturally demanding software projects a founding team can take on. The decisions you make in the first few weeks of design — about tenancy, catalogue structure, order routing, and API contracts — will either compound in your favour or quietly accumulate into the kind of technical debt that forces a complete rebuild right when your growth is accelerating.
This guide walks through the structural decisions that matter most in B2B marketplace architecture: what they are, what the trade-offs look like, and how to make them in the right sequence so you are not rewriting your data model under production load eighteen months from now.
What Is Multi-Tenant Architecture? Plain-English Guide
Why B2B Marketplace Platforms Break at the Seams
Most marketplace rebuilds do not happen because the team chose the wrong framework or the wrong cloud provider. They happen because the original data model was designed to serve one supplier and one type of buyer — then the business scaled, and every new requirement had to be forced into a structure that was never meant to hold it.
The Most Common Trigger for a Marketplace Rebuild
The pattern we see most often: the platform launches with a flat product catalogue, a single access role for suppliers, and a buyer-facing storefront that was essentially bolted on top of a CMS. It works at ten suppliers. At fifty, catalogue conflicts start appearing. At two hundred, the permissions model is a tangle of conditional logic maintained by whoever last touched it. At five hundred, a new enterprise buyer asks for a custom price list and the team realises that implementing it would require touching the core order table.
That is the moment a rebuild gets scoped. It almost always costs more than doing it right the first time — in direct engineering cost, in velocity lost during the transition, and in the features that do not ship while the team is focused on undoing earlier decisions.
How Growth Exposes Weak Foundations
B2B marketplaces have a specific growth profile that B2C platforms do not. Supplier catalogues are large, heterogeneous, and frequently updated. Buyers have complex pricing relationships — contract pricing, volume tiers, buyer-group discounts. Orders span multiple suppliers. Invoicing and fulfilment are separate concerns. None of this is unusual; all of it is predictable. Architectures that fail tend to treat these concerns as edge cases rather than first-class domains.
What Is Clean Architecture in Software? Founder's Guide
The Cost of Deferring Architecture Decisions
Deferring a structural decision does not make it go away. It transfers the cost to a future version of your team that has less context, more production data to migrate, and more users who will be affected by downtime. Architecture decisions should be made explicitly and documented — not discovered retrospectively when something breaks.
Core Architectural Layers Every B2B Marketplace Needs
A B2B marketplace is not a single system. It is a composition of distinct domains, each with its own data ownership, scaling profile, and integration surface. Getting these layers right early means each one can evolve independently without breaking the others.
Identity and Role-Based Access Control
Identity in a B2B marketplace is more complex than in most SaaS applications. You have at minimum four actor types: platform administrators, supplier account managers, supplier catalogue editors, and buyer procurement staff. Many platforms add further granularity — buyer group administrators, finance contacts, fulfilment managers.
Role-based access control (RBAC) needs to be a first-class concern from day one, not a permission flag attached to a user record. The role model should be designed to support cross-tenant operations — a supplier representative who manages multiple supplier accounts, for example, or a buyer administrator who manages multiple buyer locations — without requiring bespoke code for each combination.
Supplier and Buyer Tenant Isolation
In a B2B marketplace, tenancy applies in two directions simultaneously. Suppliers are tenants: their product data, pricing, order history, and account settings must be isolated from one another. Buyers are also tenants: their pricing agreements, order history, and account structure must not be visible across buyer organisations.
This dual-tenancy requirement is what makes B2B marketplace data architecture more complex than a standard SaaS application. The isolation model you choose determines how you structure your database, how you implement your query layer, and how you enforce security at every API boundary.
Catalogue Architecture and SKU Management
The catalogue is the structural heart of any marketplace. In a B2B context, it has to handle attribute diversity across suppliers — one supplier might have ten attributes per product, another might have sixty. It has to support product variants, unit-of-measure differences, and supplier-specific identifiers that need to be normalised into a consistent buyer-facing representation.
A flat product table, however well-indexed, cannot absorb this gracefully at scale. The catalogue domain needs its own schema design, with clear separation between the canonical product representation and the supplier-specific feed data that populates it.
Order Routing and Fulfilment Logic
A single buyer order in a B2B marketplace may include line items from three different suppliers. Each supplier needs to receive only the line items relevant to them. Each supplier may have a different fulfilment lead time. The buyer needs a unified order status that aggregates across all supplier fulfilments. Invoicing may need to be split — one invoice per supplier — or aggregated at the platform level, depending on the commercial model.
All of this is predictable and manageable if it is designed upfront. It becomes very expensive if it is added incrementally to an order model that assumed single-supplier fulfilment.
Integration and API Layer
B2B marketplaces do not operate in isolation. They connect to supplier ERP systems, third-party logistics providers, payment gateways, and external product information management tools. An API-first design — where every domain exposes a well-defined interface before any consumer is built — is not an aspirational best practice; it is the only design that remains maintainable as the integration surface expands.
Multi-Tenancy: The Decision That Defines Everything Else
Of all the architectural decisions in a B2B marketplace, the tenancy model has the highest downstream consequence. It affects database design, query performance, security, compliance scope, and the cost of onboarding new suppliers or buyers at scale.
What Is Multi-Tenant Architecture? Plain-English Guide
Shared Schema vs Separate Schema vs Separate Database
There are three primary tenancy models, each with a different trade-off profile:
Shared schema (row-level tenancy): All tenants share the same tables, distinguished by a tenant_id column. This is the simplest to implement and the most cost-efficient at low tenant counts. The risk is that a missing WHERE tenant_id = ? clause in any query becomes a data leak. At scale, a single noisy tenant can degrade performance for all others.
Separate schema (schema-per-tenant): Each tenant gets their own schema within the same database instance. This provides stronger logical isolation and makes tenant-specific migrations possible without affecting others. The operational overhead increases with tenant count — migrations must be run across every schema.
Separate database (database-per-tenant): Maximum isolation. Each tenant's data lives in a physically separate database. This is appropriate when tenants have enterprise-grade compliance requirements or when contractual data residency obligations exist. The infrastructure and operational cost is highest.
When to Choose Each Model
For most B2B marketplaces launching with fewer than 500 tenants and no explicit data residency requirement, a separate schema model offers a reasonable balance. It provides genuine logical isolation without the infrastructure overhead of per-tenant databases, and it makes it possible to migrate individual tenants to database isolation later without a full re-architecture.
Shared schema can work when the tenant population is very large (thousands of small buyers), isolation requirements are lower, and query performance can be protected by careful indexing and row-level security policies at the database layer.
Tenant Isolation and Data Security Implications
Whatever model you choose, isolation must be enforced at the application layer, not just the database layer. A supplier should never be able to retrieve another supplier's pricing, catalogue, or order data through any API endpoint — even an authenticated one. This requires explicit tenant-scoping in every service method, not just at the API gateway. OWASP's API Security Top Ten identifies broken object-level authorisation as the leading API vulnerability [Source: OWASP] — and in a marketplace, this is exactly the category of error that occurs when tenancy is an afterthought.
Catalogue Architecture at Scale: Managing Thousands of SKUs Without Chaos
The catalogue is where B2B marketplace architectures most visibly diverge from B2C approaches. A B2C catalogue is relatively homogeneous — one product, one set of attributes, one price. A B2B catalogue is a negotiation between supplier-native data structures and the normalised representation your buyers need to search, compare, and purchase efficiently.
Flat vs Hierarchical Catalogue Models
A flat catalogue model — one table, one row per product, fixed columns for attributes — works adequately for small, homogeneous catalogues. It breaks down when suppliers have divergent attribute schemas, when product hierarchies span multiple levels, or when the same physical product appears under different SKUs from different suppliers and needs to be deduplicated for the buyer.
A hierarchical model, where products belong to categories that carry their own attribute schemas, allows each product to carry only the attributes relevant to its category. This requires more upfront schema design but eliminates the sprawl of nullable columns that accumulates in a flat model at scale.
Supplier-Specific Pricing and Tiered Discounts
Pricing in a B2B marketplace is not a property of the product. It is a property of the relationship between a specific supplier and a specific buyer, potentially modified by volume, contract terms, or buyer group membership. Embedding pricing logic in the catalogue table — even as a derived column — couples two domains that have different rates of change and different ownership.
The pricing engine should be a separate service or module that accepts a product identifier, a buyer identifier, a quantity, and a context (contract tier, promotional window), and returns a resolved price. This keeps the catalogue clean and makes pricing rules auditable and testable independently.
Attribute Normalisation Across Suppliers
When supplier A calls a product attribute "colour" and supplier B calls it "finish" and supplier C uses a numeric code, the buyer-facing catalogue needs to present a consistent vocabulary. Attribute normalisation — mapping supplier-native attribute names and values to a canonical taxonomy — should be an explicit ETL step in the supplier onboarding pipeline, not a responsibility pushed to the catalogue storage layer.
In the FieldFolio B2B wholesale marketplace, built for 40,000+ retailers across Australia and New Zealand, supplier catalogue sync was designed around exactly this separation: supplier feeds are ingested, normalised, and deduplicated in a pipeline stage before they populate the canonical catalogue that retailers browse. This prevents data conflicts from accumulating and makes it possible to re-process a supplier's feed when their data format changes without touching the buyer-facing data layer.
Order Management and Routing in a Multi-Vendor Context
Order management in a B2B marketplace is a domain that regularly gets underspecified at the design stage, because the complexity is not obvious until you start mapping real buyer journeys against real supplier fulfilment workflows.
Single-Order, Multi-Supplier Fulfilment
When a buyer places a single order that contains products from three suppliers, the platform must split that order into three supplier-specific sub-orders, route each to the correct supplier, and track the status of each independently. The buyer must never see this complexity — from their perspective, they placed one order and they expect a coherent status view.
This requires an order model that distinguishes between the buyer-facing order record and the supplier-facing fulfilment record. These are different entities with different state machines. Conflating them into a single order table is the most common source of order management bugs in marketplaces that grew beyond their initial design.
Split Invoicing and Payment Handling
Payment in a multi-supplier context has regulatory and commercial dimensions. Depending on the platform's commercial model — marketplace facilitator, agency, or direct supplier invoicing — the rules around tax, payment splitting, and remittance vary significantly. The payment architecture must reflect the commercial model clearly, and that commercial model must be decided before the payment integration is built, not after.
Status Aggregation and Buyer-Facing Transparency
A buyer who has placed a multi-supplier order needs to know, from a single view, that two of their three supplier fulfilments have shipped and one is awaiting stock confirmation. This requires a status aggregation layer that polls or subscribes to supplier-level status events and resolves them into a buyer-facing order status. Webhooks are the most practical pattern for receiving supplier status updates in real time [INTERNAL LINK: What Is a Webhook? Plain-English Guide for Founders].
API Design and Integration Patterns That Prevent Lock-In
A B2B marketplace without a well-designed API layer is a closed system. And a closed system, in a B2B context, will eventually lose to one that can connect to its buyers' procurement tools, its suppliers' ERP systems, and its logistics partners' tracking platforms.
API-First vs API-Last Design
API-first means that the interface contract for a domain is defined before any consumer — whether internal or external — is built against it. The catalogue service defines its API before the supplier portal or the buyer storefront is built. The order service defines its API before the fulfilment integration is written. This discipline means that consumers are never accidentally coupled to implementation details.
API-last — where APIs are added to expose functionality that was originally built for internal use only — produces interfaces that reflect internal data structures rather than domain contracts. These are harder to version, harder to secure, and harder to extend without breaking existing consumers.
Popular frameworks used for marketplace API layers include Node.js/Express for REST services and GraphQL for flexible buyer-facing query interfaces. [Source: Statista developer survey on most-used frameworks]
Webhook Patterns for Real-Time Supplier Events
Supplier events — stock updates, price changes, fulfilment status changes — need to propagate to the marketplace in near real time. Polling supplier systems at regular intervals is fragile, does not scale, and creates lag. A webhook-first integration pattern, where suppliers push events to the marketplace's event endpoint, is more resilient and easier to audit.
The marketplace's event endpoint should be idempotent — processing the same event twice should not produce duplicate effects. This is a design requirement, not an implementation detail. [INTERNAL LINK: What Is a Webhook? Plain-English Guide for Founders]
ERP and 3PL Integration Considerations
Larger B2B buyers commonly manage procurement through ERP systems such as SAP or Microsoft Dynamics. A marketplace that cannot accept purchase orders from an ERP or send fulfilment confirmations back to one will be excluded from enterprise procurement workflows. Planning for EDI or API-based ERP integration at the architecture stage — even if it is not built in version one — prevents structural decisions that would block it later.
The Architecture Decisions You Must Document Before You Build
Architecture decision records (ADRs) are short documents that capture a single architectural decision: the context, the options considered, the decision made, and the consequences. They are not bureaucratic overhead. They are the artifact that allows a future CTO, a new engineering hire, or an acquirer's technical due-diligence team to understand why the system is the way it is. Software Product Handoff to a New CTO: Full Guide
For a B2B marketplace specifically, the following five decisions must be documented before the first line of production code is written:
Tenancy Model and Data Ownership
Which tenancy model will you use — shared schema, separate schema, or separate database? Who owns which data? What are the rules for cross-tenant data access? Document this decision with the specific trade-offs considered, not just the outcome.
Catalogue Ownership: Marketplace vs Supplier
Who is the authoritative source of truth for a product record — the marketplace or the supplier? What happens when a supplier updates their feed and the change conflicts with a manual correction made by a marketplace administrator? This conflict resolution rule must be explicit.
Pricing Engine Placement
Is pricing logic a property of the catalogue, a separate service, or embedded in the order service? The answer determines how many places you need to change when a pricing rule is updated. A pricing engine that lives in three places simultaneously is a maintenance problem waiting to happen.
Event Sourcing and Audit Trail
Do you need a full audit trail of every state change in the order and catalogue domains? If your buyers are procurement-sensitive — healthcare, government, financial services — the answer is almost certainly yes. Event sourcing, where every state change is recorded as an immutable event rather than a mutable row update, is the appropriate pattern. It adds complexity; it also makes compliance and debugging substantially easier.
How Decyb Technology LLP Architects B2B Marketplaces
The architectural framework described in this article is not theoretical. It reflects the decisions our team works through on every marketplace engagement — and the mistakes we have seen most often when we are brought in to stabilise or rebuild a platform that was not designed this way from the start.
What Our Architecture Process Looks Like in Practice
Every B2B marketplace engagement at Decyb begins with an architecture decision phase before any development work is scoped or priced. We map the tenancy model, the catalogue ownership rules, the pricing engine placement, and the order management state machine in documented ADRs. These become part of the project deliverables — not internal documents that disappear when the engagement ends.
This approach directly addresses one of the most common pain points we hear from founders who have been through a previous agency relationship: the product was built, the agency moved on, and nobody can explain why the system works the way it does. Our architecture documents are written to be handed to a future CTO, an investor's technical reviewer, or an acquirer's due-diligence team with confidence.
FieldFolio: A Real B2B Marketplace at Scale
FieldFolio is a B2B wholesale marketplace that our team designed and shipped for 40,000+ retailers across Australia and New Zealand. The architecture covered multi-tenant supplier and retailer isolation, a normalised catalogue sync pipeline handling heterogeneous supplier feeds, a split-fulfilment order management system, and a role-based access model supporting supplier account managers, retailer buyers, and platform administrators simultaneously.
The architecture decision documents produced during the FieldFolio engagement covered the tenancy model selection, the catalogue ownership rules, the pricing engine placement as a separate service, and the webhook-based event integration with supplier systems. These documents were delivered as client assets alongside the codebase.
Our delivery track record spans 12+ years of international client engagements with consistent ★ 5.0 ratings — not because we over-promise, but because we scope carefully, document everything, and own delivery from architecture to launch.
Working With Us
If you are in the early stages of designing a B2B marketplace — or if you have an existing platform that is showing the early signs of architectural strain — the most useful first step is a conversation about where the risks are and what the options look like.
We offer a free 24-hour custom technology strategy call with a senior partner. No cost, no obligation. You will leave with a clear view of the architectural decisions you need to make and an honest assessment of whether your current approach is likely to hold at scale.
Book your free strategy call — get a plan in 24 hours
Frequently Asked Questions
What is the biggest architectural mistake in B2B marketplace development?
The most common and most expensive mistake is building the platform as a single-tenant application and treating multi-tenancy as something to add later. Once production data exists in a single-tenant model — especially at meaningful supplier or buyer volumes — migrating to a proper multi-tenant schema under live conditions is a major engineering project that consumes runway and slows everything else down. Getting the tenancy model right before the first production line is written is the single highest-leverage architecture decision in a B2B marketplace.
How does multi-tenancy in a B2B marketplace differ from a standard SaaS application?
In a standard SaaS application, tenancy typically applies to one type of user — the customer organisation. In a B2B marketplace, tenancy applies simultaneously to suppliers and buyers, with the additional complexity that cross-tenant visibility is intentional in one direction (buyers can see supplier catalogues) but strictly prohibited in others (suppliers cannot see each other's pricing or order data, buyers cannot see each other's contract terms). This dual-tenancy requirement makes the isolation model significantly more complex to design and enforce.
When should a B2B marketplace use a microservices architecture?
Most B2B marketplaces should not start with microservices. A well-structured monolith — with clear domain boundaries between catalogue, order management, pricing, identity, and integration — is easier to build, deploy, and debug at the early stages. Microservices should be extracted only when a specific domain has genuinely divergent scaling requirements, team autonomy demands it, or the monolith has become a deployment bottleneck. Martin Fowler's guidance on this approach — often called the "modular monolith" path — is directly applicable to marketplace contexts [Source: martinfowler.com].
How do you manage pricing tiers for different buyers in a B2B marketplace?
Pricing tiers should be managed as a first-class domain service that is independent of the catalogue. The pricing service accepts a product reference, a buyer identity, a quantity, and any relevant context (contract membership, promotional window) and returns a resolved price. This keeps the catalogue focused on product data, makes pricing rules auditable and testable in isolation, and means that a new pricing rule — a buyer-group discount, a volume break, a time-limited promotion — can be added without touching the catalogue schema or the order service.
How do you avoid rebuilding a marketplace platform after 18 months?
The five decisions that most reliably prevent a rebuild are: (1) choose and document your tenancy model before build; (2) design the catalogue as a separate domain with attribute normalisation built into the ingestion pipeline; (3) build the pricing engine as an independent service from day one; (4) design order management to support multi-supplier fulfilment explicitly, not as a future extension; (5) adopt API-first design so every domain's interface is a deliberate contract rather than an accidental exposure. None of these decisions are expensive upfront. All of them are expensive to retrofit.
All project timelines and delivery estimates are indicative and subject to scope confirmation. Third-party service costs (hosting, domains, SaaS tools) are billed separately at cost. Decyb Technology LLP is registered in India; engagements are subject to terms of service available at decyb.com/terms.