Technology Startups
FalakA Multi-Tenant SaaS Foundation
An illustrative cloud-native SaaS architecture that separates control plane from data plane and grows from the first customer to enterprise accounts without a rebuild.
01
The challenge
Most SaaS products start with a shared database and a tenant_id column added to queries by hand. It works for the first months, then becomes security debt: one query that forgets the filter is enough to expose one customer’s data to another.
When the first enterprise customer arrives, the questions change. Do you support SAML single sign-on and SCIM provisioning? Where is our data stored? Can we be isolated in a dedicated environment? What does your audit log look like? What is your SLA? Many young teams have no ready answers.
Meanwhile, cloud costs grow without anyone knowing which customer consumes what, fragile pipelines make every release a gamble, and noisy neighbors let one tenant slow the platform for everyone.
02
Proposed solution
Falak separates two planes: a control plane that manages the tenant registry, provisioning, entitlements, usage metering and billing, and a data plane that runs the application itself. Onboarding a new tenant is a durable, resumable workflow, not a manual script.
Isolation comes in tiers chosen by plan: a pooled model protected by PostgreSQL row-level security enforced in the database itself (not just in application code) for smaller customers; a dedicated schema or database for mid-market; and a fully dedicated cell for enterprise customers or in-Kingdom data residency requirements.
The identity layer handles single sign-on via OIDC and SAML and user provisioning via SCIM, with authorization policies written in Open Policy Agent. Everything is managed GitOps-style with Terraform and Argo CD, with per-tenant telemetry and cost allocation that reveals the margin of each account.
03
Design rationale
The platform admin console is an operations tool before it is an interface: a fast tenant switcher, a persistent color band that separates production from staging to prevent costly mistakes, dense keyboard-filterable tables, and double confirmation for any action that touches customer data.
Each tenant has its own language, time zone and number formatting, so the product appears in Arabic on Riyadh time for one customer and in English for another, with no extra setup. An onboarding wizard guides each new account admin step by step to first real value.
Dark mode is the default for operations teams, light is one click away, and both meet WCAG 2.2 AA contrast. The public status page is designed to stay honest and legible even on the worst days.
04
Example architecture
An illustrative layering of the system, from the screens people use down to the infrastructure. A starting point we would validate during discovery, not a final design.
Layer 01
Control plane
- Tenant registry & lifecycle
- Temporal provisioning workflows
- Entitlements & feature flags
- Usage metering & billing
Layer 02
Data plane
- Stateless services on Kubernetes
- Pooled tier with PostgreSQL RLS
- Schema- or database-per-tenant tier
- Dedicated cells for enterprise & residency
Layer 03
Identity & access
- Keycloak with OIDC & SAML SSO
- SCIM user provisioning
- Open Policy Agent authorization
- Per-tenant audit log
Layer 04
Platform & delivery
- Terraform infrastructure as code
- Argo CD GitOps
- Progressive delivery with canaries
- Istio service mesh with mTLS
Layer 05
Observability & FinOps
- OpenTelemetry with tenant context
- Prometheus & Grafana
- Per-tenant SLOs
- Cost allocation by tenant
Layer 06
Experience
- Next.js customer application
- Tenant admin console
- Internal operations console
- Public status page
05
Relevant technologies
Tools we would consider for this concept. They indicate engineering ecosystems, not partnerships or certifications.
- Kubernetes
- Argo CD
- Terraform
- Istio
- Go
- TypeScript
- Next.js
- PostgreSQL
- Temporal
- Keycloak
- Open Policy Agent
- OpenTelemetry
- Prometheus
- Grafana
06
Key features
Tiered tenant isolation
From a pooled model enforced in the database to a fully dedicated cell, by plan.
Enterprise readiness
SAML SSO, SCIM provisioning and a per-tenant audit log.
Automated provisioning
New tenants created with their infrastructure and settings via a durable, resumable workflow.
Usage-based metering and billing
Accurate consumption metering that feeds billing and entitlements.
Safe, progressive delivery
GitOps with canary releases and automatic rollback on failure.
Per-customer cost visibility
Cloud costs allocated by tenant to reveal the margin of each account.
07
Potential benefits
These are design goals the solution is built toward, not measured results.
Designed to reduce the risk of cross-tenant data exposure
Faster enterprise deals with requirements answered up front
Better control of cloud costs and per-account margin
More frequent releases with less risk
A clear growth path from the first customer to enterprise accounts
Related services & industry
Industry
Product engineering for founders: from a validated MVP to a scalable, investor-ready SaaS platform.
Services involved
Secure, scalable cloud foundations, automated delivery pipelines and full observability on AWS, Azure and Google Cloud.
Security built into architecture, code, and delivery pipelines from day one, not bolted on after launch.
Bilingual corporate sites, online stores and web platforms engineered for speed, security and scale.
ERP, CRM, HR and finance systems shaped around how you work: integrated, adaptable and built to grow with you.
REST and GraphQL APIs, payments, webhooks, and event-driven integrations that make separate systems work as one.
This is an illustrative solution created by AMA GROUP to explain a possible approach. It is not a client engagement: the interface uses sample data, and no client, logo or result is implied.
Have a similar challenge?
Share the problem you are facing. We will come back with a clear approach, scope and next steps.