Redis Caching taste — промпт для ChatGPT и Claude.ai: правила кэша
Промпт задаёт ИИ-ассистенту набор правил работы с Redis: cache-aside, TTL с джиттером, инвалидация после записи. Пригодится, когда проектируешь кэш и не хочешь забыть про stampede и утечки памяти.
Открыть на GitHubЧто делает Redis Caching taste
Это промпт-персона: набор из двух десятков правил, которые ассистент держит в голове, когда вы обсуждаете кэширование. Основной режим — cache-aside: чтение идёт из Redis, при промахе запрос уходит к источнику истины, потом значение кладётся в кэш. Кэш считается расходным материалом: если Redis очистить, система обязана остаться корректной, пусть и медленнее.
Внутри — конкретные требования. TTL на каждый ключ, плюс случайный разброс, чтобы ключи не истекали одновременно. Пространство имён вида service:entity:id:version, версия поднимается при смене формата. Инвалидация — удалением ключа после успешной записи, а не перезаписью значения на месте. Горячие ключи защищаются коротким локом через SET key value NX PX или объединением запросов. Негативные результаты кэшируются с коротким TTL.
Есть и то, что ломает продакшен. KEYS в проде запрещён, вместо него SCAN с курсором. Большие ключи и коллекции режутся, иначе одна команда блокирует Redis на миллисекунды. Пакетные чтения идут через MGET или пайплайн. Атомарная логика живёт в Lua-скрипте, а не в клиентском check-then-set. Отдельно прописаны maxmemory с явной политикой вытеснения, раздельные инстансы для кэша и долговечных данных, таймауты клиента и предохранитель, чтобы медленный Redis давал промахи, а не падение сервиса. Промпт советует не кэшировать то, что и так быстро: сначала измерьте задержку источника.
Какие задачи решает
- выбрать режим кэширования и не утонуть в вариантах
- защитить горячий ключ от одновременных промахов
- подобрать TTL и разброс, чтобы ключи не истекали разом
- разделить кэш и очереди по разным инстансам Redis
- настроить вытеснение и не потерять нужные данные
Примеры запросов агенту
- Спроектируй кэш каталога товаров на Redis: какой режим взять и как назвать ключи?
- У нас лавина запросов к одному ключу после истечения TTL — что делать?
- Проверь мой код инвалидации кэша после записи в базу
Как установить Redis Caching taste
Как использовать
Вставьте текст в начало диалога или в инструкции проекта
Вручную: положить файлы
.claude/commands/prompts.csv.mdИз того же набора73
Весь набор →Похожие
Рядом в каталоге
Всё по теме «Бэкенд и API» →Вопросы о Redis Caching taste
Как установить Redis Caching taste в Claude?
Готовой команды установки нет: промпт вставляется в чат или сохраняется как инструкция в настройках. Скопируйте текст правил и отправьте его первым сообщением.
Что делает Redis Caching taste?
Задаёт ассистенту свод правил по работе с Redis: cache-aside, TTL с джиттером, инвалидация удалением, защита от stampede, безопасность и мониторинг.
Чем этот промпт отличается от обычного вопроса про Redis?
Он держит контекст на протяжении диалога: ассистент сам напоминает про TTL, неймспейсы и запрет KEYS в проде, а не отвечает только на заданный вопрос.
Исходный текст
prompts.csv · CC0-1.0
# Redis Caching taste of a backend engineer - Default to cache-aside: read from Redis, fall back to the source of truth on a miss, then populate the cache. Confidence: 0.90 - Treat the cache as disposable; the system must stay correct (only slower) if Redis is flushed. Confidence: 0.95 - Set a TTL on every cache key; a key without an expiry is a memory leak waiting to happen. Confidence: 0.90 - Add random jitter to TTLs so keys written together do not expire together. Confidence: 0.85 - Namespace keys as service:entity:id:version (e.g. catalog:product:42:v3) and bump the version on breaking format changes. Confidence: 0.85 - Invalidate by deleting the key after a successful write, not by updating the cached value in place. Confidence: 0.80 - Protect hot keys from stampedes with a short lock (SET key value NX PX) or request coalescing. Confidence: 0.80 - Cache negative results (not found) with a short TTL to absorb lookups for missing ids. Confidence: 0.70 - Store compact serialized values (JSON for debuggability, MessagePack when size matters) and keep values under about 100 KB. Confidence: 0.75 - Use hashes for objects whose fields are read separately, and plain strings for values read whole. Confidence: 0.70 - Never run KEYS in production; use SCAN with a cursor. Confidence: 0.95 - Avoid big keys and huge collections; split anything that would make a single command block for milliseconds. Confidence: 0.85 - Use pipelining or MGET for batch reads instead of one round trip per key. Confidence: 0.85 - Put multi-step atomic logic in a Lua script or a function, not in client-side check-then-set. Confidence: 0.80 - Set maxmemory with an explicit eviction policy (allkeys-lru for pure caches, noeviction for data you must not lose). Confidence: 0.90 - Keep caches and durable data (queues, rate limits, sessions) in separate Redis instances with separate policies. Confidence: 0.80 - Use Redis Streams or a real broker for jobs; plain lists lose work when a consumer crashes. Confidence: 0.70 - Implement rate limiting with a sliding window or token bucket script, not with ad-hoc INCR plus EXPIRE races. Confidence: 0.75 - Set client timeouts and a circuit breaker so a slow Redis degrades to cache misses instead of taking the service down. Confidence: 0.90 - Monitor hit ratio, evictions, memory fragmentation and latency, and alert on a falling hit ratio. Confidence: 0.85 - Require auth and TLS, disable or rename dangerous commands (FLUSHALL, CONFIG), and never expose Redis to the internet. Confidence: 0.95 - Do not cache what is already fast; measure the source latency before adding a cache layer. Confidence: 0.80
© f · CC0-1.0 · f/prompts.chat
