# How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC...

DevFeed: [How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC...](<https://devfeed.tech/articles/how-and-why-netflix-built-a-real-time-distributed-graph-part-3-querying-the-graph-with-grpc-138.md>)

Original publisher: [Read original article](<https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-3-querying-the-graph-with-grpc-0f3468349607?source=rss----2615bd06b42e---4>)

Author: Netflix Technology Blog

Published: 2026-08-07T16:01:02Z

Content type: article

Language: en

Sources: [Netflix](<https://devfeed.tech/sources/netflix.md>), [Netflix TechBlog - Medium](<https://devfeed.tech/sources/netflix-techblog-medium.md>)

Topics: [Graphs](<https://devfeed.tech/topics/graphs.md>), [gRPC](<https://devfeed.tech/topics/grpc.md>), [Netflix](<https://devfeed.tech/topics/netflix.md>), [real-time](<https://devfeed.tech/topics/real-time.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [API](<https://devfeed.tech/topics/api.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>), [personalization](<https://devfeed.tech/topics/personalization.md>), [Security](<https://devfeed.tech/topics/security.md>), [apache-flink](<https://devfeed.tech/topics/apache-flink.md>)

Tags: [apache](<https://devfeed.tech/tags/apache.md>), [apache-flink](<https://devfeed.tech/tags/apache-flink.md>), [api](<https://devfeed.tech/tags/api.md>), [data](<https://devfeed.tech/tags/data.md>), [data-processing](<https://devfeed.tech/tags/data-processing.md>), [events](<https://devfeed.tech/tags/events.md>), [latency](<https://devfeed.tech/tags/latency.md>), [netflix](<https://devfeed.tech/tags/netflix.md>), [personalization](<https://devfeed.tech/tags/personalization.md>), [real-time](<https://devfeed.tech/tags/real-time.md>), [security](<https://devfeed.tech/tags/security.md>), [streaming](<https://devfeed.tech/tags/streaming.md>)

## AI overview

Netflix's third-part blog post describes the serving layer for its Real-Time Distributed Graph and explains how gRPC enables efficient graph querying. It focuses on serving diverse workloads, including security lookups and personalization traces, with sub-100ms responses across a billion-edge graph.

## Source excerpt

How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC execution API Authors: Nilesh Mishra and Ajit Koti This is the third entry of a multi-part blog series describing how we built a Real-Time Distributed Graph (RDG). In Part 1, we discussed the motivation for creating the RDG and the architecture of the data processing pipeline that populates it. In Part 2, we discussed how we designed the storage layer to handle billions of nodes and edges while maintaining single-digit-millisecond latency. In Part 3, we will explore how we designed a fast, flexible serving layer to efficiently query the graph. Introduction In Part 1 of this series, we described why Netflix needed a Real-Time Distributed Graph (RDG) and how we used Apache Flink to build an ingestion and processing pipeline that turns streaming events into graph primitives. In Part 2, we explored how we designed a storage layer capable of handling billions of nodes and edges while still delivering single-digit-millisecond latency. In this post, we focus on the next challenge: querying the graph efficiently to power real-time insights for our internal partners. All of the work on ingestion and storage only matters if we can actually ask complex questions and get answers back quickly. As we optimized for lower latency, we found that the serving layer posed its own set of challenges, distinct from those of ingestion and storage. How do we turn a constantly evolving, billion-edge graph into sub-100ms responses across a wide variety of workloads? This is the problem we tackle in this post. The Real World Needs As we integrated the RDG into Netflix's ecosystem, we realized that "querying the graph" is not a one-size-fits-all operation. We needed to handle a wide range of access patterns: from high-volume security lookups to deep, exploratory personalization traces. Let's revisit our example from Part 1 and expand on it slightly. In the earlier posts, we focused on accounts, device