Multi-tenant from day one (and why retrofitting hurts)
Tenant isolation isn't a feature you add later. The choices that make wrong-tenant access impossible by construction.
The most expensive architectural mistake in gov-tech SaaS is single-tenant first, multi-tenant later.
Tenant isolation is not a layer you bolt on. It's a property of the identity layer, and it has to be enforced on every read, write, search, aggregate, callback, and side effect. If you retrofit, you'll spend years finding the leaks.
Our approach: tenant ID is bound to the auth token. The gateway resolves the token, attaches the tenant, and every downstream service receives the tenant as part of the request context — not as a header the application has to remember to check.
Reads filter by tenant in the repository layer. Writes assert tenant ownership before mutation. Searches scope by tenant before query execution. Aggregates partition by tenant. There is no API path that returns cross-tenant data.
Wrong-tenant access is rejected at the gateway, not the application. That's the design property: even an application bug can't expose cross-tenant data, because the application never sees the cross-tenant query.
This is what 'multi-tenant by default' means in practice. It's not a checkbox. It's a property of the request lifecycle.