Why Multi-Tenant Architecture Is the Default for SaaS

After building 40+ SaaS products at Webneco, we've settled on multi-tenant architecture as our default approach. It's not just about cost efficiency — it's about operational simplicity, faster deployments, and the ability to scale without multiplying infrastructure headaches.

In this article, we share the exact patterns, code structures, and infrastructure decisions that allow us to serve 10,000+ concurrent users across multiple tenants on a single MERN stack deployment.

Tenant Isolation: The Foundation

The first and most critical decision is how you isolate tenant data. We use a shared database, shared schema approach with tenant IDs on every document. This gives us the best balance of cost efficiency and operational simplicity.

MongoDB Schema Design

Every collection includes a tenantId field indexed for fast lookups. We enforce tenant isolation at the middleware level — every database query automatically includes the tenant context from the authenticated user's JWT token.

For sensitive data like billing information and API keys, we use field-level encryption with tenant-specific encryption keys stored in AWS KMS.

JWT Authentication with Tenant Context

Our JWT tokens carry three critical pieces of information: userId, tenantId, and role. The middleware extracts this context and attaches it to every request, ensuring queries are always scoped to the correct tenant.

Handling 10K+ Concurrent Connections

Node.js's event-driven architecture handles concurrency well, but at 10K+ connections, you need deliberate optimization:

  • Connection pooling: We use a shared MongoDB connection pool with a max of 100 connections per server instance
  • Redis caching: Frequently accessed data (user profiles, feature flags, tenant configs) is cached in Redis with tenant-scoped keys
  • Rate limiting: Per-tenant rate limits prevent any single tenant from monopolizing resources
  • Horizontal scaling: PM2 cluster mode across 4 cores, behind an NGINX load balancer with sticky sessions

Stripe Billing Integration

Each tenant maps to a Stripe customer. We use Stripe's subscription API with metered billing for usage-based features. Webhook handlers process subscription changes, failed payments, and plan upgrades in real-time, updating tenant configurations instantly.

MongoDB Sharding Strategy

Once our data exceeded 500GB, we implemented sharding using tenantId as the shard key. This ensures all data for a single tenant lives on the same shard, preventing cross-shard queries and maintaining query performance.

Performance Metrics

  • API response time p95: 120ms
  • Database query time p95: 45ms
  • Uptime: 99.97% over the last 12 months
  • Zero data isolation breaches across 200+ tenants

The Bottom Line

Multi-tenant MERN architecture isn't just about serving many customers from one codebase — it's about building a foundation that scales with your business. The patterns we've shared here have been battle-tested across 40+ products and millions of API requests.