Solution
Multi-tenant SaaS platforms engineered for isolation and scale
We build the platform beneath a SaaS product: the tenancy model, identity, billing, onboarding and release machinery that decide whether the product can serve its hundredth customer as safely as its first.
The problem space
A SaaS product is two systems. One is the application customers see. The other is the platform that provisions tenants, authenticates their users, enforces their plan, meters their usage, bills them and keeps their data apart from everyone else's. The second system is rarely on a roadmap, and it is the one that determines unit economics, enterprise readiness and how painful growth becomes.
The foundational decision is the tenancy model. In a pool model all tenants share compute and storage, which is efficient and simple to operate but demands strict logical isolation. In a silo model each tenant has dedicated resources, which isolates well and costs more to run and release. A bridge model mixes the two, commonly shared compute with separate databases or schemas, or pooled infrastructure for standard plans with dedicated stacks for the largest customers. Each choice has consequences for cost, compliance conversations, noisy-neighbour risk and deployment complexity.
We design the platform so the tenancy decision is explicit, enforced in code and reversible where it reasonably can be. Tenant context is established once at the edge and carried through every service, query, cache key, queue message and log line. Everything else in the platform builds on that guarantee.
Why it is hard
Engineering challenges
Tenant isolation that depends on developer discipline
If isolation relies on every query remembering a tenant filter, one missed clause exposes one customer's data to another. This is the most damaging failure a SaaS product can have. Isolation must be enforced beneath the application code, through row-level security, scoped credentials or separate stores, so that a forgotten filter returns nothing instead of everything.
Noisy neighbours
In shared infrastructure one tenant's bulk import or runaway report can exhaust database connections and degrade service for all others. Without per-tenant rate limits, quotas and workload separation, the largest customer sets the experience for the smallest.
Enterprise identity requirements
Enterprise buyers expect SAML or OIDC single sign-on, SCIM provisioning, enforced multi-factor authentication and role mapping from their directory. Retrofitting these onto a home-grown username and password table is slow and error-prone, and it tends to arrive as a blocker during a procurement review.
Metering that disagrees with invoices
Usage-based pricing needs every billable event counted exactly once. Events that are dropped under load, double-counted on retry or attributed to the wrong period produce invoices customers dispute. Metering is a data-integrity problem before it is a billing integration.
Releases across many tenants
A schema migration that locks a large table takes every tenant offline at once. With siloed tenants the problem inverts: hundreds of stacks drift to different versions. Both need a deliberate release design covering backward-compatible migrations, progressive rollout and automated fleet management.
No per-tenant view of health
Aggregate dashboards hide the fact that one tenant has had failing requests for an hour. Support cannot answer a customer's question, and engineering cannot tell a platform fault from a tenant-specific one. Telemetry has to carry tenant identity from the first request.
How we build it
Architecture
The platform is split into a control plane that manages tenants and a data plane that serves them. Tenant context is resolved once at the edge and enforced at every layer below it.
- 01
Control plane
A set of services owns the tenant lifecycle: sign-up, provisioning, plan assignment, configuration, suspension and offboarding. Provisioning is an idempotent workflow, so a failure halfway through can be retried without leaving a half-created tenant. The control plane is the single source of truth for which tenants exist and where their resources live.
- 02
Tenant resolution and isolation layer
The tenant is identified from a verified token claim or domain at the gateway and propagated as request context. In a pooled PostgreSQL design, row-level security policies bind every query to that tenant; in bridge and silo designs a routing layer selects the tenant's schema, database or cluster. Cache keys, object-storage prefixes and message topics are scoped the same way.
- 03
Identity and access
Authentication is delegated to a standards-based identity provider that supports per-tenant SSO connections over SAML and OIDC, SCIM provisioning and configurable MFA policy. Authorisation is role-based with tenant-scoped roles, evaluated in a central policy component so rules are consistent across services. Platform staff access to tenant data is separately controlled, time-bound and logged.
- 04
Metering and billing
Services emit usage events with idempotency keys to a durable stream. An aggregation pipeline deduplicates and rolls them up per tenant and billing period, and the totals are pushed to a billing provider that handles invoicing, tax and payment collection. The raw events are retained so any invoice line can be reconstructed and explained.
- 05
Entitlements and feature flags
Plans are expressed as entitlements: which features a tenant has, and what limits apply. Services query an entitlement service, with local caching, instead of hard-coding plan names. Feature flags are a separate mechanism used for progressive rollout, so releasing code and enabling a capability for a customer are independent decisions.
- 06
Release and migration pipeline
Deployments are rolling or blue-green with automated health checks and rollback. Schema changes follow the expand and contract pattern, so old and new application versions run against the same database during a rollout. For siloed tenants, infrastructure as code and a fleet orchestrator apply changes in waves, starting with internal and low-risk tenants.
- 07
Per-tenant observability
Logs, metrics and traces carry a tenant identifier, which allows service-level objectives, error rates and cost to be reported per tenant. Quotas and rate limits are enforced at the gateway and at shared resources such as connection pools and queues. Alerts fire on tenant-level degradation, not only on platform-wide averages.
Tenant-aware Edge
- Custom domains
- Tenant resolution
- WAF
- Per-tenant rate limits
Identity & SSO
- SAML and OIDC
- SCIM provisioning
- Roles and permissions
- MFA
Control Plane
Manages tenants, never serves their traffic
- Tenant lifecycle
- Plans and entitlements
- Billing and metering
- Feature flags
Application Plane
- Stateless services
- Background jobs
- Tenant context
- Webhooks
Data Isolation
Isolation model chosen per plan tier
- Row-level security
- Schema per tenant
- Dedicated databases
- Per-tenant keys
Per-tenant Observability
- Usage metrics
- Tenant-tagged traces
- Noisy-neighbour alerts
- Audit logs
What an engagement delivers
- Tenancy model decision record with cost and isolation analysis
- Control plane with automated tenant provisioning and offboarding
- Identity integration covering SSO, SCIM, MFA and role-based access
- Usage metering pipeline and billing provider integration
- Entitlement service and feature-flag framework
- Zero-downtime deployment and schema migration pipeline
- Per-tenant dashboards, quotas and alerting
Before you start
Decisions to make early
- Pool, silo or bridge
- Default to a pooled model with isolation enforced in the database when tenants are numerous and similar; it is the cheapest to run and the simplest to release. Choose silo when customers require dedicated infrastructure, their own encryption keys or a specific region, and price for it. A bridge model, pooled by default with the option to place a tenant on dedicated resources, suits products that sell to both small teams and large enterprises.
- Build or buy identity and billing
- Buy both unless they are your product. A managed identity provider and a billing platform encode years of edge cases in protocols, tax and payment failure handling. Build the parts that are specific to you: the tenant model, the entitlement logic and the metering pipeline that feeds billing.
- Modular monolith or microservices
- Early-stage platforms are usually better served by a well-structured modular monolith with clear module boundaries and one deployment. Split out a service when a module has a distinct scaling profile, release cadence or team. Starting with many services multiplies operational work before there is the traffic or headcount to justify it.
- When to offer single-tenant deployments
- Offer them when a customer's requirement cannot be met by logical isolation and the contract value covers the operating cost. Make sure provisioning and upgrades for dedicated stacks are fully automated first. Hand-built single-tenant environments are how a SaaS company quietly becomes a hosting business.
FAQ
Common questions
Can an existing single-tenant product be made multi-tenant?
Usually, and the work is larger than adding a tenant column. It involves introducing tenant context throughout the request path, enforcing isolation in the data layer, migrating existing customers' data and reworking background jobs, caches and file storage. We normally stage it, starting with an isolation layer and the control plane, then migrating tenants in groups.
How do you prove tenant isolation works?
By testing it as a security property. Automated tests attempt cross-tenant reads and writes through every API and are run in the delivery pipeline. Database policies are reviewed and tested independently of application code, and isolation is included in the scope of penetration testing.
Does zero-downtime release cover database changes?
It can, with discipline. Changes are split into backward-compatible steps: add the new structure, write to both, backfill, switch reads, then remove the old structure in a later release. Operations that would lock large tables are run with online migration tooling or in batches.
Which cloud do you build on?
The design is not tied to one provider. We work with the major public clouds and choose managed services where they reduce operating burden. The choice generally follows your existing footprint, data-residency requirements and the skills of the team that will run the platform.
Related
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.