Most SaaS architecture advice is about scale you do not have yet. Microservices, event sourcing, global multi-region deployment — the patterns of companies with a thousand engineers, applied to products with three. The decisions that actually matter for a growing SaaS are quieter and harder to reverse: how tenants are separated, how data is isolated, how background work runs, how the system is observed, and how a change gets from a laptop to production without breaking a paying customer. Get those right and the product can grow for years on a simple architecture. Get them wrong and no amount of microservices will save it.
Multi-tenancy: the decision you cannot easily undo
A SaaS serves many customers — tenants — from one system, and how you separate them shapes everything downstream. There are three broad models. Shared database, shared schema: every table has a tenant column, and every query filters on it. Simplest to operate, cheapest to run, and one missing filter away from showing one customer another's data. Shared database, separate schemas: each tenant gets its own schema. Stronger isolation, more operational complexity, and migrations that have to run hundreds of times. Separate databases per tenant: the strongest isolation and the easiest story for enterprise customers who want their data alone, at the cost of provisioning, backup and cost per tenant.
Most SaaS products should start with shared schema and make tenant isolation impossible to forget: a tenant identifier on every row, enforced at the data-access layer or with row-level security in the database, so that no query can run without a tenant scope. Design the identifiers and the access layer so that a move to separate databases for a few large customers is possible later. The mistake is not choosing shared schema; it is choosing it without the guardrails.
Data isolation and the blast radius
Beyond tenancy, ask what happens when something goes wrong. If one tenant uploads ten million rows, does every other tenant's dashboard slow down? If one tenant's integration floods the API, does everyone else get rate-limited? Isolation is about limiting the blast radius: per-tenant rate limits, per-tenant quotas on storage and jobs, and query patterns that do not let one large customer dominate shared resources. These are cheap to add early and painful to retrofit once a large customer is already causing the problem.
- Tenant identifier on every row, enforced below the application code
- Per-tenant rate limits and quotas from the first release
- Indexes that lead with the tenant column, so queries stay fast as data grows
- A tested procedure to export and delete a single tenant's data — customers and regulators will ask
Background jobs are half the product
Every SaaS ends up with more work happening outside the request cycle than inside it: emails, exports, imports, report generation, webhooks, syncs with a CRM or other third-party systems, billing runs. Treating this as an afterthought — a cron script here, a fire-and-forget thread there — produces a system where work silently fails and nobody knows.
The pattern that holds up is a proper job queue with persistent jobs, retries with backoff, dead-letter handling for jobs that keep failing, idempotency so a retried job does not send the email twice, and visibility: a dashboard of what is queued, running, failed and slow. Separate queues for fast and slow work so a large export does not delay password-reset emails. Design every job to be safe to run twice, because it will be.
Billing, plans and the entitlements problem
Every SaaS has to answer "what is this tenant allowed to do?" on every request, and the answer depends on their plan, their trial status, their seat count and whether their last invoice was paid. Teams that scatter this logic across the codebase — a plan check here, a feature check there — end up unable to change pricing without a release. Centralise entitlements: one service or module that answers "can tenant X do Y?", fed by the billing system, cached aggressively, and consulted everywhere. Then a new plan, a promotional limit or an enterprise exception is a data change, not a code change. Use a billing provider rather than building invoicing, tax and dunning yourself; that is a product in its own right and not the one you are selling.
The monolith question
Start with a well-structured monolith. One deployable, one database, clear internal module boundaries. It is faster to build, simpler to operate, easier to debug and cheaper to run — and it can carry a SaaS to a size most products never reach. Microservices solve an organisational problem: many teams needing to deploy independently. They introduce network calls where function calls used to be, distributed failures, and operational overhead that a small team pays for without getting the benefit.
The right preparation is not to build services early but to keep the monolith modular, so that if a part of the system needs to scale differently or be owned by a separate team later, it can be extracted with the boundary already drawn. Extract when there is a concrete reason — a component with different scaling needs, a team that is blocked on shared deploys — and not before.
The database will be the bottleneck
Application servers scale horizontally with little effort. The database does not, and it is where almost every SaaS hits its first real limit. The decisions that delay that day: indexes designed around the actual query patterns, with the tenant column leading; connection pooling from the start; read replicas for reporting and dashboards so analytical queries do not compete with transactions; caching of expensive reads with a clear invalidation story; and archiving or partitioning of old data before tables become unmanageable.
Plan for growth in data before growth in traffic. A table that is fine at a million rows behaves differently at a hundred million, and the queries that expose it are usually the dashboards and reports that scan a tenant's whole history. Pre-aggregate what is read often, paginate everything, and never let the UI run an unbounded query.
Choose a mainstream relational database — PostgreSQL is the safe default — and use it well before considering anything exotic. Most scaling problems attributed to the database are query and index problems, and they are fixable without a migration.
Observability before you need it
A SaaS you cannot see inside is a SaaS you cannot fix. Structured logs with a tenant and request identifier on every line, metrics for the things customers feel — request latency, error rate, queue depth, job failures — and traces that follow a request across the system. Alerts that page a person when a customer-facing threshold is crossed, not when a CPU is busy. Set this up in the first month, when it is cheap, rather than during the first outage, when it is not.
Deployment and the path to production
How a change reaches customers is architecture too. Automated tests on every change, a staging environment that resembles production, database migrations that are backward compatible so a deploy can be rolled back, and deployments that happen many times a week without a maintenance window. Feature flags let you ship code dark and enable it per tenant, which is how you give one customer early access or roll a risky change out slowly. The goal is that a deploy is boring.
Decisions that can wait
Multi-region deployment, Kubernetes, event-driven architecture, a separate analytics warehouse, GraphQL, edge computing — each is right for some products at some stage, and none is required to launch a successful SaaS. The discipline is to add complexity when a specific problem demands it and can be named, and to resist adding it because it appears in conference talks. A boring architecture that the team fully understands beats a sophisticated one that nobody can operate at two in the morning.
Frequently asked questions
Should we start with microservices?
No. Start with a modular monolith and one database. Microservices add operational cost that small teams pay without benefit. Extract a service when a part of the system has a concrete reason to be separate — different scaling needs or a team that needs to deploy independently.
Which multi-tenancy model is best?
Shared database and shared schema, with tenant isolation enforced below the application code, is the right start for most products. Keep the option of dedicated databases for large or regulated customers by designing tenant identifiers and the data-access layer with that move in mind.
When does a SaaS architecture need to be revisited?
When a specific symptom appears: database queries slowing as data grows, a large tenant affecting others, background jobs failing silently, deploys becoming risky. Each of those points to a specific change. Revisit on evidence, not on anniversaries.
At Inverge Tech we design and build SaaS platforms with these decisions made deliberately from the start — the same approach behind the Inverge Journals platform, which we built and now run as a managed service. If you are building a SaaS, or scaling one that is starting to strain, we can help.