La llamada llegó a las 9:47 de la mañana del Black Friday. Una tienda de moda belga había lanzado la mayor promoción del año, respaldada por semanas de campañas de correo electrónico, colaboraciones con influencers y publicidad de pago. El tráfico se disparó exactamente como estaba previsto y su tienda PrestaShop se cayó por completo en la primera hora. Los clientes que pulsaban anuncios cuidadosamente preparados se encontraban con páginas de error en lugar de las ofertas por tiempo limitado que se les habían prometido. El sitio se recuperaba un momento, servía un puñado de páginas y volvía a caer cuando las peticiones en cola saturaban la capacidad que acababa de quedar libre. Cuando nos contactaron, ya habían perdido más de €40,000 en ventas previstas y las horas de compra más intensas del año se estaban agotando. Su proveedor de hosting insistía en que los servidores estaban bien. Su desarrollador anterior no cogía el teléfono. La inversión en marketing se evaporaba en tiempo real.

→ ¿Te enfrentas a una emergencia de rendimiento? Nuestro equipo responde de inmediato

Los síntomas que describían apuntaban a un fallo en la capa de base de datos: el patrón concreto de una recuperación parcial seguida de un nuevo colapso, que indica agotamiento de conexiones y no una simple saturación de recursos. Con tráfico normal, su configuración de MySQL soportaba sin problemas una base modesta de usuarios simultáneos. Pero el tráfico del Black Friday multiplicó por cincuenta los visitantes a la vez, y cada visitante generaba varias consultas a la base de datos para productos, operaciones del carrito y gestión de sesiones. El límite configurado de ciento cincuenta conexiones simultáneas había parecido generoso en las conversaciones de planificación con su desarrollador anterior; bajo la carga real de las fiestas, se agotaba a los pocos minutos de cada recuperación y creaba un ciclo en el que la base de datos aceptaba conexiones un instante, se saturaba de inmediato y rechazaba nuevas peticiones hasta que las conexiones existentes caducaban y se liberaban.

El entorno de hosting añadió complicaciones que alargaron el tiempo de resolución. Habían elegido un proveedor de hosting gestionado precisamente por la comodidad de no tener que ocuparse de nada, pero esa simplicidad significaba que no había acceso por SSH, que no se podía modificar la configuración de MySQL directamente y que los tiempos de respuesta del soporte se medían en horas durante el propio pico de soporte del Black Friday de su proveedor. Los ajustes de rendimiento de PrestaShop que podíamos cambiar desde la configuración de administración —caché, compilación, modo de depuración— ya estaban bien configurados. La propia base de datos estaba razonablemente optimizada: su desarrollador anterior había implantado las rutinas de limpieza habituales. El problema estaba en la capa de infraestructura, en configuraciones que su entorno de hosting les impedía modificar a propósito.

→ No esperes al Black Friday para descubrir los límites de tu infraestructura

Nuestra intervención de emergencia se desarrolló en dos vías paralelas. Primero, implementamos una gestión inmediata del tráfico para reducir la carga de la base de datos y, al mismo tiempo, preservar la capacidad de ventas al máximo. Se implementaron versiones estáticas de las páginas de productos críticas en los servidores perimetrales de la CDN, lo que permitió a los clientes explorar los artículos promocionales clave incluso mientras las operaciones dinámicas seguían estancadas. Se priorizó la funcionalidad del carrito y el pago mediante el enrutamiento de solicitudes, que dirigía las conexiones limitadas de la base de datos hacia operaciones críticas para la conversión en lugar de hacia la navegación. Las operaciones administrativas se bloquearon por completo para evitar que la actividad del personal consumiera las conexiones necesarias para las compras de los clientes. Estas medidas permitieron que la tienda funcionara con capacidad reducida, lo cual no era ideal, pero generó ventas en lugar de solo errores.

La segunda vía abordó las causas raíz mediante la escalada de la infraestructura. En colaboración con el equipo de escalada de emergencia del proveedor de alojamiento, negociamos cambios temporales de configuración que aumentaron el número máximo de conexiones a la base de datos y los procesos de trabajo PHP por encima de sus límites estándar. Se amplió la asignación de memoria para los procesos PHP para evitar el agotamiento de la memoria que había contribuido a los fallos en cascada. A primera hora de la tarde, aproximadamente cuatro horas después del fallo inicial, la tienda se había estabilizado a plena capacidad, con la infraestructura reconfigurada temporalmente para gestionar el tráfico que generaba su promoción. Las ventas se reanudaron con un volumen que, si bien fue inferior al que se habría obtenido con una jornada completa, permitió recuperar ingresos significativos de lo que parecía una pérdida total.

El análisis posterior reveló una infraestructura que nunca se había dimensionado de verdad para el tráfico que el equipo de marketing era capaz de generar. Su hosting de PrestaShop había bastado para el día a día y para picos promocionales modestos, pero las campañas grandes se apoyaban en supuestos de capacidad que nadie había validado con pruebas de carga. El límite de ciento cincuenta conexiones a la base de datos soportaba aproximadamente cien visitantes simultáneos con sus patrones de consulta, muy por debajo de los miles que atraería una campaña de Black Friday con éxito. La memoria asignada en su plan de hosting no podía sostener el número de workers de PHP necesario para una alta concurrencia. Esas limitaciones permanecían invisibles en el funcionamiento normal y solo salían a la luz de forma catastrófica cuando el marketing lograba exactamente la escala hacia la que habían estado trabajando.

La solución que implantamos para las temporadas siguientes abordó estas vulnerabilidades con una arquitectura pensada para la capacidad punta y no para cubrir solo lo básico. La infraestructura de base de datos se migró a un hosting MySQL dedicado, con límites de conexión acordes a sus ambiciones de tráfico. Los servidores web quedaron detrás de un balanceo de carga capaz de escalar en horizontal durante los periodos promocionales. Se implantó caché con Redis para reducir el volumen de consultas a la base de datos en un ochenta por ciento, y la capacidad efectiva creció de forma notable. Las pruebas de carga confirmaron que la nueva arquitectura sostenía diez mil usuarios simultáneos sin degradación: una capacidad capaz de absorber incluso promociones extraordinariamente exitosas sin que la infraestructura se convirtiera en el factor limitante.

¿Está su tienda preparada para su próxima gran oportunidad?

Los €40,000 en ventas perdidas del Black Friday que sufrió este comercio representan solo el daño medible de forma directa: los ingresos de los visitantes que intentaron comprar durante esas horas de caída. Los costes no medidos incluyen relaciones con clientes dañadas por las páginas de error, una reputación de marca afectada por las quejas en redes sociales y una inversión publicitaria desperdiciada en tráfico que recibió fallos en lugar de una experiencia de compra. Toda tienda PrestaShop que planifica una actividad promocional importante corre un riesgo parecido si la infraestructura no se ha validado frente al tráfico punta esperado. La pregunta no es si conseguirás atraer tráfico: tu equipo de marketing trabaja exactamente hacia ese resultado. La pregunta es si tu infraestructura convertirá ese tráfico en ventas o en un caso de estudio sobre lo que ocurre cuando la preparación no está a la altura de la ambición.

→ Valida tu infraestructura antes de tu próxima campaña