Multi-tenancy: the first and least reversible decision
Multi-tenancy — many customers sharing one system — has three common shapes, and choosing wrong is expensive to undo.
| Approach | Isolation | Operational cost | Suits |
|---|---|---|---|
| Shared database, shared tables, tenant column | Lowest | Lowest | Many small customers |
| Shared database, schema per tenant | Medium | Medium | A balance of both |
| Database per tenant | Highest | Highest | Few large customers, strict compliance |
The biggest risk with the first is a query that forgets its tenant filter, letting one customer see another’s data. The defence is not being more careful; it is making the omission impossible — put the filter in the data access layer, or use PostgreSQL row-level security, so there is no path that writes a query without it.
When microservices are right
Microservices solve an organisational problem more than a technical one. They let multiple teams work and deploy independently.
With a single team, splitting into ten services usually slows things down: each change touches several repositories, debugging means tracing across services, and a transaction spanning four services is far harder than one inside a single database.
The lower-risk start is a single deployable with clean module boundaries inside it. When a module proves it needs its own scaling or its own team, split it out. Clean boundaries make that split painless later.
What production-ready means
A platform serving many customers needs things an internal product can skip.
It must be observable: structured logs, metrics, and traces that follow one request across services. When a customer reports slowness you need to answer where, not guess.
It must isolate blast radius: one customer running a heavy report must not slow everyone else. Usually handled with per-tenant rate limits and separate queues for heavy work.
And onboarding must be automatic. If adding a customer requires an engineer running scripts by hand, it is not a platform yet — it is a product installed repeatedly.