ResourcesSlize application: infrastructure overview
How Slize is built, from the frontend to the cloud infrastructure — what runs where, what is isolated per client, and why the system of record stays where it is.
This is a high-level overview of the Slize application architecture and the cloud infrastructure underneath it: how the frontend, core commerce logic, search, pricing and integrations are separated, and what that separation buys in performance, security and scale.
It is technical enough for IT and solution architects, and structured so that digital, e-commerce and commercial teams can follow it without infrastructure background. If you are evaluating Slize from any of those seats, this is the part that explains why it behaves the way it does.
One thing to establish first, because it shapes everything below: Slize does not replace your ERP. It sits on top of it, handling digital commerce logic, pricing and order flows, while the ERP stays the system of record.
The application layer
The application splits into three zones. Client-side is the user and the frontend served through a CDN. Slize-side is the API gateway and the modules behind it. Customer-side is your own estate — the systems of record — reached through the integration layer.
Everything a channel needs arrives through one surface. That is what allows the frontend to be fast — it is reading from the commerce layer, not waiting on an ERP query — and it is what keeps high transaction volumes from turning into ERP load.
Behind the gateway, each concern is its own module, and each can be scaled or replaced without touching the others.
Catalog, basket, order and account logic — the transactional heart of the platform.
Umbraco as the CMS, so editorial content and commerce data are managed in the tools each is best at.
A dedicated search engine, scaled on its own pool because catalog search load has nothing in common with checkout load.
The pricing engine, where contract terms, market movement and customer-specific rules resolve into the number a buyer sees.
The internal surface — the same data as the storefront, presented for the people selling against it.
The boundary to the systems of record, and the only place that boundary is crossed.
The infrastructure
Slize runs as containerised services on shared, purpose-separated pools. Traffic reaches them through a firewall and a per-client load balancer; nothing is exposed directly.
The application containers. Horizontal scale here absorbs traffic, users and order volume as they grow, and peaks without a re-architecture.
Search engines, on their own pool. A catalog re-index cannot slow down checkout when the two do not share compute.
The Umbraco and Commerce databases — separate databases per client, on pooled infrastructure.
CDN, secrets vault, blob storage and log storage: the shared platform services every client environment draws on.
The unit of isolation is the client. Each one gets its own load balancer, application instances, search engine, Umbraco database and Commerce database, alongside its own CDN, secrets vault, blob storage and logs. The pools are shared; what runs in them is not.
That is what makes multi-entity and multi-market setups straightforward rather than exceptional: a group can run several isolated environments — per country, per brand, per subsidiary — on the same shared core services, without one of them being able to affect another.
What the shape buys you
- Independent scaling — frontend, search, pricing and backend grow separately, because their load profiles are different
- Horizontal scale on demand — Kubernetes pools absorb traffic and order volume without a redesign
- Isolation with shared services — multi-entity and multi-market estates, each in its own environment
- Security by default — firewalls, load balancers, secrets vaults and centralised logging in every environment
- No ERP overload — large catalogs, complex pricing and customer-specific rules are served by the commerce layer
The architecture is not unusual for its own sake. Each separation in it exists because wholesale workloads are lopsided — a catalog of hundreds of thousands of items, pricing that changes daily, order volumes that spike, and an ERP that must not be asked to carry any of that in real time.
See what Slize does with your catalog and ERP landscape.
Book a walkthrough tailored to your systems and product complexity — or just say hello.