PlanetScale documenta una caída de producción de dieciséis minutos sufrida por una base de datos MySQL para explicar por qué aumentar la concurrencia puede reducir el rendimiento en lugar de mejorarlo. El incidente lo provocó un trabajo por lotes que abrió una transacción sobre una tabla activa y retuvo bloqueos de fila durante quince minutos sin hacer commit. Las lecturas que se acumularon detrás no estaban bloqueadas por esos bloqueos, pero InnoDB tuvo que reconstruir instantáneas consistentes retrocediendo en el historial de versiones de cada fila tocada por la transacción, lo que disparó los tiempos de ejecución por encima de los noventa segundos. Las reintentos del cliente apilaron más de diez mil peticiones en el motor de almacenamiento, cuyas cadenas de versiones eran cada vez más largas, y la presión sobre el buffer pool acabó afectando incluso a tablas no relacionadas.
La carga provenía de una migración reciente desde Cloud SQL a Vitess. Cloud SQL utilizaba un pool de hilos que limitaba a unos mil los statements simultáneos y encolaba el resto; Vitess usa vttablet con un pool de transacciones que, al llenarse, devuelve error tras una espera corta. Esa diferencia hizo que los errores se propagaran por una pila de aplicación que nunca había tenido que gestionarlos. La primera reacción fue elevar el límite del pool a diez mil, lo que eliminó los errores pero eliminó también la capacidad de Vitess para aplicar contrapresión.
El artículo enmarca el problema con la Ley de Little (N = X · W) y la Ley de Escalabilidad Universal de Gunther, que descompone el coste de la concurrencia en contención (α) y coherencia (β). Cuando β domina, el rendimiento total puede caer: doblar N casi cuadruplica el coste de coherencia, un fenómeno que Gunther denomina escalado retrógrado. Los bloqueos eran solo la contención α; el daño real fue β, las diez mil lecturas de instantáneas encarecidas mutuamente por el historial de versiones.
La solución aplicada fue revertir los cambios en ambas dimensiones: reducir el pool de transacciones de Vitess a unos mil, como el antiguo pool de hilos, y hacer que las peticiones que lleguen a un pool lleno esperen un tiempo acotado en cola en lugar de fallar. Los autores concluyen que dimensionar los pools de conexiones con evidencia y mantener una cola con timeout limitado es clave para que una sola transacción lenta no derive en una caída generalizada.