Skip to content

SYSTEM Cited by 3 sources

EVCache

EVCache is Netflix's distributed in-memory caching solution, a wrapper around Memcached with Netflix-specific enhancements for high availability, global replication, client-side sharding, and multi-region operation. Open-source at github.com/Netflix/EVCache.

Within this wiki, EVCache is a stub — named as a canonical Netflix caching layer paired with persistent stores in KV DAL namespaces, but not yet deep-dived. Expansion is expected when a dedicated EVCache architecture post is ingested.

Role in the KV DAL story

Namespace configs in KV DAL can layer EVCache as a CACHE tier on top of a durable primary. Example from the post:

CACHE:
  physical_storage:
    type: CACHE
    cluster: evcache_kv_ngsegment
  config:
    default_cache_ttl: 180s

The combination — e.g. Cassandra as PRIMARY_STORAGE + EVCache as CACHE — gives "highly durable persistent storage AND lower- latency point reads" inside one logical namespace, without the calling microservice having to wire cache + DB coherency by hand.

Role in the Counter Abstraction

The Distributed Counter Abstraction uses EVCache in two distinct roles:

  1. Best-Effort counter backing — a thin wrapper over EVCache incr/decr delivers a regional approximate counter with high throughput + low latency, at the cost of no cross-region replication on increments + no idempotency + no consistency guarantees. Code skeleton from the post:
return delta > 0
    ? cache.incr(counterCacheKey, delta, TTL)
    : cache.decr(counterCacheKey, Math.abs(delta), TTL);

ClearCount maps to cache.delete(key, ReplicaPolicy.ALL). (Source: sources/2024-11-13-netflix-netflixs-distributed-counter-abstraction)

  1. Rollup Cache for Eventually-Consistent counters — caches the combined (lastRollupCount, lastRollupTs) as a single cached value per counter (combined to prevent count / timestamp mismatch). GetCount serves a point-read from this cache, accepting a few seconds of staleness. See patterns/sliding-window-rollup-aggregation.

Role in the Graph Abstraction story (2026-05-29)

The Graph Abstraction Part-I post adds a third canonical EVCache face: the read-aside cache for graph-edge property reads under Netflix's Graph Abstraction service. Verbatim:

"To reduce read amplification on the durable store, the Graph Abstraction leverages KV's integration with EVCache. Multiple KV namespaces can share the same caching clusters for cost efficiency. The Abstraction first fetches data from durable storage, while subsequent reads are served from the cache. Caching is applied at both the record and item levels, benefiting all graph objects."

Two structural disclosures:

  1. Multi-namespace shared caching clusters — many graph namespaces (per-node-type, per-edge-type forward / reverse link / property) share one EVCache cluster for cost efficiency, not one cluster per namespace. Noisy-neighbour mitigation lives in EVCache's own multi-tenant sizing.
  2. Two cache levels — record + item — both whole-record sorted maps and individual KV pairs are cached, matching the different access shapes of property-bag fetches vs targeted property reads.

The Graph Abstraction adds per-namespace selectable invalidation strategy (patterns/read-aside-cache-with-dual-invalidation): invalidate-on-write for graphs that change infrequently and cannot tolerate staleness, TTL-driven for high-write-throughput graphs that can. Either way, the cache is the front-line lever against graph traversal read amplification (a single traversal can fan out to thousands of fetches).

Seen in

Last updated · 542 distilled / 1,571 read