Implement Caching Strategy for Frequently Accessed Data

[grantfox-oss]

Priority: Medium
Files: New cache module + relevant services
Description:

• Add caching support using @nestjs/cache-manager
• Implement caching for frequently accessed data (e.g., user profiles, posts)
• Configure cache TTLs appropriately
• Support multiple cache stores (in-memory, Redis)
  Acceptance Criteria:
• Caching is implemented
• Performance improvements are measurable
• Cache invalidation works correctly

---

[Tobi-8]

hey maintainer, allow me to work on this

[Glam26]

I'd like to work on this issue.

My proposed implementation plan:

• Create a dedicated cache module using @nestjs/cache-manager that can support both in-memory caching for local development and Redis-backed caching for production deployments.

• Audit the existing services to identify high-read, low-write data that would benefit most from caching (e.g. user profiles, posts, public lookups, and dashboard summary queries).

• Introduce cache keys with clear naming conventions and configurable TTLs based on data volatility:

  • User profiles: longer TTL
  • Posts and feeds: moderate TTL
  • Frequently updated entities: shorter TTL

• Implement cache invalidation on create, update, and delete operations to prevent stale data from being served.

• Make cache configuration environment-driven so deployments can switch between memory and Redis without code changes.

• Add tests covering:

  • Cache hit/miss behavior
  • Cache invalidation after updates
  • TTL expiration
  • Redis and memory store compatibility where applicable

• Include before/after performance measurements for the targeted endpoints and document the caching strategy in the PR.

This approach should improve response times for frequently accessed resources while keeping data consistency guarantees through explicit invalidation logic.

[MoscowDev]

I'd like to work on this issue.

Before implementing caching, I'll review the application's read/write patterns to identify high-value cache candidates and define clear invalidation rules. My goal is to improve response times without introducing stale-data issues or tightly coupling services to a specific cache backend.

My implementation plan is to:

• Add a centralized cache module using @nestjs/cache-manager.
• Support both in-memory and Redis-backed stores through configuration.
• Introduce cache abstractions for frequently accessed resources such as user profiles and posts.
• Define cache TTLs based on data volatility rather than using a single global timeout.
• Implement explicit cache invalidation on create/update/delete operations.
• Add metrics and benchmarks to demonstrate measurable performance improvements.
• Include tests covering cache hits, misses, expiration, and invalidation behavior.

I'll keep the implementation modular, so additional services can adopt caching consistently in the future.

[Babigdk]

I’d like to work on this by adding caching using @nestjs/cache-manager.

I will introduce a cache module and apply caching to frequently accessed data like user profiles and posts to reduce database load and improve response times.

The setup will support both in-memory caching for development and Redis for production, with configurable TTLs depending on how often the data changes.

I’ll also ensure proper cache invalidation when data is updated, created, or deleted so we don’t serve stale data.

Finally, I’ll verify performance improvements and ensure the caching behavior is consistent and measurable.

[nikkybel]

Please can I be assigned this issue?

[Senorespecial]

I would love to work on this issue, please assign the issues to me so i Can work on it ASAP

[DTriple-p]

Hi there, I'll like to work on this issue.

[grantfox-oss]

🦊 GrantFox — @Babigdk has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #477)
2. Your PR will be reviewed by the MERIDIAN-CITY maintainers

Good luck! Track your progress on GrantFox.