メニュー
Design and implement caching strategies across all layers — in-memory, distributed (Redis/Memcached), CDN, HTTP cache headers, and application-level memoization
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/InugamiDev/ultrathink-oss --skill cachingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Unified design foundations — design system architecture, tokens, component specs, visual principles, creative vision, figma integration, plus brand design system loader (66 real brands via DESIGN.md). Absorbs design, design-system, design-systems, design-principles, design-router, creative-vision, figma, design-md.
Render, summarize, and present markdown documents and structured content in multiple output modes
Ultra UI skill - combines Google's DESIGN.md spec (machine-readable design tokens) with the ui-ux-pro-max knowledge base (91 styles, 161 palettes, 73 font pairings, 161 products, 104 UX guidelines, 25 chart types). Generates lint-clean DESIGN.md files, validates token references and WCAG contrast, exports Tailwind/DTCG tokens, and diffs design systems version-over-version.
| name | caching |
| description | Design and implement caching strategies across all layers — in-memory, distributed (Redis/Memcached), CDN, HTTP cache headers, and application-level memoization |
| layer | utility |
| category | performance |
| triggers | ["cache this","add caching","caching strategy","redis cache","CDN caching","HTTP cache headers","memoize","cache invalidation"] |
| inputs | ["Resource or endpoint to cache","Current latency or load characteristics","Data freshness requirements (real-time, near-real-time, stale-ok)","Infrastructure available (Redis, Memcached, CDN provider, edge)"] |
| outputs | ["Caching strategy document with layer recommendations","Implementation code for chosen cache layer(s)","Cache invalidation plan","TTL and eviction policy recommendations","Monitoring and hit-rate tracking guidance"] |
| linksTo | ["api-designer","data-modeling","performance-profiler"] |
| linkedFrom | ["optimize","ship"] |
| preferredNextSkills | ["performance-profiler","testing-patterns"] |
| fallbackSkills | ["optimize"] |
| riskLevel | low |
| memoryReadPolicy | selective |
| memoryWritePolicy | selective |
| sideEffects | ["May add Redis or cache dependencies to project","May modify HTTP response headers","May add middleware or proxy configuration"] |
Caching is the single highest-ROI performance optimization in most systems. This skill designs multi-layer caching strategies, implements them correctly, and — critically — plans cache invalidation so stale data does not become a silent bug.
[Browser Cache] ← HTTP headers, Service Worker
[CDN / Edge] ← Vercel Edge, Cloudflare, Fastly
[Reverse Proxy] ← Nginx, Varnish
[Application Cache] ← In-memory (LRU), Redis, Memcached
[Database Query Cache] ← Materialized views, query result cache
[Source of Truth (DB/API)] ← Always correct, slowest
| Strategy | TTL | Invalidation | Best For |
|---|---|---|---|
| Write-through | N/A | On write | Consistency-critical data |
| Write-behind | N/A | Async after write | High write throughput |
| Cache-aside (Lazy) | Time-based | TTL expiry + manual | Read-heavy, tolerance for staleness |
| Read-through | Time-based | TTL expiry | Transparent to caller |
| Refresh-ahead | Time-based | Pre-emptive refresh | Predictable access patterns |
Never cache blindly. Identify:
Latency Budget Analysis:
Target: < 200ms p95
Current: 850ms p95
Breakdown:
DB query: 600ms (cacheable — read:write = 50:1)
API call: 200ms (cacheable — changes hourly)
Compute: 50ms (memoizable — pure function)
Decision Matrix:
Is it static content (images, JS, CSS)?
→ CDN + immutable cache headers
Is it per-user, session-scoped?
→ In-memory (server) or browser cache
Is it shared across users, read-heavy?
→ Redis / Memcached with cache-aside
Is it an expensive pure computation?
→ Memoization (in-process LRU)
Is it an API response with known TTL?
→ HTTP Cache-Control headers + stale-while-revalidate
// Next.js API route or middleware
export function GET(request: Request) {
const data = await fetchData();
return Response.json(data, {
headers: {
// Public: CDN can cache. max-age: browser TTL. s-maxage: CDN TTL.
'Cache-Control': 'public, max-age=60, s-maxage=300, stale-while-revalidate=600',
// Vary ensures different cached versions per relevant header
'Vary': 'Accept-Encoding, Authorization',
},
});
}
Cache-Control Cheat Sheet:
| Directive | Meaning |
|---|---|
public | Any cache (CDN, proxy) may store |
private | Only browser may store |
no-cache | Must revalidate before use (NOT "don't cache") |
no-store | Truly never cache |
max-age=N | Fresh for N seconds (browser) |
s-maxage=N | Fresh for N seconds (shared/CDN cache) |
stale-while-revalidate=N | Serve stale for N seconds while refreshing in background |
immutable | Never changes (use with hashed filenames) |
import { Redis } from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);
interface CacheOptions {
ttl: number; // seconds
prefix?: string;
serialize?: (v: unknown) => string;
deserialize?: (v: string) => unknown;
}
async function cacheAside<T>(
key: string,
fetcher: () => Promise<T>,
options: CacheOptions
): Promise<T> {
const fullKey = options.prefix ? `${options.prefix}:${key}` : key;
const serialize = options.serialize ?? JSON.stringify;
const deserialize = options.deserialize ?? JSON.parse;
// 1. Try cache
const cached = await redis.get(fullKey);
if (cached !== null) {
return deserialize(cached) as T;
}
// 2. Cache miss — fetch from source
const data = await fetcher();
// 3. Write to cache (don't await — fire and forget for speed)
redis.setex(fullKey, options.ttl, serialize(data)).catch((err) => {
console.error(`Cache write failed for ${fullKey}:`, err);
});
return data;
}
// Usage
const user = await cacheAside(
`user:${userId}`,
() => db.user.findUnique({ where: { id: userId } }),
{ ttl: 300, prefix: 'app' }
);
class LRUCache<K, V> {
private cache = new Map<K, V>();
constructor(private maxSize: number) {}
get(key: K): V | undefined {
const value = this.cache.get(key);
if (value !== undefined) {
// Move to end (most recently used)
this.cache.delete(key);
this.cache.set(key, value);
}
return value;
}
set(key: K, value: V): void {
if (this.cache.has(key)) {
this.cache.delete(key);
} else if (this.cache.size >= this.maxSize) {
// Evict least recently used (first entry)
const firstKey = this.cache.keys().next().value;
this.cache.delete(firstKey);
}
this.cache.set(key, value);
}
}
// For production, use `lru-cache` package instead of rolling your own
// next.config.js — static asset caching
const nextConfig = {
headers: async () => [
{
source: '/_next/static/:path*',
headers: [
{ key: 'Cache-Control', value: 'public, max-age=31536000, immutable' },
],
},
],
};
// ISR (Incremental Static Regeneration)
export const revalidate = 60; // Revalidate every 60 seconds
// On-demand revalidation
import { revalidateTag } from 'next/cache';
export async function POST(request: Request) {
revalidateTag('posts');
return Response.json({ revalidated: true });
}
Pattern: Event-Driven Invalidation
// After a write operation, invalidate related cache keys
async function updateUser(userId: string, data: UpdateUserData) {
const updated = await db.user.update({ where: { id: userId }, data });
// Invalidate all cache keys related to this user
const keysToInvalidate = [
`app:user:${userId}`,
`app:user-profile:${userId}`,
`app:user-posts:${userId}`,
];
await Promise.all(keysToInvalidate.map((key) => redis.del(key)));
// If using tag-based invalidation (Next.js)
revalidateTag(`user-${userId}`);
return updated;
}
Pattern: Versioned Keys
// Instead of invalidating, bump a version
const version = await redis.incr(`version:user:${userId}`);
const cacheKey = `user:${userId}:v${version}`;
// Old versions naturally expire via TTL
Key metrics to track:
// Simple hit/miss tracking
let hits = 0, misses = 0;
async function cachedFetch<T>(key: string, fetcher: () => Promise<T>): Promise<T> {
const cached = await redis.get(key);
if (cached) {
hits++;
return JSON.parse(cached);
}
misses++;
const data = await fetcher();
await redis.setex(key, 300, JSON.stringify(data));
return data;
}
// Expose metrics endpoint
function getCacheStats() {
const total = hits + misses;
return {
hits,
misses,
hitRate: total > 0 ? (hits / total * 100).toFixed(1) + '%' : 'N/A',
};
}
SETNX) or stale-while-revalidate.Layer 1: CDN (Vercel Edge) — Cache full HTML for 60s, stale-while-revalidate 300s
Layer 2: Redis — Cache product data for 5 min, invalidate on admin update
Layer 3: DB query cache — Materialized view for price calculations, refresh every minute
Invalidation: Webhook from CMS triggers revalidateTag('product-{id}')
Layer 1: Browser — Cache-Control: private, max-age=0, must-revalidate (no shared cache)
Layer 2: Redis — Cache per-user dashboard data for 30s
Layer 3: In-memory — LRU cache for user preferences (small, rarely changes)
Invalidation: Write-through on user action, TTL expiry for background data
Layer 1: CDN — Cache GET responses for 10s with Vary: Authorization
Layer 2: Redis — Cache API responses per unique query hash for 60s
Rate limit: Use Redis INCR with TTL for sliding window rate limiting
Invalidation: Short TTLs only — no explicit invalidation needed