Production AI systems and digital engineering for enterprise teams.Explore our work
Composable services, clear boundaries, and data ownership—patterns we use for multi-tenant products.
Article
Scaling SaaS is less about bigger servers and more about clear boundaries—who owns data, how services communicate, and where you accept coupling. This article covers the path from early product to multi-tenant platform without a premature microservices split.
Audience
Staff engineers & architects
Stage
Growth → scale
Focus
Boundaries & tenancy
Prerequisites
Product-market fit
Your monolith served you well through early customers. Now release trains feel fragile, one noisy tenant affects others, and every new integration touches five modules. The team debates microservices while incidents still come from unclear data ownership.
How to use this guide
Grow structure with revenue and team size—boundaries first, deployables second. Every split should answer who owns on-call for the new surface area.
Follow the phases below from scoping through steady-state operations. Each section builds on the previous—skip ahead only if your foundations are already in place.
Concepts, tradeoffs, and implementation notes from programs we've run.
01
We favor a modular monolith or a small number of well-bounded services until team topology justifies more deployables. Each module owns its schema and exposes explicit APIs—HTTP or events—with versioned contracts documented in the repo.
Premature microservices multiply failure modes: distributed transactions, partial deploys, and observability gaps—without the organizational scale to operate them.
02
Tenant ID belongs on every row that matters, enforced in the data access layer—not sprinkled in controllers. Row-level security in Postgres, schema-per-tenant for isolation-heavy verticals, or dedicated cells for enterprise tiers are explicit product decisions with cost tradeoffs.
Background jobs, exports, and analytics pipelines must inherit tenant context. A common outage is a report job that aggregates across tenants because a queue message dropped the ID.
03
Publish domain events at boundaries you expect to outlive the monolith: billing state changes, user lifecycle, document ingestion. Consumers should be idempotent; schemas should be backward compatible with a documented deprecation window.
Public APIs get versioning and SLA tiers. Internal APIs can move faster but still need contract tests so refactors do not break sibling modules silently.
04
Instrument request tracing from day one—correlate API, worker, and database spans. Define SLOs on core journeys (signup, checkout, sync) before you need them for enterprise sales.
When pricing is usage-based, attribute infrastructure cost per tenant early. It informs packaging, abuse detection, and capacity planning.
A phased path you can adapt to your team size and risk profile.
How we deliver
Grow structure with revenue and team size—boundaries first, deployables second. Every split should answer who owns on-call for the new surface area.
Use before you expand scope or declare general availability.
Documented bounded contexts and data owners
Tenant enforcement in persistence layer
Tracing across API and workers
SLOs defined for core journeys
Event contracts with versioning policy
Cost attribution per tenant or tier
Key takeaways
Topics & tools
Keep reading
More notes on engineering, AI, and delivery from our team.
Tell us what you're building—we'll share relevant experience from programs like this.
