Designing a Multi-Tenant B2B SaaS Without Microservices
How to build high-scale multi-tenant applications using a unified modular monolith with PostgreSQL Row-Level Security, connection pooling, and background worker queues.
Founders frequently get persuaded by agencies to build microservices on Kubernetes for a v1 B2B product. They end up with 15 repositories, distributed transaction nightmares, $4,000/mo cloud bills, and zero users.
How to guarantee 100% cryptographic tenant isolation, sub-50ms API response times, and zero cross-tenant data leakage while keeping the operational overhead low enough for a lean engineering team.
+-------------------------------------------------------------------------+
| CLIENT TRAFFIC |
| (Browsers, Mobile Apps, Third-Party Webhooks, Enterprise SSO) |
+------------------------------------+------------------------------------+
| HTTPS / Edge Network (Cloudflare)
v
+-------------------------------------------------------------------------+
| EDGE ROUTING & AUTHENTICATION LAYER |
| - Session Validation & JWT Claims Verification (Org ID, Role, Perms) |
| - Rate Limiting (Token Bucket per Tenant ID via Upstash Redis) |
+------------------------------------+------------------------------------+
|
v
+-------------------------------------------------------------------------+
| APPLICATION CORE (Next.js Node.js Monolith) |
| |
| +-----------------------+ +-------------------+ +-----------------+ |
| | Tenant Context Middle | | Domain Services | | Event Bus | |
| | (Sets 'app.tenant_id')| | (Billing, CRM...) | | (In-Process) | |
| +-----------------------+ +-------------------+ +-----------------+ |
+-------------------+--------------------------------+--------------------+
| | Async Task Dispatch
v v
+-------------------------------------+ +-------------------------------+
| DATABASE POOL (PgBouncer) | | BACKGROUND WORKERS (BullMQ) |
| - Connection pooling across cores | | - Metered Billing Jobs |
| - Sets current_setting('tenant') | | - Webhook Dispatchers |
+-------------------+-----------------+ | - PDF / Export Generators |
| +---------------+---------------+
v |
+-------------------------------------+ |
| POSTGRESQL (RLS Enabled) | |
| - Row-Level Security on every tab | <-----------------+
| - Isolated schemas for enterprise |
+-------------------------------------+Core Technology Foundation
Architectural Rationale & Trade-Offs
Evaluating failure modes, scaling bottlenecks, and defensive engineering decisions.
Why PostgreSQL over DynamoDB or separate per-tenant databases?
Separate databases per tenant creates operational paralysis: migrating 500 databases during a schema update takes hours, breaks CI/CD, and skyrockets RDS instance costs. DynamoDB forces non-relational query design that destroys product flexibility. PostgreSQL with native Row-Level Security (RLS) offers the exact sweet spot: relational queries, ACID guarantees, instant migrations, and kernel-level data isolation.
Why this tenancy model?
Shared database with row-level tenant partitioning via `org_id`. Before executing any query, the database connection executes `SET LOCAL app.current_tenant_id = :orgId;`. Database policies reject any read or write where `tenant_id != current_setting('app.current_tenant_id')`. Even if application code has a bug or SQL injection vulnerability, data leakage across tenants is mathematically prevented at the database kernel.
Where does caching live?
Multi-layer caching: static assets and marketing pages cached at the CDN Edge (Cloudflare). Dynamic tenant data cached via Redis with tenant-scoped keys (`cache:tenant_{id}:user_{uid}`). Write operations trigger deterministic tag-based invalidations. We never cache un-scoped database queries.
What happens at 10x traffic?
PostgreSQL connection exhaustion is prevented using PgBouncer in transaction-pooling mode. Heavy read endpoints (analytics, reporting dashboards) are routed to a read-replica pool. Intensive background processing (CSV exports, webhook broadcasts) is throttled through Redis queue workers so API responsiveness stays under 50ms.
What happens if a third-party API fails?
Third-party calls (Stripe, Resend, HubSpot) are NEVER executed in the synchronous request-response lifecycle. Mutations record a pending domain event in PostgreSQL. A durable queue worker executes the external call with exponential backoff and idempotency keys. If Stripe drops offline, client mutations succeed, and the worker retries gracefully.
What would I deliberately NOT build?
1) No Kubernetes clusters (Vercel or simple containerized AWS ECS instances are 10x more cost-efficient for 99% of SaaS). 2) No microservices (a clean modular monolith with strict domain boundaries eliminates network latency, distributed logging hell, and RPC sync overhead). 3) No Event Sourcing (standard transactional state with audit logs gives 100% compliance without the nightmare of event stream schema migrations).
Project Meridian: AI-Powered Sales Automation & Multi-Tenant CRM Platform
Multi-tenant architecture serving active global sales teams
You own the system.
The code. The infra. The data.
Software should not become valuable enough to matter and then be impossible for the client to own or operate.
Everything I build is 100% client-owned intellectual property from day one. You own the code, the accounts, the infrastructure, and the data. No vendor lock-in.
What belongs to you in full:
- 01Source code & Complete Git Repositories
- 02Apple, Google & Enterprise Developer Accounts
- 03Cloud Infrastructure, VPCs & Production Databases
- 04Figma Design Files, Assets & Documentation
- 05CI/CD Deployment Pipelines & Signing Keys
Have a system that needs this level of architectural rigor?
Whether you are building from zero or rescuing a fragile prototype, I provide decisive architectural leadership.
Start an Architectural Engagement