Caching in Communication
Redis caching coverage, TTL, cache key scope, and invalidation rules for Communication mobile reads.
Caching in Communication
Audience: Backend developers, frontend developers, QA Scope: Redis-backed caching for Communication mobile read APIs
Overview
Communication now caches the highest-read mobile endpoints in Redis for 30 minutes.
The goals are:
- reduce repeated DB reads for posts and discussion threads
- keep user-specific access checks safe
- invalidate precisely after writes so clients do not read stale content for long
The cache is implemented in:
TTL
| Setting | Value |
|---|---|
| Cache TTL | 30 minutes |
| TTL in code | 1800 seconds |
Cached Endpoints
| Endpoint | What is cached | Cache key scope | TTL |
|---|---|---|---|
GET /api/mobile/channels/:channelId/posts | Channel post page response | channelId + userId + cursor + limit + access-decision fingerprint | 30 min |
GET /api/mobile/posts/:postId | Single post detail | postId + userId + access-decision fingerprint | 30 min |
GET /api/mobile/channels/:channelId/discussion | Discussion detail | channelId + userId | 30 min |
GET /api/mobile/channels/:channelId/discussion/messages | Discussion message page | channelId + userId + beforeSeq + limit + view | 30 min |
Why Post Caches Are Access-Aware
Channel post reads are not globally cacheable because they depend on:
- current channel access decision
- read windows from entitlement history
- post-level visibility filtering
So the post cache key includes an access-decision fingerprint.
That fingerprint is derived from:
modearchiveUntilreadWindowsreasonCode
This prevents one user’s or one access window’s cached result from being reused incorrectly for another decision state.
Invalidation Rules
| Cached endpoint | Invalidated by |
|---|---|
GET /api/mobile/channels/:channelId/posts | Post create, update, pin/unpin, soft delete, restore, replace post visibility rules |
GET /api/mobile/posts/:postId | Post create, update, pin/unpin, soft delete, restore, replace post visibility rules |
GET /api/mobile/channels/:channelId/discussion | Discussion create, discussion update, discussion message create/update/delete/restore, slow mode update |
GET /api/mobile/channels/:channelId/discussion/messages | Discussion message create/update/delete/restore, discussion create/update, slow mode update |
Invalidation Source Files
Post Cache Invalidation
Discussion Cache Invalidation
- discussions-admin.service.ts
- messages-admin.service.ts
- moderation-admin.service.ts
- discussions-mobile.service.ts
- messages-mobile.service.ts
Read-Path Integration
These mobile read services now use Redis cache reads:
The shared provider is exported from:
Staleness Strategy
Communication does not rely only on TTL expiry.
Instead:
- reads are cached for up to 30 minutes
- writes actively invalidate the affected read-model caches
- TTL acts as a fallback safety net, not the only freshness mechanism
This keeps the system:
- fast for repeated reads
- safe after writes
- easier to reason about during QA
Important Notes
- Channel list and channel detail are not part of this cache layer yet.
- Post caches are user-scoped and access-aware.
- Discussion caches are user-scoped.
- Invalidation uses pattern-based clearing for the affected post or channel scope.
Summary
Communication caching currently targets:
- channel post list
- post detail
- discussion detail
- discussion message list
with:
30 minute TTL- user-scoped cache keys
- access-aware post cache keys
- write-time invalidation to minimize stale reads