Este artículo, tercero de una serie del blog de ingeniería de Netflix, detalla la capa de consulta del Real-Time Distributed Graph (RDG) de la compañía, un sistema capaz de manejar miles de millones de nodos y aristas con latencias de un solo dígito en milisegundos. Tras explicar en las dos entregas anteriores la ingesta con Apache Flink y el diseño del almacenamiento, los autores Nilesh Mishra y Ajit Koti describen cómo se construyó una capa de servicio capaz de responder consultas complejas en menos de 100 milisegundos.
El texto distingue dos patrones de uso opuestos que el sistema debe soportar: consultas "poco profundas y anchas", como identificar todos los dispositivos desde los que una cuenta ha reproducido contenido en los últimos 30 días, que exigen gran capacidad de E/S; y consultas "profundas y estrechas", como reconstruir el historial de visionado de un perfil a través de varios saltos en el grafo, que penalizan la latencia por la dependencia secuencial entre saltos. Para resolver el primer caso se aprovechan los límites por tipo de arista y el procesamiento en paralelo por niveles; para el segundo, se empaqueta la lógica multi-salto en una única petición, evitando el overhead de red.
Dos decisiones de diseño articulan la solución: el recorrido en anchura (breadth-first) frente al clásico en profundidad, que reduce el número de rondas de llamadas aunque aumente el uso de memoria; y un modelo asíncrono basado en pequeños pools de hilos (16–24 hilos en total) que sostiene miles de consultas concurrentes sin recurrir al modelo thread-per-request. El resultado es una API de ejecución sobre gRPC que permite a equipos internos de Netflix —personalización, seguridad, operaciones— explorar el grafo en tiempo real sobre una base que sigue creciendo.