perf: implement Redis caching layer for gist queries

[snowrugar-beep]

Problem Statement

Redis infrastructure is defined in Terraform (ElastiCache parameter group with redis7 and allkeys-lru eviction policy) but no caching logic is implemented in the application. Every gist query — including repeated spatial queries within the same radius — hits PostgreSQL directly, creating unnecessary read load.

Evidence

• infrastructure/terraform/redis-parameters.tf — Redis parameter group defined
• No Redis client or caching logic in Backend source code
• Every findNearby, findOne call hits PostgreSQL

Impact

High read load on primary database. No read load distribution. Slower response times for repeated queries.

Proposed Solution

1. Install ioredis and @nestjs/bull (or @liaoliaots/nestjs-redis) for NestJS Redis integration
2. Configure Redis connection from environment variables
3. Cache findNearby results with TTL based on query parameters (lat, lon, radius, limit)
4. Cache findOne results by gist ID with TTL
5. Invalidate cache on new gist creation
6. Add cache hit/miss metrics

Technical Requirements

• Cache key format: gist:nearby:{lat}:{lon}:{radius}:{limit}
• Cache TTL: 60 seconds for nearby, 300 seconds for single gist
• Must handle cache invalidation on new gist creation
• Must gracefully degrade if Redis is unavailable
• Must not cache paginated results incorrectly

Acceptance Criteria

1. First query misses cache, hits DB, populates cache
2. Second identical query returns from cache (no DB hit)
3. New gist creation invalidates nearby cache for that area
4. Redis unavailability does not crash the application
5. Cache hit rate is logged/metrics available
6. All existing tests pass

File Inventory

• Backend/src/gists/gists.service.ts
• Backend/src/gists/gist.repository.ts
• Backend/src/app.module.ts
• Backend/package.json

Dependencies

None.

Testing Strategy

• Unit test: service layer with mocked Redis
• Integration test: running Redis, verify cache behavior
• Performance test: compare response times with and without cache

Security Considerations

Cache should not store sensitive data. Redis should require authentication in production.

Definition of Done

• Redis client configured
• Caching logic implemented
• Cache invalidation working
• Graceful degradation on Redis failure
• Tests passing

[anonfedora]

I'd like to work on this issue because it aligns with my experience building high-performance backend systems with Redis caching.

I have experience implementing cache-aside patterns, Redis-based caching layers, cache invalidation strategies, and observability for backend services. I'm confident in adding reusable cache decorators, configuring TTL policies, implementing cache warming for hot data, and exposing Redis health metrics while keeping the architecture modular, maintainable, and easy to test.

[grantfox-oss]

🦊 GrantFox — @anonfedora 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 #25)
2. Your PR will be reviewed by the VertexChainLabs maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@anonfedora's PR #86 was approved and merged by @snowrugar-beep.

🏆 @anonfedora: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (366 total points). Track your full progress on GrantFox.

👏 Great work, @anonfedora! Keep contributing to VertexChainLabs.