NETFLIX 2026-05-29 Tier 1

Netflix — High-Throughput Graph Abstraction at Netflix: Part I¶

Summary¶

Tier-1 Netflix TechBlog architectural-decomposition post — first part of a multi-part series and the dedicated decomposition the [[sources/2026-05-29-netflix-from-silos-to-service-topology-why-netflix-built-a-real-time-service-map|2026-05-29 Service Topology post]] referenced as deferred. The post canonicalises Netflix's Graph Abstraction — an internal OLTP-graph service handling "close to 10 million operations per second across 650 TB of graph datasets" with single-digit-ms p99 edge/node persistence and sub-50ms p90 on 2-hop traversals. The post's load-bearing structural disclosure is the storage layout: every graph is broken into a strongly-typed property-graph schema loaded as an in-memory metadata graph, then physically stored on top of Netflix's Key-Value Abstraction using a three-axis split: (1) per-node-type KV namespace (fetch a node + all properties in a single partition lookup); (2) edge links separated from edge properties into distinct namespaces (the link namespace holds the adjacency list; the property namespace holds the property bag); and (3) forward and reverse indexes (patterns/forward-and-reverse-adjacency-index) on the link namespace so that traversals can fan out in either direction with a single range read. Edge property records use a lexicographically-sorted-and- concatenated source+destination ID (patterns/lex-sorted-concatenated-edge-id) so properties live in one place regardless of the traversal direction the user requests. Two caching strategies sit in front of durable storage: a write-aside cache of edge links with TTL + invalidation-on-delete + lease-based exponential backoff to suppress redundant writes when an edge link already exists, and a read-aside cache of properties on EVCache with a per-namespace selectable invalidation strategy (invalidate-on-write for consistency-sensitive graphs / TTL-driven for high-write-throughput graphs that tolerate staleness). The consistency model is strict eventual consistency across regions with three explicit mechanisms to enforce it: (a) Last-Write-Wins (LWW) on every write via timestamped idempotency tokens enforced at the KV-storage layer and inherited by the graph layer; (b) a Kafka-driven entropy-repair pipeline (patterns/kafka-entropy-repair-for-multi-namespace-writes) that re-tries any failed multi-namespace write so non-atomic edge-link + edge-property writes converge — "to prevent inconsistencies or lasting entropy from failures in any operation"; and (c) asynchronous cascade delete (patterns/asynchronous-cascade-delete-for-high-fanout-graph-nodes) for nodes with potentially millions of connected edges, with LWW as the load-bearing primitive that makes the asynchronous-delete-vs- concurrent-update race correct. Schema is configured in the Data Gateway Control Plane, polled periodically by Abstraction servers, and used at runtime for data quality (write rejection on schema mismatch), query planning (possible traversal-path discovery), bidirectional traversal deduplication, and traversal-path elimination (impossible relationships and incompatible filters pruned before execution). The gRPC traversal API is Gremlin-inspired (chain traversals, filter, sort, limit, property-key pushdown to the KV layer), with a companion Count API for counting traversals at "very high rate with similar latencies". Three named consumers: Real-Time Distributed Graph (RDG) — dynamic relationship graph across the Netflix ecosystem, "powered by 2-hop traversals with a higher degree of fan-out" (often >100ms with p90 < 50ms); Social Graph for Netflix Gaming user engagement; and Service Topology (systems/netflix-service-topology) — the sibling 2026-05-29 post's real-time service-dependency map, hosting the network-flow graph and IPC graph each in its own Graph Abstraction namespace. Optional integration with TimeSeries Abstraction gives historical / time-travel views (deferred to Part III); traversal-engine deep-dive deferred to Part II. The post answers every "what's the substrate?" question deferred by the Service Topology post and the prior MVP-stub Graph Abstraction page on this wiki.

Key takeaways¶

Netflix splits its graph workload along the OLTP/ OLAP axis and builds Graph Abstraction strictly for OLTP. Verbatim: "OLAP: These use cases typically involve open-ended and algorithmic exploration of large graph datasets. They often utilize industry-standard models and languages such as RDF with SPARQL, Property Graphs with Gremlin or openCypher, and even SQL. The primary focus in these situations is in-depth analysis, rather than achieving high throughput and low latency. […] OLTP: These use cases require extremely high throughput — up to millions of operations per second — while delivering traversal results within milliseconds. Achieving such a level of performance often requires making trade-offs, which can include accepting eventual consistency or restricting query complexity. For example, the service can demand a specified starting point for traversals and enforce a maximum traversal depth." The wiki gets its first canonical disclosure of the OLTP/OLAP axis applied to graph workloads, and Graph Abstraction is the canonical OLTP-graph shape: high-throughput, low-latency, mandatory traversal start point, bounded depth, eventual consistency tolerated.
Build taller, not from scratch. "Instead of building the persistence and caching layers from scratch, we chose to build taller on top of existing Netflix data abstractions." Substrate: KV Abstraction for the real-time index on every node + edge namespace, optional TimeSeries Abstraction for historical views, EVCache for low- millisecond read latencies, and the Data Gateway Control Plane for schema management, provisioning, deletion, and dataset configuration. Graph Abstraction is therefore not a new database but a graph-shaped composition layer over Netflix's existing KV + cache + timeseries primitives, with the schema-driven in-memory metadata graph as the runtime brain.
Strongly-typed property graph + in-memory metadata graph at server startup drives four query-time optimisations. Each namespace is associated with an explicit graph schema in the Control Plane: edge mappings (fromNodeType, edgeType, toNodeType, directionType ∈ {UNIDIRECTIONAL, BIDIRECTIONAL}), each extended with a property schema (propertyKey, propertyValueType). At startup, servers "load this schema [...] and build an in-memory metadata graph of possible relationships, enabling several key optimizations":
Data Quality — "The Abstraction rejects non-conforming nodes, edges, and properties during writes, ensuring high data quality and consistent exports."
Query Planning — "The Abstraction uses the schema to quickly construct the possible traversal paths the service should take to answer a given user query."
Deduplication of Traversed Edges — "For bidirectional traversals on edges between the same node type, the schema helps avoid redundant processing by deduplicating traversed paths."
Eliminating Traversal Paths — "For a given user query, the Abstraction removes traversal paths associated with impossible relationships, as well as those where filters or property types are incompatible."

Schema is hot-reloaded — "the Abstraction servers periodically poll the schema from the Data Gateway Control Plane in order to keep it updated with user changes." (concepts/in-memory-schema-metadata-graph, patterns/schema-aware-traversal-planning)

Storage layout: per-node-type namespace + edge-link/edge- property split + forward and reverse indexes. This is the load-bearing structural disclosure of the post.
Nodes: each node type lives in its own KV namespace; "a given node and all its properties are fetched in a single partition lookup, achieving single-digit millisecond latency". KV's property selection pushdown and property filtering pushdown mean target keys / values are filtered at the KV layer, "reducing the amount of data fetched and further decreasing latencies and network overhead". Highly parallelised exports by node type.
Edges use two distinct types of indexes: a link index (adjacency list mapping source → connected neighbours) and a property index (the per-edge property bag). The split brings (a) efficient property upserts — "Allows individual properties to be upserted over time without needing to read the entire property set for an edge"; and (b) wide-row prevention — "Decoupling edge links from their properties prevents large partitions in databases like Cassandra, enabling efficient storage and low-latency reads — even for edges with millions of connections." The trade-off it costs: non-atomic writes across the link + property namespaces — addressed via Kafka entropy-repair (takeaway 7).
Forward and reverse indexes on the link namespace — "to support traversals in either direction". Direction becomes a query-time choice; both directions are O(range- read on a partition).
Direction-agnostic edge property storage — "the Abstraction lexicographically sorts and concatenates the source and destination node IDs to create a direction- agnostic identifier for property storage. This ensures that properties can be accessed or mutated in a single database call regardless of the direction specified in the request." One copy of properties; either direction reaches them via a deterministic ID.

Edge access patterns enabled: - Point reads — given an edge id, all properties in a single partition lookup. - Range reads — given a source node, range read on a partition returns all edges; forward or reverse index selected by direction. - Property filtering — "Properties are fetched only for the links that match the record or page limit criteria, minimizing the data exchanged over the network." - Sort orders — links are "sorted lexicographically by their target node" by default. For latest-connections queries, links are fetched and sorted by last-write time in memory — explicitly bounded: "to ensure optimal performance without exerting too much memory pressure, we aim to limit the number of edges per source node within the system." (patterns/separate-edge-links-from-properties, patterns/forward-and-reverse-adjacency-index, patterns/lex-sorted-concatenated-edge-id)

Idempotency tokens with timestamps drive Last-Write-Wins at the KV layer; Graph Abstraction inherits this primitive. Verbatim: "Writes to a given ID and key are idempotent, enabling request hedging and safe retries. The idempotency token contains a timestamp, which KV uses to enforce Last-Write-Wins (LWW) semantics at the storage layer." The wiki already canonicalises idempotency tokens as a Netflix KV primitive — this post adds the second-order disclosure that LWW is the load-bearing primitive of the asynchronous-cascade- delete correctness argument below.
Two caching strategies, chosen by what's being cached.
Write-aside cache of edge links — edge links carry no payload beyond the link identity + last-write timestamp. Cache them for short durations to suppress redundant writes of an already-existing link. "This mechanism is balanced with configurable TTL windows, cache invalidation on deletes, and lease acquisitions with exponential backoff. These strategies provide the necessary consistency guarantees while still allowing the last-write timestamp to be refreshed according to the predefined staleness."
Read-aside cache of properties on EVCache, both record- level and item-level. "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." Two per-namespace selectable invalidation strategies:
- Invalidation on write — "Both record and item caches are invalidated with every write, ensuring consistency across regions. This strategy is ideal for graphs that change infrequently and cannot tolerate data staleness, but comes with the tradeoff of pushing a higher throughput on the cache."
- TTL-driven invalidation — "Cache entries are invalidated only when their TTL expires. This approach works best for frequently modified objects that can tolerate some staleness."
Work-in-progress: write-through cache — "organize indexes by different sort orders (e.g., sorting data by last-write timestamp), at the cost of increased memory consumption."

The structural insight: edge-links and edge-properties have different cache shapes because edge-links are existence-questions and edge-properties are bag-fetches. (patterns/write-aside-cache-for-edge-links, patterns/read-aside-cache-with-dual-invalidation)

Strict eventual consistency enforced via Kafka entropy repair. Verbatim: "Each write in the Abstraction persists data for both inward and outward indices in parallel to support high throughput. Further, each write happens on multiple KV namespaces. To prevent inconsistencies or lasting entropy from failures in any operation, the Abstraction uses a robust retry mechanism using Kafka." This is the load-bearing answer to the non-atomic-multi-namespace-write trade-off introduced by the link/property split: the system accepts that any single write may fail partway, then publishes the failed-write intent to Kafka and retries it until it converges. The wiki gets its first canonical disclosure of Kafka as an entropy-repair substrate (rather than as an event log or a stream-processing substrate) — the broker is being used as a durable retry queue for cross-namespace consistency. (concepts/entropy-repair, patterns/kafka-entropy-repair-for-multi-namespace-writes)
Asynchronous cascade delete + LWW + load-bearing for correctness. Verbatim: "Deleting nodes in a highly connected graph is more complex than simply removing a KV record as each node may have thousands of connected edges that must be handled to maintain graph integrity. Further, synchronously deleting all such connections would introduce unacceptable latency for the Abstraction callers. The Abstraction employs an asynchronous deletion strategy to manage this issue. The consequence of this approach, however, is that the observed mutated state is only eventually consistent. Further, to ensure correctness of asynchronous deletes during concurrent updates, the Last-Write-Wins (LWW) conflict resolution mechanism is essential." The structural argument: an asynchronous delete raced against a concurrent update can resurrect the deleted state if the system used naive ordering — LWW makes it correct because the delete carries a higher timestamp than any update that races but did not actually happen-before the delete. (concepts/asynchronous-cascade-delete, patterns/asynchronous-cascade-delete-for-high-fanout-graph-nodes)
Multi-region async replication via the underlying caching + durable layers — graph-side gets eventual consistency for free. Verbatim: "As illustrated in the diagram below, both the caching layer and durable storage replicate data asynchronously across regions, resulting in an eventually consistent system." Graph Abstraction does not add cross-region semantics on top — it inherits whatever the substrate (KV + EVCache) provides. The payoff: high availability across regions; the cost: cross- region reads may briefly see stale state. The strict-eventual-consistency framing applies here: convergence is guaranteed, just not bounded.
gRPC traversal API is Gremlin-inspired with chained traversals + property selection pushdown + sort + limit + direction filter. A traversal request can chain multiple Traversal blocks against the intermediate result; each block has a DirectionTraversal (direction + property selections + type filter). The property selections are pushed down to KV so only requested fields cross the wire. Worked example from the post — "recommend shows to users on a shared device, by considering the duration of the most recent viewing session for each show across all profiles and accounts associated with that device" — chains device → (IN, account|profile, edge limit 5, select created_at, last_active) → (OUT, title|plan, edge limit 200 ordered LATEST, select watched.view_time, has_plan.active). Companion Count API performs counting traversals at "very high rate with similar latencies" (covered in Part II). The Gremlin influence sits at the API surface layer; the underlying engine is Netflix's own (OLTP-graph orientation, KV-backed store, schema-aware planner).
Operational headlines. "The abstraction is handling close to 10 million operations per second across 650 TB of graph datasets with low latency and cost efficiency." Edge and node persistence at single-digit-ms p99; 1-hop traversals at single-digit-ms latency; 2-hop traversals can reach 100ms with p90 < 50ms when fan-out is high; node deletions sub-second (the asynchronous cascade-delete trajectory). The Count API runs "at a very high rate with similar latencies". RDG specifically is "powered by 2-hop traversals with a higher degree of fan-out". The post tracks average and max edge fan-out at different depths as a first-class operational metric.
Three named consumers; many implied. Real-Time Distributed Graph (RDG) — "a graph capturing dynamic relationships across entities and interactions throughout the Netflix ecosystem" (succeeds the original RDG implementation referenced in the post — "This functionality has since been integrated into the Graph Abstraction"); Social Graph for Netflix Gaming; and Service Topology (the sibling 2026-05-29 post) which now becomes the third named first-party consumer of Graph Abstraction. The forward-looking framing — "As Netflix scales further into new verticals such as live content, games, and ads, Graph Abstraction will remain crucial for uncovering and leveraging rich connections" — positions Graph Abstraction as one of the key substrates for Netflix's next-generation product surface.

Architecture (post diagram, decoded)¶

                    ┌─────────────────────────────────────┐
                    │  Data Gateway Control Plane         │
                    │  - graph schema (edge mappings,     │
                    │    property schemas)                │
                    │  - provision/delete/configure       │
                    │  - capacity-modeled hardware spec   │
                    └────────────┬────────────────────────┘
                                 │ poll periodically
                                 ▼
        ┌────────────────────────────────────────────────────┐
        │  Graph Abstraction servers                         │
        │  - In-memory metadata graph (built from schema)    │
        │  - Strongly-typed property graph runtime           │
        │  - Schema-aware planner (4 optimisations)          │
        │  - gRPC traversal API (Gremlin-inspired)           │
        │  - Count API                                       │
        └─────┬─────────────────────────────────────┬────────┘
              │                                     │
              │ point/range reads on KV             │ Kafka entropy
              ▼                                     │ repair pipeline
   ┌──────────────────────────────┐                 │
   │ Netflix KV Abstraction       │                 ▼
   │ - per-node-type namespace    │   ┌────────────────────────┐
   │ - edge-link namespace        │   │ Kafka — durable retry  │
   │   (forward + reverse index)  │   │ queue for failed       │
   │ - edge-property namespace    │   │ multi-namespace writes │
   │   (lex-sorted-concat ID)     │   └────────────────────────┘
   │ - LWW via idempotency token  │
   └──────────────┬───────────────┘
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
   ┌──────────────┐    ┌─────────────────────────────────┐
   │ EVCache      │    │ Optional: TimeSeries Abstraction│
   │ - read-aside │    │ - historical view (Part III)    │
   │ - inv-on-    │    └─────────────────────────────────┘
   │   write OR   │
   │   TTL-driven │
   └──────────────┘
   ┌──────────────────────────────────────────────────┐
   │ In-process write-aside cache (edge links)        │
   │ - short TTL  - inv on delete  - leases + backoff │
   └──────────────────────────────────────────────────┘

         Async multi-region replication on KV + EVCache
         → strict eventual consistency on graph layer

   Consumers:  RDG  ·  Netflix Gaming Social Graph  ·
               Service Topology (network + IPC graphs)

Operational numbers¶

Quantity	Value	Source quote
Aggregate ops/sec at peak	~10 million / sec	"close to 10 million operations per second"
Total graph data globally	~650 TB	"close to 650 TB of data globally across all our graph datasets"
Node read latency	single-digit ms (single partition lookup)	"a given node and all its properties are fetched in a single partition lookup, achieving single-digit millisecond latency"
Edge / node persistence	single-digit ms p99	post charts (p99 red / p90 orange / p50 green)
1-hop traversal	single-digit ms	"Typically 1-hop traversals are executed with single-digit millisecond latency"
2-hop traversal	upwards of 100 ms; p90 < 50 ms	"2-hop traversals with a higher degree of fan-out. While these operations can reach upwards of 100 ms in latency, the 90th percentile (p90) latency remains under 50ms"
Async deletes	sub-second typically	"asynchronous operations such as node deletions can be slightly latent, but typically perform with sub-second latency"
Count API latency	similar to traversal latencies	"counting traversals at a very high rate with similar latencies"
Storage substrate	KV Abstraction (durable) + EVCache (cache) + optional TimeSeries Abstraction	"key-value abstraction stores the latest view" / "plug-in the timeseries abstraction" / "EVCache to achieve low-millisecond latencies"
Failure-recovery substrate	Kafka	"a robust retry mechanism using Kafka"
Multi-region semantics	async replication on KV + EVCache	"both the caching layer and durable storage replicate data asynchronously across regions"

Systems extracted¶

systems/netflix-graph-abstraction — the system itself. Canonical decomposition in this post (was MVP-stub on the wiki prior to ingest).
systems/netflix-kv-dal — substrate for the real-time index; every node + edge namespace is a KV namespace; the "map of sorted maps" + idempotency-token shape is reused verbatim. New face — Graph Abstraction altitude.
systems/netflix-timeseries-abstraction — optional substrate for the historical / time-travel view of how the graph evolves (deferred to Part III). New face — Graph Abstraction altitude.
systems/evcache — in-memory cache substrate for property reads; "Multiple KV namespaces can share the same caching clusters for cost efficiency." New face — graph-property read-aside cache with per-namespace invalidation strategy.
systems/netflix-data-gateway — Control Plane for schema management, provisioning, deletion, configuration, and capacity- modelled hardware spec. New face — graph-schema authority.
systems/apache-cassandra — explicit example of a wide-row- sensitive backend the link/property split protects against; "prevents large partitions in databases like Cassandra".
systems/netflix-service-topology — third named consumer of Graph Abstraction (Network + IPC layers). Cross-link from sibling 2026-05-29 post.

Concepts extracted¶

concepts/property-graph — the data model of Graph Abstraction; nodes and edges of various typed kinds with strongly- typed properties; edges directional or bidirectional.
concepts/oltp-vs-olap — applied at the graph-workload axis (this post's load-bearing framing).
concepts/adjacency-list-storage — the link namespace shape; "arranged as an adjacency list mapping source nodes to their connected neighbors".
concepts/forward-reverse-edge-index — dual indexes per edge type to support either traversal direction with a single range read.
concepts/direction-agnostic-edge-id — the lex-sorted + concatenated source/dest node ID; one property storage record regardless of traversal direction.
concepts/in-memory-schema-metadata-graph — schema loaded at startup as a runtime graph used for write rejection, query planning, traversal-edge dedup, and impossible-path elimination.
concepts/read-amplification — "A single traversal request on the fronting service may translate into thousands of fetch operations on the backend, especially for highly interconnected graphs."
concepts/write-amplification — "A single write on the fronting service can result in multiple writes to the backing durable storage due to the use of multiple indexes."
concepts/idempotency-token — already canonical wiki concept; this post adds the disclosure that the token is the LWW vehicle.
concepts/last-write-wins — already canonical wiki concept; this post adds the disclosure that LWW is the load-bearing primitive that makes asynchronous-cascade-delete correct against concurrent updates.
concepts/strict-eventual-consistency — graph-layer outcome of multi-region async replication + Kafka entropy repair + LWW.
concepts/asynchronous-cascade-delete — the deletion strategy for high-fanout graph nodes; sub-second observed latency.
concepts/graph-traversal-fanout — "average and max edge fanout at different depths" tracked as first-class operational metric.
concepts/entropy-repair — Kafka-based retry-until-converge mechanism for cross-namespace inconsistency.
concepts/eventual-consistency — broader concept the strict- EC variant inherits from.

Patterns extracted¶

patterns/separate-edge-links-from-properties — the load-bearing storage pattern of Graph Abstraction. Two distinct index types per edge: link index (the adjacency list, low payload) + property index (the property bag). Trade: non-atomic multi-namespace writes → entropy repair.
patterns/forward-and-reverse-adjacency-index — dual indexes on the link namespace for either-direction traversal in a single range read.
patterns/lex-sorted-concatenated-edge-id — direction-agnostic edge identifier so property storage is single-copy regardless of traversal direction.
patterns/write-aside-cache-for-edge-links — short-TTL + invalidate-on-delete + lease-with-exponential-backoff caching of edge-link existence, suppressing redundant writes.
patterns/read-aside-cache-with-dual-invalidation — EVCache read-aside with per-namespace selectable invalidation strategy (invalidate-on-write vs TTL-driven), at both record and item levels.
patterns/kafka-entropy-repair-for-multi-namespace-writes — Kafka-driven retry until convergence; the fix for non-atomic multi-namespace edge writes.
patterns/asynchronous-cascade-delete-for-high-fanout-graph-nodes — defer connected-edge cleanup to async pipeline; LWW provides correctness against concurrent updates.
patterns/schema-aware-traversal-planning — load schema as in-memory metadata graph at startup; use it for data-quality validation, query planning, traversal dedup, and impossible-path elimination.

Caveats¶

Part-I-shape — engine deferred. The post explicitly defers "the design and implementation of traversal planning and execution, along with different traversal types" to Part II, and the temporal / time-travel index implementation to Part III. Read this source as the storage and consistency layer; the planner and the historical-view-vs-real-time-index merge are named but not detailed.
No concrete throughput / latency split per workload. The 10 M ops/sec headline is fleet-aggregate; per-namespace throughput, RDG-specific QPS, and Service-Topology-specific QPS are not disclosed. Edge-fanout distributions are shown qualitatively (median + max charts) but no numeric values.
No node-count / edge-count totals. 650 TB is the storage headline; no node-count, edge-count, or per-namespace dataset size is given. "Limit the number of edges per source node within the system" is named as an operational invariant but the actual cap is not disclosed.
Underlying KV substrate not deeply named for the graph-side KV namespaces. The [[sources/2024-09-19-netflix-netflixs-key-value-data-abstraction-layer|2024-09-19 KV Abstraction post]] discloses Cassandra, EVCache, DynamoDB, and RocksDB as KV-substrate options; this post simply uses Cassandra-shaped "large partitions" as the wide-row example. The actual KV-substrate-per-graph-namespace mapping is not disclosed (almost certainly Cassandra-backed for the at-scale graphs given the "map of sorted maps" shape, but unconfirmed in this post).
Kafka deployment for entropy repair is named but not sized. Topic count, partition count, retention horizon, consumer parallelism, deduplication policy, and DLQ semantics are all undisclosed. Whether the Kafka loop is per-region or cross- region is also unclear.
Cache invalidation strategy chosen "based on write throughput and consistency requirements" — but the decision rule is not disclosed. Per-namespace selection is implied but the threshold (which RPS / which staleness budget switches the recommendation) is undisclosed.
Write-through cache is work-in-progress. "We are also developing a write-through caching strategy designed to store most of the data required by the Abstraction during traversals" — no shipped use, no benchmark numbers, no on-the-record trade-off framing yet.
Asynchronous-cascade-delete observability surface is thin. "Sub-second latency" covers the typical case; the worst-case fanout (millions of edges) latency, the back-pressure shape on the async pipeline, and consumer-visible semantics during the in-flight delete are not detailed. The post argues correctness via LWW but does not show how a query running mid-delete presents.
OLAP graph workloads are out of scope. The post explicitly positions OLAP graph use cases (RDF/SPARQL/Gremlin/openCypher/SQL on big graphs) as a different category Graph Abstraction does not target. Whether Netflix has a separate substrate for OLAP graph queries is not addressed.
The Gremlin influence is API-surface only. The post says the traversal API is "inspired by Gremlin" but does not adopt the Gremlin language or the TinkerPop runtime; the engine is Netflix's own. Schema-awareness, mandatory traversal start-point, and bounded depth all diverge from canonical Gremlin semantics.
Provisioning automation is named but not detailed in this post. The link to the Service Capacity Modeling repo and Joey Lynch's AWS re:Invent talk are pointers — the actual decision algorithm (throughput / latency / dataset size / workload criticality → hardware spec) is referenced but not re-disclosed.
The relationship to the original RDG post is consolidative. The post says "This functionality has since been integrated into the Graph Abstraction" — RDG started with its own storage layer (referenced 2018-era post) and was migrated onto Graph Abstraction. The migration history, cutover mechanics, and any contradictions vs the older RDG architecture are not surfaced.
Authorship: Oleksii Tkachuk, Kartik Sathyanarayanan, Rajiv Shringi. Acknowledged as contributors: Kaidan Fullerton, Joey Lynch, Sudhesh Suresh, Vinay Chella, Sumanth Pasupuleti, Vidhya Arvind, Raj Ummadisetty, Jordan West, Chris Lohfink, Joe Lee, Jingxi Huang, Jessica Walton, Prudhviraj Karumanchi, Akashdeep Goel, Sriram Rangarajan, Chris Van Vlack, Christopher Gray, Luis Medina, Ajit Koti, Mohidul Abedin.

Sibling cross-refs¶

Direct sibling — [[sources/2026-05-29-netflix-from-silos-to-service-topology-why-netflix-built-a-real-time-service-map|2026-05-29 Service Topology post]]. Both posts published the same day; the Service Topology post identifies "Netflix's graph database, an abstraction layer built on top of our distributed key-value storage infrastructure" as the substrate for its network-flow graph and IPC graph; this post is the substrate's dedicated decomposition. Together the two posts span the storage substrate → consumer-application arc.
Sibling on the data-abstraction-layer axis — [[sources/2024-09-19-netflix-netflixs-key-value-data-abstraction-layer|2024-09-19 KV Abstraction]] (the KV substrate); [[sources/2024-11-13-netflix-netflixs-distributed-counter-abstraction|2024-11-13 Distributed Counter Abstraction]] (counter shape over the same KV substrate). All three posts canonicalise Netflix's "build-taller-on-top-of-existing-data-abstractions" approach — counter is the simplest shape, KV is the substrate, Graph is the most complex shape.
Sibling on the graph-substrate axis — [[sources/2025-06-14-netflix-model-once-represent-everywhere-uda|2025-06-14 UDA]] (knowledge-graph as semantic substrate); [[sources/2026-05-04-netflix-democratizing-machine-learning-building-the-model-lifecycle-graph|2026-05-04 Model Lifecycle Graph]] (graph as ML-metadata substrate). The three posts converge on graph-shaped substrates as the programmable foundation under different Netflix engineering surfaces — UDA on knowledge / semantics, MDS on ML metadata, Graph Abstraction on real-time OLTP graph workloads.
Sibling on the OLTP-vs-OLAP-graph axis — open question: the post frames OLAP graph workloads as a separate category but no Netflix wiki page yet covers the OLAP-side. A future ingest of Netflix's analytical-graph substrate (if disclosed) would close this axis.