Difficulty: Intermediate
Type: Feature
Recommended labels (if available in this repo): enhancement, caching, sdk
Background
docs/cache-adapters.md documents the pluggable caching interface, and the roadmap in docs/CAMPAIGN_TASKS.md lists an LRU cache adapter as a planned-but-not-implemented feature. Currently examples/redis-cache-adapter/ shows how to plug in Redis, but there is no lightweight in-memory default for consumers who don't want an external cache dependency.
Problem
Consumers who don't need Redis (e.g. simple Node scripts or short-lived edge functions) have no first-party in-memory cache option and must either write their own adapter or run without caching entirely, hurting default performance.
Expected Outcome
A new LruCacheAdapter implementing the cache adapter interface defined in src/cache/cache.types.ts, usable as new LruCacheAdapter({ maxEntries, ttlMs }), with TTL-based expiry.
Suggested Implementation
Implement a doubly-linked-list-backed or Map-based LRU (insertion-order eviction is acceptable if a full O(1) LRU is out of scope) honoring the CacheAdapter interface. Add configurable maxEntries and ttlMs. Wire it as the SDK's default adapter when no adapter is explicitly configured, matching the pattern implied in docs/cache-adapters.md.
Acceptance Criteria
- New
LruCacheAdapter class implements the existing CacheAdapter interface without modifying the interface itself
- Supports configurable max size and TTL-based expiry
- Unit tests cover eviction order, TTL expiry, and get/set/delete/clear behavior
docs/cache-adapters.md updated with usage examplepnpm test:run passes
Likely Affected Files/Directories
src/cache/cache.types.tsdocs/cache-adapters.mdexamples/redis-cache-adapter/src/index.ts
Difficulty: Intermediate
Type: Feature
Recommended labels (if available in this repo):
enhancement,caching,sdkBackground
docs/cache-adapters.mddocuments the pluggable caching interface, and the roadmap indocs/CAMPAIGN_TASKS.mdlists an LRU cache adapter as a planned-but-not-implemented feature. Currentlyexamples/redis-cache-adapter/shows how to plug in Redis, but there is no lightweight in-memory default for consumers who don't want an external cache dependency.Problem
Consumers who don't need Redis (e.g. simple Node scripts or short-lived edge functions) have no first-party in-memory cache option and must either write their own adapter or run without caching entirely, hurting default performance.
Expected Outcome
A new
LruCacheAdapterimplementing the cache adapter interface defined insrc/cache/cache.types.ts, usable asnew LruCacheAdapter({ maxEntries, ttlMs }), with TTL-based expiry.Suggested Implementation
Implement a doubly-linked-list-backed or
Map-based LRU (insertion-order eviction is acceptable if a full O(1) LRU is out of scope) honoring theCacheAdapterinterface. Add configurablemaxEntriesandttlMs. Wire it as the SDK's default adapter when no adapter is explicitly configured, matching the pattern implied indocs/cache-adapters.md.Acceptance Criteria
LruCacheAdapterclass implements the existingCacheAdapterinterface without modifying the interface itselfdocs/cache-adapters.mdupdated with usage examplepnpm test:runpassesLikely Affected Files/Directories
src/cache/cache.types.tsdocs/cache-adapters.mdexamples/redis-cache-adapter/src/index.ts