El incidente se originó por el crecimiento incontrolado de particiones en Apache Cassandra, un problema común en bases de datos NoSQL con esquemas de datos de series temporales. Las particiones anchas llevaron a un rendimiento degradado, manifestado como altas latencias de lectura, timeouts, pausas de Garbage Collection, alta utilización de CPU y colas de hilos. La estrategia inicial de particionamiento por 'Time Slices' y la planificación de capacidad basada en Monte Carlo no fueron suficientes para manejar cargas de trabajo desconocidas, evolutivas o con outliers de datos (TimeSeries IDs con volúmenes de eventos excepcionalmente altos).
Las salvaguardas existentes, como el escalado del cluster, eran costosas e ineficientes para el problema de particiones específicas. La primera solución, 'Time Slice Re-Partitioning', abordó el problema a nivel de tabla, ajustando la estrategia de particionamiento para futuras Time Slices. Sin embargo, esta solución no era efectiva para el caso de outliers de IDs dentro de una tabla, donde solo un pequeño porcentaje de particiones eran problemáticas. Esto dejaba una brecha crítica en la capacidad del sistema para manejar la variabilidad inherente de las cargas de trabajo de series temporales.
La solución definitiva, 'Dynamic Partitioning per ID', abordó la causa raíz de manera más granular. Al detectar particiones anchas en la ruta de lectura, planificar su división asíncronamente y redirigir las lecturas de forma transparente, Netflix pudo mitigar el impacto de las particiones anchas sin requerir cambios manuales o reescrituras de datos masivas. La decisión de enfocarse inicialmente en particiones inmutables redujo la complejidad, y el uso de Bloom filters y caches para el enrutamiento de lecturas minimizó la sobrecarga, demostrando un diseño robusto para un problema complejo de rendimiento de bases de datos distribuidas.