Response caching
Client-side cache wrappers — LRU, Redis — Meridian doesn't cache responses server-side.
Meridian takes an opinionated stance on response caching: we don't do it server-side. Every request hits your origin. This keeps licensing checks authoritative and eliminates stale-state bugs that plague traditional CDN-cached DRM backends.
Instead, Meridian ships client-side cache wrappers you can drop into your loader or dashboard frontend. Two backends are supported out of the box:
LRU (Least Recently Used)
In-memory bounded cache. Default capacity is 256 entries. Evicts oldest-accessed keys when full. Zero dependencies, zero network calls. Ideal for loader-side session tokens and hardware-fingerprint lookups that repeat within a single process lifetime.
Redis
Network-backed cache for multi-process or multi-machine deployments. Connects via a standard Redis URI. Meridian handles connection pooling, automatic reconnect with exponential backoff, and optional TLS. Use this when your dashboard or bot shares cached license states across replicas.
Usage pattern
Both wrappers expose the same interface: get(key), set(key, value, ttl), del(key). You choose the backend at init time and the rest of your code stays identical. No cache stampede protection is built in — that's your responsibility at the call site if you need it.
Design note: Meridian deliberately avoids server-side response caching because every license validation must be real-time. A cached "valid" response for a revoked key is a security incident. Client-side caches are short-lived and scoped to the process that owns them.
TTL semantics
Time-to-live is specified in seconds. A TTL of 0 means "never expire" (LRU eviction still applies). The Redis backend delegates TTL to Redis's native EXPIRE command. The LRU backend runs a lazy sweep on each get() call — expired entries are dropped before the lookup proceeds.
What Meridian does NOT cache
- License validation responses (always live)
- Hardware fingerprint enrollments
- Payment webhook payloads
- Session token issuance
The client-side cache is meant for derived, idempotent lookups: resolved user metadata, feature-flag evaluations, and pre-computed UI state. If you're unsure whether something should be cached, the answer is probably no.