You are choosing an architecture style for a new B2B SaaS product. Six engineers. Enterprise customers with data residency requirements in three regions. Which style and why?

What is being tested

Whether you can let the drivers choose the style, and whether you notice that the residency requirement is doing more structural work than the team size.

Reading the drivers

Six engineers rules out anything with a large fixed operational cost. That points at a monolith or a modular monolith, and it is the correct starting point.

But data residency in three regions is a structural driver, and it is the one that decides the shape. It means there is no single global database, because customer data cannot leave its region. That has consequences most designs discover too late:

• Every request must be routed to the correct region before it touches data, which means tenancy must be resolvable at the edge — from the hostname, the token, or a globally replicated tenant directory holding no personal data.
• Cross-tenant global features — aggregate analytics, a global search, an admin console — either become per-region, or operate on data that has been deliberately anonymised or aggregated to the point where it may leave.
• Your control plane and your data plane are now different things with different residency rules, and conflating them is the classic mistake.

The recommendation

A modular monolith deployed as a per-region cell, with a thin global control plane.

Each region runs a complete, independent copy: application, database, cache. Tenants are pinned to a region. The global layer holds only routing information — which tenant lives where — plus billing and provisioning, and is designed to hold nothing that residency rules cover.

What this buys:

• Residency is structural, not enforced by code review. Data cannot leave a region because there is no path for it to leave. This is far easier to explain to an auditor than row-level filtering.
• Regions are blast radius boundaries. One region's outage is contained to its tenants.
• Six engineers can operate it. One codebase, one deployment pipeline run three times, one runtime to debug.
• A large customer can be given a dedicated cell later without changing the architecture, which is a common enterprise sales requirement and normally an expensive retrofit.

What it costs: three times the infrastructure baseline for the same total traffic, deployments that must be rolled per region, and genuine difficulty in producing cross-region aggregates.

What would change the answer

If residency were not required, a single-region deployment with read replicas is simpler and cheaper, and should be preferred. If the product had one workload with a radically different resource profile — video processing, model inference — extract that one component and leave the rest. If enterprise customers demand full single-tenant isolation, the cell model already accommodates it, which is the strongest argument for choosing it now rather than later.

What would be wrong

Microservices, at six engineers, for a product with no proven boundaries. A single global database with a region column and application-level filtering, which satisfies nobody's compliance officer. A separate codebase per region, which triples the maintenance for no benefit.