box:app:video:category:list:{categoryId} – Redis LIST of video IDs scoped by category. Readers fetch IDs (via VideoCacheHelper) and hydrate details from MongoDB; writers are the category cache builder.
box:app:video:tag:list:{categoryId}:{tagId} – Redis LIST of video IDs filtered by tag membership. Writers are the tag-filtered builder, readers reuse the same helpers as category lists when tagName filters are requested.
box:app:tag:list:{categoryId} – Redis LIST of stringified Tag metadata objects ({id,name,seq,status,categoryId,channelId,createAt,updateAt}). Only the tag metadata builder writes here; readers rely on VideoCacheHelper.getTagListForCategory for typed access.
box:app:video:recommended – Redis STRING (JSON) storing an array of RecommendedVideoItem structures produced by RecommendedVideosCacheBuilder and consumed by VideoService.getRecommendedVideos.
box:app:video:payload:{videoId} – Redis STRING (JSON) intended to hold a minimal VideoMedia payload with exactly these fields: id, title, coverImg, coverImgNew, videoTime, country, firstTag, secondTags, preFileName, desc, size, updatedAt, filename, fieldNameFs, ext. size remains a BigInt serialized via RedisService.setJson. This key mirrors the detail cache but keeps the payload minimal, and caches should only include active videos sourced from the latest Mongo data.
Value types & TTL
Category/tag lists: Redis LIST of Mongo ObjectId strings. No TTL is set (lists persist until the next rebuild).
Tag metadata lists: Redis LIST of JSON strings; TTL is unset so the data lives until the next rebuild.
Recommended videos: JSON array stored via RedisService.setJson with a 1-hour TTL (RecommendedVideosCacheBuilder.CACHE_TTL).
Payload key: JSON string stored via RedisService.setJson. TTL stays in sync with the builder that writes it (none by default, but can be added when the payload writer is implemented).
Migration & hygiene
All helpers that read video lists or tag metadata go through VideoCacheHelper, which attempts the canonical key (app:...) and falls back once to the legacy double-prefixed form (box:app:...) before logging a warning.
Admin/developer endpoints now only delete canonical patterns (app:...) and also sweep legacy box:app:... keys so old double-prefixed data can be removed after the new prefixes are safely draining.
New constants in CacheKeys/tsCacheKeys expose appVideoPayloadKey(videoId) so builders/services can stay aligned with the spec while Redis’ configured box: prefix is always applied exactly once.
