01. The caching challenge: performance without Redis.
Typically, when dealing with dashboards aggregating data for tens of thousands of users across distinct branches, engineers default to adding a Redis caching layer to handle high query load. However, due to budget and deployment infrastructure restrictions, we set out to build this using optimized indexing, query pipelines, and structured database separation instead.
This decision forced us to think deeply about MongoDB aggregation performance and avoid lazily hiding unoptimized queries behind memory caches.
02. Schema indexing & aggregation pipelines.
Instead of querying raw tables on every request, we leveraged compound indexing and MongoDB aggregation pipelines to pre-compute branch-level metrics. By indexing fields like branchId, status, and examDate together, the database could resolve dashboard aggregates in milliseconds directly from RAM.
This choice proved that well-modeled data schemas can sustain high concurrency levels. It avoids the maintenance overhead, cache-invalidation bugs, and hosting costs of an in-memory caching daemon like Redis.
03. Isolation via custom API gateway protocols.
The system ensures smooth performance without needing Redis for caching! The two backends communicate via a robust API structure, enabling seamless data flow and high concurrency handling. By separating database connection scopes, structuring aggregated lookups, and leveraging compound indexing in MongoDB, we kept response latencies under 60ms even during peak exam hours.
This separation makes the dashboard modular: if the admin panel experiences high load, the student portal remains entirely unaffected.
04. Real-world latency & reliability results.
During mid-term exam weeks, the platform handled concurrent dashboard requests from thousands of students and administrative staffs simultaneously. With index queries running in under 12ms and page renders completing in under 45ms, the client saved thousands in infrastructure scaling costs while maintaining zero downtime.