MERN Stack at Scale: How We Handle 10,000+ Concurrent Users with Multi-Tenant Architecture
Real-world lessons from building 40+ SaaS products. JWT auth, tenant isolation, Stripe billing, and MongoDB sharding strategies that actually work.
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.
Planning something like this?
We map the database, APIs, stack, and budget before a line of code is written - and the fee is credited against your build if you go ahead with us within 60 days.