Architecture and Infrastructure

Marketplace Software

A marketplace system does more than take orders: it keeps thousands of sellers' data isolated in the same database, splits an order from a single basket across several parties, and does it under the traffic spikes of a sale day. This page explains how the architecture is built.

Start Free TrialBook a Technical Call
Every capability exists as an API before anything else
API-firstEvery capability exists as an API before anything else
The application layer is stateless; you add replicas
Horizontal scalingThe application layer is stateless; you add replicas
The option to run it on your own servers
Cloud or on-premiseThe option to run it on your own servers
The database and files stay under your control
Data ownershipThe database and files stay under your control

Why Are Architectural Decisions the Most Expensive Ones to Correct Later?

The questions you ask when choosing marketplace software are different from those you ask when choosing a single-seller e-commerce package. Here the system does more than take orders; it keeps the data of thousands of sellers who do not know each other isolated in the same database, applies a separate permission scope for every seller, splits an order from a single basket across several parties, and does all of that under the traffic spikes of a sale day.

That is why architectural decisions are the most expensive ones to correct later. The depth of the category tree, how product attributes are stored, whether the search layer is separated from the database, and where file storage sits — none of this is visible in the first months, yet at a scale of millions of records it sets the ceiling of the system. Equally, the authentication and permission model has to be designed for multi-tenancy from the start.

The third matter is independence. Payment institutions, carriers and invoicing services change over time; a system wired directly to them is rewritten with every change. Provider-agnostic interfaces remove that risk. The same logic applies to deployment: software that can only run on a single cloud provider is a constraint in the long run.

Architecture

Application and Data Layers

On the left how the business logic is divided, on the right where the data sits. As scale grows, it is the right-hand column that decides things.

Application layers

  • The API layer: every capability exists as an endpoint first, and interfaces consume it
  • Modular business logic: order, payment, shipping and seller live in separate modules
  • Provider-agnostic interfaces: payment, shipping and invoicing integrations bind to a contract
  • A workflow engine: rule-based automation defined without a code change
  • The storefront layer: a server-rendered, SEO-friendly front end
  • Admin panel and seller panel as separate interfaces on a shared API

Data and infrastructure layers

  • A relational database: data requiring consistency, such as orders, payments and earnings
  • A search engine (Typesense): separating catalogue search from the database
  • A caching layer: so frequently read catalogue and content data is not recomputed
  • Object storage: product images and files, distributed via a CDN
  • Queues and background jobs: bulk imports, notifications and webhook delivery
  • Transaction logs and an audit trail
Technical Capabilities

The Technical Guarantees the Infrastructure Provides

Multi-Tenant Data Isolation

Seller data is separated at organisation level and every query passes a scope check. One seller reaching another's data is prevented architecturally.

Role-Based Access Control

Separate permission scopes for the platform administrator, the seller, the seller's staff and the customer. Permissions are defined at resource level.

A Separated Search Layer

Catalogue search puts no load on the database. Typo tolerance, faceted filtering and millisecond responses at a scale of millions of records.

Horizontal Scaling

The application layer runs stateless; when traffic rises you add replicas. Adding resources on a sale day happens without downtime.

Cache and CDN Architecture

Catalogue and content are cached and images are distributed via a CDN. The number of requests reaching the origin server falls markedly.

Workflow Engine

Condition-and-action rules are defined from the panel; no release is needed for a new automation.

Webhook and Event Layer

Internal events are delivered to external systems as signed requests; failed deliveries are retried and queued.

Multi-Language and Multi-Currency Structure

Content and catalogue are managed per language; the URL structure and structured data are generated separately for each one.

Security Layer

Token-based authentication, scope-based API keys, rate limits and an audit trail.

An SEO-Friendly Storefront

Pages are rendered on the server, so search engines see the content without executing JavaScript. Structured data and canonical management come ready.

Release and Deployment Management

Test, staging and production environments are separated; updates are applied in a controlled way.

Extensibility

Additional modules and third-party apps connect through the same API layer; the core code is never modified.

Deployment Model

Cloud, On-Premise and Hybrid Compared

The decision is usually driven by compliance rather than technology: where the data has to sit is what settles it.

CriterionCloud (managed)On-premiseHybrid
Server responsibilityWith usWith youShared
Data locationCloud in the region you chooseYour own data centreSensitive data with you, the rest in the cloud
ScalingAdding resources is fast and flexibleBounded by hardware capacityVaries by layer
Initial costLowRequires hardware investmentMedium
Compliance requirementSufficient for most scenariosSuitable when data must stay in the countrySuitable under partial restrictions
Maintenance and updatesBy usPlanned with your IT teamShared
Who It Suits

Which Teams Is This Infrastructure Right For?

Companies With Their Own Development Team

Your team can write its own front end on the API layer, add custom modules and connect it to your existing systems. You keep receiving core updates.

The API and webhook layer

Enterprise IT and Compliance Requirements

Where the data sits, who reaches it and how it is backed up are set out contractually. On-premise deployment and the audit trail are ready for these scenarios.

High-Traffic Projects

On projects where traffic multiplies on sale days, the separated search layer, caching and horizontal scaling work together.

Teams Who Want to Go Headless

You can use the platform purely as a data and business logic layer and write the front end in your own technology.

Headless e-commerce
Operations

Four Things Watched After You Go Live

Monitoring and alerting

Response times, error rates and queue latency are monitored; alerts are raised when a threshold is crossed.

Backups and recovery

Regular backups and restore drills; what matters is not that a backup exists but that you can come back from it.

Access discipline

Access to the production environment is restricted by role and every operation is recorded in the audit trail.

Capacity planning

Load testing and resource increases are planned before a campaign; the scaling decision is not taken after the traffic arrives.

FAQ

Frequently Asked Questions

The questions technical teams and IT decision-makers ask most often.

In four places. First, multi-tenancy: the data of thousands of sellers has to stay isolated in the same database and every query has to pass a scope check. Second, authorisation: separate permission scopes are needed for the platform administrator, the seller, the seller's staff and the customer. Third, order splitting: an order from a single basket is distributed across several parties and each part follows its own life cycle. Fourth, financial separation: commission and earnings have to be recorded as separate lines on every transaction.
The critical decision is separating the search layer from the database. Catalogue search runs on Typesense; typo tolerance and faceted filtering work without loading the database. On top of that come a caching layer and image distribution via a CDN. Because the application layer is stateless, horizontal scaling is done by adding replicas when traffic rises; on sale days resources are added without downtime.
Yes, on-premise deployment is supported. That option is chosen particularly in enterprise scenarios where data has to stay in a specific location. In that case server responsibility and scaling sit with your IT team and updates are planned together. Hybrid arrangements — sensitive data with you, the rest in the cloud — are also possible.
You do. The database and file storage are under your control; on an on-premise deployment entirely on your own infrastructure, and on a managed deployment held in your name and belonging to you. Exporting data is always possible through the API and bulk export tools; you are never locked into a platform.
No. Payment, shipping and invoicing integrations connect through provider-agnostic interfaces; every provider implements the same contract. Adding a new provider means writing an implementation that satisfies that interface, and the rest of the application code stays unchanged. You can also define several providers at once and route by region or by condition.
Yes. Because the platform is designed API-first, every capability exists as an endpoint first; the ready storefront is only one of the layers consuming that API. You can write your own front end in whatever technology you like and use the platform as a data and business logic layer. Because the mobile app consumes the same API, content management stays in one place.
Not when extensions are made without modifying the core code. Additional modules and third-party apps connect through the same API layer, and business rules are defined from the workflow engine; neither is affected by version updates. In scenarios where the core has been changed directly, the update plan is worked through together on a per-project basis.
Storefront pages are rendered on the server, so search engines see the content without executing JavaScript. Structured data is generated for product, category and content pages, and canonical management and a multi-language URL structure come ready. That keeps the category and product pages — which become the main source of organic traffic as the catalogue grows — indexable.

Related Pages

Multi-Vendor E-Commerce

The business side of it: two-sided market dynamics, take rate and operations.

Marketplace API Integration

The REST API surface, webhook events and integration patterns.

Headless E-Commerce

Writing the front end in your own technology and using the platform as a data layer.

All Marketplace Features

The full account of the modules in the infrastructure and their technical detail.

Let's Review Your Architectural Requirements Together

Let's set up a technical call around your expected volume, your integration list and your deployment model.

Book a Technical CallExplore Features

On-premise option · You own the data · 24/7 support