Netflix's serving layer for its Real-Time Distributed Graph, built to answer tens of thousands of queries/sec in under 100ms. Jordan and Riley dig into the two query shapes (shallow-wide vs. deep-narrow), why they chose breadth-first batched traversal over depth-first, the async-first threading model over thread-per-request, and packing multi-hop traversals into a single gRPC call to kill per-hop round-trips.

Source: How and Why Netflix Built a Real-Time Distributed Graph, Part 3: Querying the Graph with gRPC — Netflix Tech Blog, Aug 7 2026 — https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-3-querying-the-graph-with-grpc-0f3468349607

This is commentary/summary in the hosts' own words, not a reproduction of the article.

Why Netflix skipped native graph databases (Neo4j, Neptune) for its Real-Time Distributed Graph and built on KVDAL — a key-value abstraction over Apache Cassandra — instead. Jordan and Riley cover the record/item mapping that makes a key-value store hold a graph (nodes as property records, edges as adjacency lists), the per-type namespace model for independent scaling, and the scale: 8 billion nodes, 150+ billion edges, 2M reads/sec and 6M writes/sec at single-digit-millisecond latency across 2,400 EC2 instances.

Source: How and Why Netflix Built a Real-Time Distributed Graph, Part 2: Building a Scalable Storage Layer — Netflix Tech Blog, Nov 14 2025 — https://netflixtechblog.medium.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-2-building-a-scalable-storage-layer-ff4a8dbd3d1f

This is commentary/summary in the hosts' own words, not a reproduction of the article.

The origin story of Netflix's Real-Time Distributed Graph: why microservices left them with data silos across ads, live events, and games, and how member actions become graph nodes and edges. Jordan and Riley cover the API Gateway to Kafka to Flink pipeline (~1M msgs/sec per topic, 5M+ records/sec published downstream), and the two scaling calls Netflix made — one Flink job per Kafka topic, and a separate topic per node/edge type — trading operational overhead for independent scaling.

Source: How and Why Netflix Built a Real-Time Distributed Graph, Part 1: Ingesting and Processing Data Streams at Internet Scale — Netflix Tech Blog, Oct 17 2025 — https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-1-ingesting-and-processing-data-80113e124acc

This is commentary/summary in the hosts' own words, not a reproduction of the article.

In this episode, Jordan and Riley break down a recent Cloudflare Engineering post on Town Lake, their internal data lakehouse, and Skipper, the AI agent built on top of it. They cover why Cloudflare needed it (a billion+ events/sec scattered across Postgres, ClickHouse, Kafka, and more), how Trino and Iceberg tie it together into one queryable system, the "default-closed" access model for sensitive data, and how Skipper turns natural-language questions into safe, grounded SQL — including a neat trick that cut its tool-calling round-trips from five down to one.

Source: How we built Cloudflare's data platform and an AI agent on top of it — The Cloudflare Blog, May 28, 2026. This episode is commentary and discussion, not a reproduction of the original post — read the full article at the link above.