perf(core): implement multi-level LRU caching for expensive computations and data retrieval (fixes #210)

[Diwakar-odds]

Summary

This PR implements an LRU (Least Recently Used) caching strategy across the core data-retrieval layers of the backend, specifically targeting high-latency reporting and high-frequency dashboard queries.

Motivation

Closes #210
The system was performing full database queries for every request to generateReportCard (which sequentially queries User, Course, Submissions with populated relationships, and Attendance docs) and getDashboardStats (which issues three concurrent countDocuments operations). This lack of caching caused slow response times and redundant DB processing. By implementing an LRU cache with TTL limits and invalidation hooks, we significantly drop the aggregate query load on the database.

Changes

• backend/utils/cache.js:
  • Implemented CacheInterface and an in-memory LRUCache class that handles capacity-based eviction and configurable TTL (Time-To-Live).
• backend/utils/cache.test.js:
  • Added full test coverage ensuring set(), get(), LRU reordering, automatic eviction, TTL limits, and manual invalidate() operations behave correctly.
• backend/controllers/reportController.js:
  • Intercepted the 4 expensive data fetching routines in generateReportCard with memoryCache.get(). Results are cached dynamically per student for 5 minutes.
• backend/controllers/teacherController.js:
  • Cached the multi-collection lookup in getDashboardStats for 1 minute.
  • Bound the caching system to modifying operations (postNotice, deleteNotice, uploadResource, deleteResource, markAttendance) using memoryCache.invalidate() so that any mutation immediately clears stale cached statistics.

Acceptance Criteria

• Implement a generic Caching Interface (with .get(), .set(), .invalidate()).
• Provide an in-memory LRU cache implementation of this interface.
• Integrate the cache into a known high-latency or high-frequency read path.
• Add tests to ensure cache hits/misses function correctly and TTL is respected.

Impact & Side Effects

• Massively reduces time complexity overhead on the /reports and /teacher/stats endpoints.
• No breaking changes or regressions.

How to Test

1. Run node backend/utils/cache.test.js to verify caching mechanics execute smoothly.
2. Load the Teacher Dashboard or generate a Report Card twice consecutively. Observe via local logging or DB performance hooks that the underlying queries are only executed once per TTL cycle.

[Diwakar-odds]

Hi maintainers, could you please review this PR?

Technical Analysis for ECSoC26 Labeling:

This PR implements Core/Architecture optimization by introducing a generic \LRUCache\ interface and integrating it across two primary data retrieval bottlenecks (Teacher Dashboard and Report Card Generation). By intercepting concurrent \countDocuments\ operations and heavy sequential MongoDB aggregations (User, Course, Submission trees, and Attendances), we significantly reduce database load and algorithmic latency.

Since this involves core backend logic changes, performance optimization through caching layers, and reducing algorithmic complexity overhead on hot computational paths, it aligns perfectly with the Level 3 criteria.

Could you please assign the \ECSoC26\ label along with \Level 3\ and \good-backend\ tags? Thank you!