SaaS Architecture Explained: Multi-Tenancy, Auth, Billing and Scaling
A plain-English technical breakdown of how SaaS products are architected — covering multi-tenancy models, authentication, Stripe billing design, and how to build for scale from day one.
TL;DR
- SaaS architecture has four critical pillars: multi-tenancy, authentication, billing, and horizontal scalability
- Start with shared database + tenant_id; use PostgreSQL Row-Level Security to enforce isolation
- Never build auth from scratch — use Auth0, Supabase Auth, or Clerk
- Stripe webhooks are the most brittle part of SaaS billing — handle idempotency carefully
- Design the API layer to be stateless from day one so it can scale horizontally
The Four Pillars of SaaS Architecture
Every SaaS product, regardless of industry or feature set, must solve four architectural problems well: how data is isolated between customers (multi-tenancy), how users are authenticated and authorised, how recurring billing is managed, and how the system scales as usage grows. Get any of these wrong and you will pay for it at scale.
Pillar 1: Multi-Tenancy Architecture
Multi-tenancy is what makes SaaS economically viable. You serve thousands of customers from a single codebase and infrastructure. The challenge is ensuring each customer's data is fully isolated from every other customer's data.
There are three established models:
Model A: Shared Database with Tenant ID
All customer data lives in one database. Every table has an organisation_id column. The application always filters queries by the authenticated tenant's ID.
Pros: Simple infrastructure, low cost, easy to maintain. Cons: Risk of data leakage if a query forgets the tenant filter. Mitigate with PostgreSQL Row-Level Security. Best for: Most B2B SaaS products.
Model B: Schema-Per-Tenant
Each customer gets their own PostgreSQL schema (namespace) within the same database instance. Tables are identical; schemas are separate.
Pros: Stronger logical isolation. Easier per-tenant backups and migrations. Cons: Schema management overhead grows with tenant count. Best for: Regulated industries like healthcare or finance with strict data isolation requirements.
Model C: Database-Per-Tenant
Each customer gets a completely separate database instance. Maximum isolation. Can be hosted in the customer's own cloud account for sovereignty.
Pros: True data sovereignty, easy compliance. Cons: Expensive and operationally complex at scale. Best for: Enterprise SaaS with large customers who demand their own infrastructure.
Pillar 2: Authentication and Authorisation
Authentication (who are you?) and authorisation (what are you allowed to do?) are two separate concerns that SaaS products must get right. A bug in either can expose customer data to the wrong people — the worst possible outcome for a SaaS business.
| Concern | What It Means | Implementation |
|---|---|---|
| Authentication | Verifying the user is who they claim to be | JWT tokens, session cookies, OAuth — use Auth0 or Supabase Auth |
| Authorisation | Verifying what the user is allowed to do | RBAC (roles: admin, member, viewer) enforced at API layer |
| Tenant Scoping | Ensuring users only see their organisation's data | organisation_id from JWT claim, enforced in every query |
| Plan Gating | Restricting features by subscription tier | Feature flags driven by active Stripe subscription plan |
| MFA / SSO | Enterprise security requirements | TOTP MFA, SAML SSO (available in Auth0, Clerk Enterprise tier) |
Pillar 3: Billing Architecture
Billing is not just a Stripe integration — it's a core part of your application's data model and business logic. Poor billing architecture causes revenue leakage, incorrect plan access, and customer trust issues.
The correct data model for Stripe billing in a SaaS product:
organisations id, name, stripe_customer_id subscriptions id, organisation_id, stripe_subscription_id, stripe_price_id, status, current_period_end, cancel_at_period_end -- status: trialing | active | past_due | canceled | incomplete
Key webhook events to handle from Stripe:
| Webhook Event | What It Means | Action Required |
|---|---|---|
| customer.subscription.created | New subscription started | Create subscription record, enable plan features |
| customer.subscription.updated | Plan changed or trial ended | Update plan, re-evaluate feature access |
| invoice.payment_succeeded | Monthly payment collected | Extend current_period_end, send receipt |
| invoice.payment_failed | Card declined | Set status past_due, send dunning email |
| customer.subscription.deleted | Subscription cancelled | Set status canceled, restrict access |
Critical: Stripe webhooks can be delivered more than once and out of order. Always handle webhooks idempotently — check whether the event has already been processed before taking action. Use Stripe's event ID to deduplicate.
Pillar 4: Scalability Architecture
The goal is horizontal scalability — being able to add more application server instances rather than buying a bigger machine. This requires three things:
Stateless Application Servers
No session state stored in application memory. All state goes in the database or Redis. Any server instance can handle any request. This allows you to run behind a load balancer and scale by adding more instances.
Database Read Replicas
Route read-heavy queries (dashboards, reports, list views) to read replicas. Route writes to the primary. This scales read capacity independently of write capacity and dramatically reduces load on the primary.
Background Job Queues
Move any work that doesn't need to happen synchronously (emails, webhooks, data processing, reports) to a background job queue (Celery + Redis, BullMQ, or AWS SQS). This keeps API response times fast even under high load.
The Complete SaaS Architecture Diagram
Browser / Mobile App ↓ CDN (Cloudflare) — static assets, edge caching ↓ Load Balancer (AWS ALB) ↓ Next.js Frontend (multiple instances) ↓ FastAPI Backend (multiple stateless instances) ↓ ┌────────────────────┬────────────────────┐ │ PostgreSQL Primary │ Redis Cache │ │ (writes) │ (sessions, queue) │ ├────────────────────┤ │ │ Read Replica │ │ │ (reads) │ │ └────────────────────┴────────────────────┘ ↓ Background Workers (Celery/BullMQ) ↓ Email (Resend) | S3 (files) | Stripe (billing)
Architecture Decisions That Are Hard to Reverse
| Decision | Cost to Change Later | Get Right From Day 1 |
|---|---|---|
| Multi-tenancy model | Very High — full data migration | Yes |
| Auth provider | High — user migration, token changes | Yes |
| Billing integration | High — subscription migrations are risky | Yes |
| Primary database engine | Very High — full data re-migration | Yes (use PostgreSQL) |
| API versioning strategy | Medium — breaking API changes affect integrators | Version from day one |
Need Help Designing Your SaaS Architecture?
We design and build production-ready SaaS products with the right architecture from day one — multi-tenancy, billing, auth, and scalable infrastructure all included.
Book an Architecture Review