cache

Implement read-through caching with getOrSet and environment-driven providers.

Updated May 7, 2026

Search Tags:#testing #caching #monorepo #invalidation #Upstash #read-through #getOrSet

Ready to run

npx skills add https://github.com/johinsDev/loyalty-app --skill cache-johinsdev

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: cache
Source: https://github.com/johinsDev/loyalty-app/tree/main/.claude/skills/cache
Command: npx skills add https://github.com/johinsDev/loyalty-app --skill cache-johinsdev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you prevent repeated database work and avoid stale data by providing a consistent read-through cache pattern for the loyalty-app monorepo.

Core Features & Use Cases

Read-through caching with getOrSet: Cache the result of an async factory and automatically reuse it on cache hits.
Environment-aware provider strategy: Select a cache provider by runtime (memory for local dev; Upstash for Vercel preview/production), with overrides for special cases.
Safe invalidation after writes: Delete the right cache keys after repository updates to ensure subsequent reads reflect the latest state.
Test support with FakeStore: Fake the cache to seed deterministic values and assert presence/absence without hitting networked providers.

Quick Start

Use the cache skill to read-through a customer lookup by running: cache.getOrSet for the key customer:<id> with a factory that fetches the customer and a TTL in seconds.

Frequently Asked Questions about cache

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I implement read-through caching to prevent stale database reads?▼

Read-through caching prevents stale reads by using a getOrSet pattern to fetch data from an async factory on a cache miss, then reusing the cached result until the TTL expires or the key is invalidated after repository writes.

How does cache invalidation work after database writes?▼

Cache invalidation after writes works by explicitly deleting the affected cache keys following repository updates, ensuring that subsequent read-through requests fetch the latest state from the database instead of returning stale data.

Can I use different cache providers for local development and production environments?▼

You can select cache providers per environment using environment-driven configuration, typically choosing an in-memory store for local development and Upstash or Redis for Vercel preview and production deployments.

What is the best way to test caching logic without hitting networked providers?▼

The best way to test caching logic without network calls is using a FakeStore to seed deterministic cache values, allowing you to assert key presence or absence and verify getOrSet miss semantics safely.

Does read-through caching require JSON serialization for cached values?▼

Read-through caching requires JSON serialization on both read and write operations to ensure cached values are stored and retrieved consistently across different cache providers.

When should I use getOrSet semantics for caching derived query results?▼

You should use getOrSet semantics for caching derived query results when you want to automatically execute an async factory to fetch data on a cache miss and reuse the stored result for subsequent hits until invalidation.