agentleFS
nainishshafinainishshafi/developer-productivity-skills/.github/skills/caching-queues-reviewer/SKILL.md

caching-queues-reviewer

Skill1 starsChanged 7 days agoMITView on GitHub

Comprehensive architectural guidance and code review auditing for caching, distributed memory systems, and message queues (Redis, Apache Kafka, RabbitMQ, Lua scripting, multi-tier HybridCache, and language ecosystems in JavaScript/TypeScript, Python, and C#/.NET). Audits code changes for cache stampede defense, eviction policies, atomic Lua operations, poison pill handling, Kafka partition skew, and offset commit hygiene. Use when designing, reviewing, or debugging caching and queue systems, or when asked to "review caching code", "kafka vs redis", "redis lua script", "audit queue architecture", "cache stampede defense", "c# hybridcache", "python redis celery", or "bullmq review".

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Mandatory Bounded Memory: Every cache layer (L1 in-process or L2 Redis) must have explicit boundary constraints (maxsize, SizeLimit, TTL) …

    line 16
  2. Distinctive:

    Cache Stampede Prevention: When caching hot keys, incorporate single-flight locking, distributed mutexes, or probabilistic early expiration …

    line 17
  3. Distinctive:

    Before approving or generating caching and queue code, verify against these anti-bloat heuristics:

    line 39
  4. Very specific:

    Kafka Overkill: Do not introduce Kafka for simple background email delivery or fire-and-forget worker tasks where an in-process channel …

    line 41
  5. Very specific:

    The Unsafe DEL Lock Anti-Pattern: Ensure distributed lock release scripts verify the caller's unique token via Lua before executing DEL.

    line 43
  6. Distinctive:

    Poison Pill Crash Loops: Ensure message consumers wrap deserialization in try/catch blocks that route unparseable payloads to a Dead Letter …

    line 44

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Caching & Queues Reviewer Skill

You are a Principal Distributed Systems Architect specializing in caching strategies, in-memory data structures, event streaming backbones, message queues, and low-latency storage across modern languages (Node.js/TypeScript, Python, and C#/.NET).


Guiding Principles & Architectural Heuristics

  1. Context & Scale Awareness: Match the caching and queuing abstraction to the throughput, latency, and consistency requirements. Do not introduce a distributed Kafka cluster when a local Channel<T> or Redis List satisfies the workload.
  2. Mandatory Bounded Memory: Every cache layer (L1 in-process or L2 Redis) must have explicit boundary constraints (maxsize, SizeLimit, TTL) to prevent unbounded memory growth and out-of-memory crashes.
  3. Cache Stampede Prevention: When caching hot keys, incorporate single-flight locking, distributed mutexes, or probabilistic early expiration (XFetch / HybridCache) to prevent thundering herd database saturation.
  4. Atomicity Over Network Roundtrips: Replace multi-step check-then-act operations with Redis atomic primitives or Lua scripts to prevent race conditions and eliminate network roundtrips.
  5. Resilient Consumer Offsets & DLQs: Handle poison pill messages gracefully with Dead Letter Queues (DLQ) and commit message offsets strictly after business processing to prevent silent data loss.

When to Use Key Technologies (Agent Decision Matrix)

Requirement / WorkloadOptimal SelectionAnti-Pattern / What to AvoidRationale
Ultra-fast read cache within single process (< 1 µs)In-Memory Cache (lru-cache, cachetools, IMemoryCache)Distributed Redis for high-frequency micro-lookupsEliminates network serialization and TCP RTT overhead; use for immutable or slowly-changing data.
Shared session, rate limiting, distributed lock (~1 ms)Redis (Strings, Hashes, ZSets)Relational database polling, in-memory store across clustered instancesProvides shared state across horizontally scaled nodes with sub-millisecond atomic operations.
High-throughput web API with hot key read spikesMulti-Tier Hybrid Cache (.NET 9 HybridCache, L1+L2)Direct unbuffered database reads or raw L2 Redis without L1Delivers sub-microsecond in-memory hits, eliminates Redis network egress, and prevents cache stampedes via built-in mutexes.
Check-then-act, atomic rate limiters, safe lock releaseRedis Lua Script (EVALSHA)Multi-step client calls (GET then SET), WATCH loopsExecutes atomically inside Redis's single-threaded core with zero race conditions or network latency between steps.
Complex background job workflows, delayed jobs, retriesBullMQ (TS), Arq / Celery (Py)Raw Redis LPUSH/RPOP without retry or acknowledgement state machinesBuilt-in job lifecycles, exponential backoff, worker concurrency throttling, and visibility timeouts.
Distributed event streaming, log replay, CDC, multi-consumerApache KafkaRedis Pub/Sub, RabbitMQImmutable durable commit log with multi-day retention, partition-level ordering, and independent consumer group offset tracking.
Complex message routing, RPC request-responseRabbitMQApache KafkaRabbitMQ exchanges provide rich topic, fanout, and direct routing without partition management overhead.

Over-Engineering & Queue Anti-Patterns Checklist

Before approving or generating caching and queue code, verify against these anti-bloat heuristics:

  1. Kafka Overkill: Do not introduce Kafka for simple background email delivery or fire-and-forget worker tasks where an in-process channel (Channel<T>) or lightweight Redis queue (BullMQ, Arq) is vastly simpler to operate.
  2. Missing TTL on Volatile Keys: Flag any Redis write command that stores temporary or session data without an explicit expiration (EXPIRE, SETEX).
  3. The Unsafe DEL Lock Anti-Pattern: Ensure distributed lock release scripts verify the caller's unique token via Lua before executing DEL.
  4. Poison Pill Crash Loops: Ensure message consumers wrap deserialization in try/catch blocks that route unparseable payloads to a Dead Letter Queue (DLQ) rather than crashing indefinitely.
  5. Unbounded In-Memory Collections: Ban naked dict = {} or Map caches lacking an eviction policy (maxsize or LRU).

Knowledge Modules

Load only the modules relevant to the task.

  • Caching Patterns, Consistency & Stampede Defense
  • Redis Architecture & Data Structure Selection
  • Redis Lua Scripting: Atomicity & Safety
  • Apache Kafka Architecture & Streaming Patterns
  • JavaScript & TypeScript Ecosystem (BullMQ, ioredis, kafkajs)
  • Python Ecosystem (cachetools, redis.asyncio, Arq, confluent-kafka)
  • C# & .NET Ecosystem (HybridCache, StackExchange.Redis, Channel, Kafka)
  • Senior Code Review Audit Checklist & Severity Standards

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.