Why choose MongoDB sharding over read replicas?

Write throughput was the bottleneck (5K ops/sec). Sharding increased write capacity 10x.

What was the biggest frontend improvement?

Virtualized lists for dashboard tables reduced DOM nodes from 10,000 to 50.

How does this case study work?

Raise a request, talk to experts, fund the project, expert works, review and approve payment. All remote, all through our platform.

Scaling SaaS Platforms with MERN

Executive Summary

A B2B SaaS startup's MERN stack application collapsed at 5,000 users due to database bottlenecks and unoptimized React rendering. MERN developers implemented horizontal sharding in MongoDB, added Redis caching, and optimized component rendering, scaling to 50,000 users with 150ms API latency.

Key Outcomes

▹ 100 → 50,000 users (500x scale)
▹ API latency reduced 400ms → 150ms
▹ Infrastructure cost per user reduced 80%

Client Situation

The startup's user base grew 10x in 6 months, but the platform became unusable during peak hours with timeouts and slow dashboard loads.

Key Challenges

⚠ Database queries taking 2+ seconds on collections with 10M documents
⚠ React re-rendering entire dashboard on every user action
⚠ No horizontal scaling strategy for MongoDB

Existing Architecture

Single MongoDB replica set, Express REST API, React with Redux, deployed on 5 EC2 instances.

Single write node bottleneck at 5K writes/sec
No database indexing strategy
React components re-rendering unnecessarily

Solution Design

MongoDB sharding, Redis caching layer, React memoization, and CDN for static assets.

Key Decisions

✓ Shard MongoDB by tenant ID (50 shards)
✓ Redis cache for session data and API responses
✓ React.memo and useCallback to prevent re-renders

MongoDBRedisReactNode.jsAWS CDN

Implementation

Phased rollout: database scaling first, then backend caching, finally frontend optimization.

Phase 1: Phase 1: MongoDB Sharding
Sharded 100M documents across 50 nodes—write throughput 5K → 50K ops/sec.
Phase 2: Phase 2: Redis Caching
Cached user sessions and dashboard aggregates—API latency 400ms → 200ms.
Phase 3: Phase 3: React Optimization
Memoized components and code splitting—time-to-interactive 3s → 1.2s.

Technical Challenges

Cross-shard query performance

Impact: Queries without tenant ID scanned all 50 shards (5s latency)

Resolution: Enforced tenant ID in all queries + compound shard key

Real-time updates with Redis cache

Impact: Stale dashboard data after updates

Resolution: Cache invalidation via pub/sub on write operations

Results

Maximum concurrent users: Before5,000
After50,000
Improvement10x increase
API P99 latency: Before400ms
After150ms
Improvement63% reduction
Time-to-interactive: Before3 seconds
After1.2 seconds
Improvement60% reduction

Lessons Learned

📘 Sharding by tenant ID was essential for multi-tenant SaaS
📘 Redis caching reduced database load by 70%
📘 React.memo on list items prevented 90% of re-renders

What We Would Do Differently

💡 Implement database connection pooling earlier
💡 Use Next.js for server-side rendering of dashboards

Role Relevance

MERN developers scaled the full stack—database, backend, and frontend—enabling 500x user growth without rewrites.

Critical Skills Demonstrated

MongoDB shardingRedis cachingReact performanceHorizontal scaling

Frequently Asked Questions

Why choose MongoDB sharding over read replicas?: Write throughput was the bottleneck (5K ops/sec). Sharding increased write capacity 10x.
What was the biggest frontend improvement?: Virtualized lists for dashboard tables reduced DOM nodes from 10,000 to 50.