Cache invalidation strategy implemented

A cache with no invalidation strategy serves stale data indefinitely. After a server-side update — price change, policy revision, content correction — users continue seeing the cached version until they clear app data or reinstall. ISO 25010:2011 reliability.recoverability requires a defined freshness boundary. Beyond staleness, unbounded caches accumulate sensitive data (PII, session-specific content) that should have been evicted after use. GDPR Art. 32 expects that personal data is not retained beyond its necessary lifetime — a cache without TTL enforcement is a retention policy violation by omission.

Wrap every cache entry with a timestamp and a TTL. Evict on read when the entry is expired, and run a periodic cleanup to prevent storage accumulation.

interface CacheEntry<T> { data: T; storedAt: number; ttl: number; }

export class Cache<T> {
  private store = new Map<string, CacheEntry<T>>();

  set(key: string, data: T, ttl = 5 * 60_000) {
    this.store.set(key, { data, storedAt: Date.now(), ttl });
  }

  get(key: string): T | undefined {
    const entry = this.store.get(key);
    if (!entry) return undefined;
    if (Date.now() - entry.storedAt > entry.ttl) {
      this.store.delete(key);
      return undefined;
    }
    return entry.data;
  }

  invalidate(key: string) { this.store.delete(key); }
}

// Always invalidate after a mutation:
await updateUser(id, data);
userCache.invalidate(`user_${id}`);

Set TTLs no higher than 86,400 seconds (24 hours). For data containing PII, use a tighter TTL (≤3,600 seconds) aligned with your data retention policy.