SaaS Architecture Explained: Multi-Tenancy, Auth, Billing and Scaling

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
• 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. That is the worst possible outcome for a SaaS business.

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:

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. This means 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 to a background job queue (Celery + Redis, BullMQ, or AWS SQS). This includes emails, webhooks, data processing, and reports. 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

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.

Related Articles & Services

Continue reading