Nestjs caching queues

Skill dkmqflx/nestjs-best-practices-plugin/plugins/nestjs-best-practices/skills/nestjs-caching-queues

Claude Code plugin: 12 NestJS best-practice skills (90 rules) grounded in the official NestJS docs

Install

npx -y skills add dkmqflx/nestjs-best-practices-plugin --skill nestjs-caching-queues

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

NestJS caching and background-job queue best practices. Use when adding caching or async job processing to NestJS — CacheModule, cache-manager, Redis, or BullMQ/Bull queues. Triggers on CacheModule, @InjectQueue, @Processor, cache TTL, or background jobs.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.1 KB, as published. Nobody here has run it

NestJS Caching & Queues

Best practices for two related NestJS performance techniques: caching (@nestjs/cache-manager, backed by Keyv/Redis) and background-job queues (@nestjs/bullmq, backed by Redis). Caching avoids recomputing or re-fetching hot data; queues move slow or unreliable work off the request path so HTTP responses stay fast. Both are Redis-backed in production and share the same core concern: predictable behavior under load and failure.

Verified against the NestJS v10/v11 docs (techniques/caching, techniques/queues). Note the units gotcha: cache TTLs are in milliseconds since @nestjs/cache-manager v2 / cache-manager v5+.

When to Apply

Reference these rules when:

Registering CacheModule or injecting CACHE_MANAGER / using CacheInterceptor
Choosing a cache store (in-memory dev vs. Redis prod via @keyv/redis)
Setting or debugging cache TTLs and cache invalidation
Deciding whether work belongs inline or in a queue (email, image/video processing, external API calls)
Wiring BullModule, @InjectQueue, or a @Processor consumer
Configuring retries/backoff, or scaling workers as a separate deployment

Rules

Rule	Impact	Topic
`cache-module-setup`	HIGH	Register `CacheModule` globally; in-memory for dev, Redis for prod
`set-sensible-ttl`	HIGH	Always set a TTL (in ms); never leave caches unbounded
`cache-keys-explicit`	HIGH	Deterministic, namespaced keys; invalidate on writes
`offload-heavy-work-to-queues`	CRITICAL	Move slow/external work off the request path into a queue
`idempotent-processors`	CRITICAL	Processors must tolerate retries and duplicate deliveries
`retries-and-backoff`	HIGH	Configure `attempts` + exponential `backoff` for transient failures
`separate-worker-process`	MEDIUM	Run consumers as a separate process/deployment for scaling & isolation

How to Use

Caching first. Start with cache-module-setup, then apply set-sensible-ttl and cache-keys-explicit to every cached value — a cache without a TTL or an invalidation story is a correctness bug, not just a performance one.
Queues for anything slow or flaky. Apply offload-heavy-work-to-queues to decide what to enqueue, then idempotent-processors and retries-and-backoff to make the consumer safe to re-run. These two are CRITICAL: BullMQ retries and at-least-once delivery mean a non-idempotent processor will double-charge, double-send, or corrupt data.
Scale out. Apply separate-worker-process when CPU-bound jobs threaten the event loop or you need to scale producers and consumers independently.

Each rule file shows an Incorrect and Correct example. Prefer BullMQ (@nestjs/bullmq) for new projects; Bull (@nestjs/bull) is in maintenance mode.