⚡ Tecnología
Adiós a Redis: Shopify lo reemplazó con MySQL y aguantó $5.1M por minuto
Un equipo de Shopify miró su infraestructura y tomó la decisión más hereje del año: botar Redis, la base de datos en memoria favorita de todo startup, y reemplazarla por MySQL. El abuelo de las bases de datos. ¿El resultado? Aguantó un Black Friday con $5.1 millones en ventas por minuto.
La historia está incendiando Hacker News: 124 puntos y 73 comentarios en menos de 24 horas. Y no es para menos, porque contradice una década de dogma tech que dice "si necesitas velocidad, usa Redis".
El problema: no puedes vender lo que ya vendiste
Cuando un comprador presiona "Completar compra", Shopify tiene que garantizar que el producto sigue disponible. Si dos personas compran la última unidad al mismo tiempo, alguien se queda sin su pedido y el comerciante paga el costo del soporte.
Ese sistema de reservas vivía en Redis desde hace años. Y funcionaba... hasta que no. El problema era la arquitectura: las reservas estaban en Redis, pero el inventario real vivía en MySQL. Dos sistemas separados que no podían actualizarse en una sola operación atómica.
El resultado: errores de overselling (vendiste algo que ya no tenías) y underselling (perdiste ventas porque marcaste algo como agotado cuando no lo estaba). En una plataforma que maneja el 14% del ecommerce de Estados Unidos, cualquier error se multiplica por millones.
La solución: MySQL con esteroides
Shopify reconstruyó el sistema de reservas sobre MySQL 8 usando SKIP LOCKED, una función que permite saltarse filas bloqueadas en lugar de esperarlas. La idea: una fila por unidad vendible en vez de una fila con contador.
Pero el diablo estaba en los detalles técnicos que separan a los buenos de los legendarios:
- Claves primarias compuestas: pasaron de 2 locks por reserva a solo 1
- READ COMMITTED: cambiaron el nivel de aislamiento para eliminar deadlocks en momentos pico
- Pool acotado de filas: máximo 1,000 unidades disponibles por producto/ubicación, con reposición automática
Inspirados en el enfoque de 37signals sobre distribución de carga con bases de datos tradicionales, lograron lo impensable: MySQL soportando picos que antes requerían un cluster de Redis.
La lección que nadie esperaba
Y aquí viene el plot twist. Después de optimizar queries, índices y locks, descubrieron que el verdadero cuello de botella no era la base de datos: eran las conexiones.
Los hilos se acumulaban, el CPU se disparaba en ráfagas y las conexiones a MySQL se agotaban en la capa de ProxySQL. Toda una operación de ingeniería para descubrir que el problema estaba en un lugar completamente distinto al que todos miraban.
La moraleja es incómoda: la mayoría de los equipos culpan a su base de datos cuando el problema real está en otra capa. Y migran a herramientas más caras y complejas sin medir primero.
Qué significa esto para ti 🚀
Si eres dev en LATAM, esta historia es oro. Porque te dice que no necesitas el stack más caro para escalar. MySQL corre en cualquier VPS, no requiere un cluster dedicado y tiene 30 años de documentación.
Claro, Redis sigue siendo excelente para caché. Pero el caso de Shopify demuestra que la tecnología "aburrida" puede manejar cargas brutales si la arquitectura está bien pensada.
¿La próxima vez que tu jefe quiera migrar a la base de datos de moda para arreglar un problema de rendimiento? Primero revisa las conexiones. 🐘
Comparte esto con ese dev que cree que MySQL no puede escalar. Y dime: ¿has migrado tecnología solo porque "estaba de moda" y después te arrepentiste? 👇