node-cache

node-cache is an in-process key-value cache for Node.js that stores everything in a single in-memory object, giving set, get, mset, and del methods along with per-key or global TTL (time-to-live) expiration. It behaves conceptually like memcached but runs entirely inside the Node.js process, so there’s no separate cache server to run or network hop to pay for.

The cache supports both cloned and reference-based storage of values (useClones), an expired event for handling keys as they time out, an optional key-count limit, and a legacy callback-based API for older codebases migrating from earlier major versions. The project has publicly declared it will not be sold or handed to a new maintainer, and while it is described by its own maintainers as effectively unmaintained, it remains one of the most widely depended-on caching primitives in the npm ecosystem.

What You Get

• A NodeCache class with set, get, mget, mset, del, take, and has methods
• Per-key or global stdTTL expiration with a configurable background checkperiod sweep
• An expired event emitted when a key times out, so consumers can react before/after deletion
• useClones option to choose between deep-cloned values (safety) or stored references (performance)
• A maxKeys limit to cap total cache size and reject new keys once full
• An optional legacy callback-based API (enableLegacyCallbacks) for compatibility with pre-5.x code

Common Use Cases

• Caching expensive computed values or database query results in-process for a short TTL window
• Rate-limiting or deduplication bookkeeping where a lightweight expiring key-value store is sufficient
• Memoizing API responses inside a server process without standing up Redis or memcached
• Storing session-like or short-lived state in single-instance Node.js applications and scripts

Under The Hood

Architecture: The implementation lives in _src/lib/node_cache.coffee (716 lines), a CoffeeScript source compiled to the published index.js/index.d.ts. Internally, NodeCache keeps all entries in one plain JavaScript object keyed by string, with per-entry metadata (value, ttl timestamp) attached; a periodic checkperiod timer sweeps this object to find and evict expired keys, emitting the expired event, rather than scheduling a separate timer per key — a design that trades slight expiration-timing imprecision for much lower per-key overhead at scale (the README notes a practical limit around ~1M keys given the single-object model). The clone npm dependency is used when useClones is enabled to deep-copy stored/retrieved values so callers can’t accidentally mutate cached state through a shared reference. Tech Stack: Source is CoffeeScript, compiled via a Grunt build pipeline (Gruntfile.coffee, grunt-contrib-coffee) into the published CommonJS index.js with hand-maintained TypeScript typings (index.d.ts); the only runtime dependency is clone; tests run through mocha+nyc (coverage via Coveralls) with a separate TypeScript compile step (tsc) to validate the type definitions. Code Quality: _src/test/mocha_test.coffee is a substantial 1330-line test suite covering TTL expiration, cloning behavior, multi-key operations, and the expired event, plus a dedicated typedefinition_test.ts validating the TypeScript types compile and behave as declared — a solid quality bar for the era the code was written in. The project has had effectively no commits since mid-2024 and its own README states plainly that it is unmaintained, so bugs or Node.js compatibility issues are unlikely to be fixed upstream. API Design: The set/get/del naming and behavior deliberately mirror memcached, so anyone with prior cache experience can start using it immediately; the promised v6.x TypeScript rewrite (mentioned in the README but not yet shipped) signals the maintainers are aware the CoffeeScript-sourced internals are a maintenance liability without changing the public API surface consumers already depend on.