Cada año la historia se repite: tiendas online que funcionan sin problemas durante once meses se caen precisamente el día que más visitas, más pedidos y más facturación concentran. El Black Friday no perdona: un pico de tráfico de 5x o 10x sobre tu media habitual expone cada cuello de botella que tu plataforma ha ido acumulando en silencio. Y lo peor no es la caída en sí, sino el momento: cada minuto de inactividad durante el pico puede suponer miles de euros en ventas perdidas y clientes que se van directos a la competencia con la tarjeta en la mano.
La buena noticia es que las caídas del Black Friday casi nunca son mala suerte. Son el resultado predecible de no haber hecho los deberes técnicos con suficiente antelación. Un servidor que aguanta 200 usuarios concurrentes no va a aguantar 2.000 por mucho que cruces los dedos, y descubrirlo el 27 de noviembre a las 00:15 es la forma más cara posible de enterarte.
Por eso este artículo se publica en verano y no en noviembre. Preparar el Black Friday de una tienda online es un proyecto técnico de tres a cuatro meses, no un checklist de última hora. En esta guía repasamos, con calendario incluido, todo lo que tu plataforma necesita: test de carga, escalado de infraestructura, estrategia de caché por capas, optimización del checkout, protección frente a bots y un plan de contingencia real para cuando algo, inevitablemente, se tuerza. Da igual si vendes con WooCommerce, PrestaShop, Shopify o un desarrollo a medida: los principios son los mismos y las consecuencias de ignorarlos, también.
1. Por qué el Black Friday se gana en verano
Existe una asimetría fundamental en la preparación técnica de un pico de tráfico: casi todas las medidas eficaces requieren semanas o meses de antelación, mientras que las medidas de última hora apenas arañan mejoras marginales. Migrar de servidor, reestructurar la caché, optimizar consultas SQL pesadas o renegociar límites con tu pasarela de pago no son tareas de una tarde. Si empiezas en octubre, llegarás tarde a casi todo lo importante.
Hay además un motivo operativo: los proveedores también se saturan. Los equipos de hosting gestionado reciben avalanchas de peticiones de escalado en octubre y noviembre, las agencias de desarrollo tienen los calendarios llenos y las pasarelas de pago tardan más en atender solicitudes de aumento de límites. Quien reserva capacidad en julio o agosto negocia con calma; quien lo hace en noviembre suplica.
Y un motivo estadístico: para saber cuánto tráfico esperar necesitas analizar tus datos históricos con tiempo. ¿Cuál fue tu pico del año pasado? ¿Qué ratio de conversión tuviste durante la campaña? ¿Qué páginas concentraron el tráfico? Con esos datos puedes dimensionar el objetivo del test de carga de forma realista: la regla habitual es prepararse para entre 3 y 5 veces el pico del año anterior, porque las campañas crecen y porque el margen de seguridad es más barato que la caída.
2. Auditoría de partida: conoce tus límites antes de que los descubra el tráfico
Todo plan serio empieza midiendo. No puedes escalar lo que no conoces, y la mayoría de tiendas online no sabe cuántos usuarios concurrentes aguanta su plataforma antes de degradarse. La primera fase, idealmente unas 16 semanas antes de la campaña, consiste en una auditoría técnica completa que responda a tres preguntas: dónde está el límite actual, qué componente cede primero y cuánto cuesta ampliarlo.
2.1 Test de carga realista
Un test de carga útil no consiste en lanzar peticiones a la home. Consiste en simular recorridos completos de compra: entrada por una landing de campaña, navegación por categoría, búsqueda interna, ficha de producto, añadir al carrito, iniciar checkout y pagar. Herramientas como k6, Gatling o JMeter permiten programar estos escenarios con distribuciones realistas (por ejemplo, 70% navegación, 20% carrito, 10% checkout) y subir la concurrencia por escalones hasta encontrar el punto de ruptura.
Los errores clásicos al testear: hacerlo contra un entorno de staging con la mitad de recursos que producción (los números no extrapolan), testear con la caché caliente cuando el Black Friday te la va a invalidar constantemente con cambios de precios y stock, y olvidar los servicios externos. Tu plataforma puede aguantar, pero ¿aguanta tu buscador, tu motor de recomendaciones, tu ERP sincronizando stock? Cada integración externa es un punto de fallo que también hay que estresar. Si tu tienda expone APIs propias, revisa además su autenticación y rate limiting, porque un pico de tráfico legítimo se parece mucho a un abuso si no has definido límites correctos.
2.2 Las métricas que importan
Del test de carga deben salir números concretos: usuarios concurrentes soportados con tiempos de respuesta aceptables (p95 por debajo de 1,5-2 segundos en páginas de catálogo y del orden de 3 segundos en checkout), throughput máximo de pedidos por minuto, consumo de CPU y memoria en cada capa, y tiempo de respuesta de la base de datos bajo presión. Estos valores son tu línea base: todo el trabajo de las semanas siguientes se mide contra ellos. Conviene también auditar el rendimiento percibido con métricas de usuario real, porque la velocidad no solo sostiene la conversión durante el pico: es un factor de posicionamiento que trabajamos en detalle en nuestra guía de SEO técnico para ecommerce.
3. Infraestructura: escalar antes, no durante
Con la línea base clara, toca ampliar capacidad. La regla de oro: todo escalado debe estar hecho y probado al menos cuatro semanas antes de la campaña. Escalar en caliente durante el pico es posible en algunas arquitecturas, pero improvisarlo el mismo día es apostar la facturación del año a que nada sale mal en la maniobra más delicada.
3.1 Hosting y autoscaling
Si estás en cloud (AWS, Google Cloud, Azure o equivalentes), configura grupos de autoscaling con políticas basadas en CPU y en latencia, y sobre todo pre-calienta capacidad: el autoscaling reactivo tarda minutos en levantar instancias nuevas, y en un pico agresivo esos minutos son la diferencia entre degradarse y caerse. Para las horas críticas (medianoche del jueves al viernes, mediodía del viernes, Cyber Monday) programa el escalado por calendario, no por métrica. Si estás en un servidor dedicado o VPS tradicional, habla con tu proveedor en septiembre como tarde: ampliaciones de RAM, CPU o migraciones a máquinas mayores necesitan ventana de mantenimiento planificada. La elección de plataforma también condiciona el techo de escalado, algo que analizamos al comparar opciones en nuestra guía para elegir plataforma ecommerce.
3.2 PHP-FPM y capa de aplicación
En plataformas PHP (WooCommerce, PrestaShop, Magento), la configuración del pool de PHP-FPM marca la diferencia entre aprovechar el hardware y desperdiciarlo. Un pm.max_children demasiado bajo deja CPU ociosa mientras los usuarios hacen cola; demasiado alto provoca swapping y degrada todo. El cálculo correcto parte de la memoria media por proceso y de la RAM disponible, y lo explicamos paso a paso en nuestra guía de optimización de PHP-FPM y OPcache. Revisa también OPcache (que quepa todo el código en memoria, con opcache.validate_timestamps desactivado en producción) y elimina plugins o módulos que no uses: cada uno añade consultas y milisegundos que en el pico se multiplican por miles.
3.3 Base de datos
La base de datos es casi siempre el componente que cede primero, porque es el más difícil de escalar horizontalmente. Antes de la campaña: identifica y optimiza las consultas lentas (el slow query log es tu amigo), añade los índices que falten en tablas de productos, pedidos y sesiones, y valora una réplica de lectura para separar el tráfico de catálogo (lecturas masivas) del transaccional (escrituras de pedidos). En WooCommerce, además, vigila la tabla de opciones con autoload y las sesiones en base de datos, dos clásicos que degradan el rendimiento bajo carga; nuestro análisis de WooCommerce en 2026 repasa dónde está hoy el techo real de la plataforma.
4. Caché y CDN: la defensa en capas
El principio más rentable de toda la preparación: la petición más barata es la que nunca llega a tu servidor. Una estrategia de caché bien diseñada consigue que el 80-90% del tráfico del Black Friday se resuelva sin ejecutar ni una línea de PHP ni una consulta SQL. Se construye por capas, de fuera hacia dentro.
Primera capa, el navegador: cabeceras cache-control agresivas para assets estáticos versionados. Segunda, el CDN: no solo imágenes, CSS y JavaScript; con la configuración adecuada también HTML completo de páginas que no dependen de sesión. Tercera, caché de página completa en el origen (Varnish o FastCGI cache de Nginx) para servir HTML renderizado a usuarios anónimos, que en campaña son la inmensa mayoría. Cuarta, caché de objetos con Redis o Memcached para consultas repetidas, sesiones y fragmentos de catálogo. Y al fondo, la aplicación y la base de datos, que solo deberían ejecutar lo estrictamente dinámico: carrito, checkout, stock en tiempo real.
El punto delicado en ecommerce es la invalidación: precios que cambian a medianoche, stock que se agota en minutos. Diseña purgas selectivas por producto o categoría (nunca purga total en plena campaña, que provoca una estampida contra el origen), define TTLs cortos pero no nulos para el catálogo (30-60 segundos absorben muchísimo tráfico sin mostrar datos viejos) y prueba la estampida de caché en el test de carga: qué pasa cuando expira la caché de tu landing principal con 2.000 usuarios dentro.
¿Tu tienda aguantará el Black Friday?
En Keliam auditamos, escalamos y mantenemos plataformas ecommerce para que el pico del año sea una oportunidad y no un incidente: test de carga, optimización de infraestructura, caché y soporte durante la campaña.
5. Checkout y pagos: donde se gana o se pierde el dinero
Puedes permitirte que una página de categoría tarde un segundo más. Lo que no puedes permitirte es que falle el checkout, porque ahí cada error es un pedido perdido con intención de compra ya formada. El checkout merece su propio plan.
Primero, simplifica: cada campo innecesario, cada validación lenta y cada llamada externa síncrona en el flujo de pago es fricción y riesgo. Revisa qué scripts de terceros se cargan en el checkout (chat, analítica, píxeles de marketing) y difiere o elimina los que no sean imprescindibles: son el sospechoso habitual cuando el checkout se arrastra bajo carga.
Segundo, habla con tu pasarela de pago antes de la campaña. Las pasarelas aplican límites de peticiones por segundo y sistemas antifraude que, ante un pico repentino de transacciones, pueden interpretar tu mejor día del año como un ataque. Avisa a tu proveedor de las fechas y volúmenes esperados, confirma límites y pide contacto de soporte prioritario. Ten además una pasarela de respaldo configurada y probada: si tu proveedor principal sufre una incidencia global en pleno viernes (ha pasado), poder conmutar en minutos salva la campaña.
Tercero, gestiona la concurrencia de stock: con cientos de compradores disputándose las últimas unidades de una oferta, los sistemas ingenuos venden stock inexistente o bloquean tablas enteras. Reservas de stock con expiración al añadir al carrito, decrementos atómicos y colas para operaciones de escritura son patrones que evitan tanto el overselling como los deadlocks. Y si esperas un pico extremo en un lanzamiento concreto, valora una sala de espera virtual: es mejor que un cliente espere 90 segundos con una barra de progreso a que reciba un error 500.
6. Seguridad: los bots también hacen Black Friday
El pico de tráfico legítimo llega acompañado de tráfico hostil que conoce el calendario tan bien como tú. Durante la campaña se disparan tres amenazas concretas: el scraping agresivo de precios por parte de competidores y agregadores, que puede suponer un porcentaje absurdo de tu tráfico de catálogo; el carding, que aprovecha el volumen de transacciones para probar tarjetas robadas camufladas entre pedidos reales; y los ataques DDoS oportunistas, a veces con extorsión incluida, porque los atacantes saben que en esas fechas cada hora de caída duele el triple.
Las defensas hay que dejarlas afinadas antes: un WAF con reglas específicas de ecommerce, rate limiting por IP y por sesión en endpoints sensibles (login, búsqueda, carrito, checkout), protección bot del CDN activada en modo desafío para patrones anómalos, y monitorización de ratios de autorización de pagos para detectar carding en minutos. Cuidado con pasarse de agresivo: una regla antibots mal calibrada que bloquee compradores reales es un incidente tan caro como un ataque. Prueba las reglas con tráfico real semanas antes. Si tu tienda corre sobre WordPress, nuestra guía de seguridad WordPress para empresas detalla el endurecimiento base sobre el que construir estas protecciones.
7. Feature freeze y plan de contingencia
Las últimas cuatro semanas antes de la campaña cambian las reglas del juego: el objetivo ya no es mejorar la plataforma sino no romperla. Se declara el feature freeze: nada de despliegues nuevos salvo hotfixes críticos, nada de actualizar plugins, módulos o dependencias, nada de experimentos. La estadística es tozuda: una parte enorme de los incidentes en producción viene de cambios recientes, y la semana del Black Friday es el peor momento imaginable para estrenar código.
En paralelo se prepara el runbook de contingencia: un documento operativo, ensayado, que responda a «¿qué hacemos si…?». Si se degrada el rendimiento: activar el modo catálogo ligero (desactivar recomendaciones, búsquedas facetadas y todo lo prescindible) que habrás dejado preparado tras un feature flag. Si cae la pasarela principal: conmutar a la de respaldo con el procedimiento documentado. Si cae la base de datos: promover la réplica. Si todo lo demás falla: una página estática de cortesía servida desde el CDN, con la marca cuidada, que capture emails para avisar cuando vuelva el servicio. Cada escenario con responsable, pasos concretos y criterio de activación.
Y durante la campaña, war room: dashboards en tiempo real (tráfico, latencias, tasa de error, pedidos por minuto, autorizaciones de pago), alertas con umbrales ajustados a los volúmenes esperados y turnos de guardia definidos, con los teléfonos del hosting, la pasarela y la agencia a mano. No hace falta un equipo enorme; hace falta saber quién mira qué y quién decide. Los backups, por supuesto, verificados y con restauración probada esa misma semana: un backup que nunca se ha restaurado es una hipótesis, no una garantía, como recordamos siempre al hablar de ransomware y continuidad de negocio.
Conclusión: el mejor Black Friday es el aburrido
Un Black Friday técnicamente exitoso es aquel en el que el equipo de guardia se aburre: los dashboards en verde, el autoscaling absorbiendo olas, el checkout convirtiendo y el runbook sin estrenar. Ese aburrimiento no es suerte: es el dividendo de un trabajo que empezó dieciséis semanas antes con una auditoría honesta, siguió con escalado y caché bien diseñados, y terminó con un freeze disciplinado y un plan B para cada pieza crítica.
La inversión, además, no caduca el Cyber Monday: todo lo que hagas para el Black Friday (infraestructura dimensionada, caché por capas, consultas optimizadas, monitorización, runbook) mejora tu plataforma los 365 días del año, reduce costes de incidencias y te deja lista la Navidad, las rebajas de enero y cualquier campaña futura. Empieza ahora, en verano, y noviembre será un trámite rentable en lugar de una ruleta rusa.
Preguntas frecuentes
¿Cuándo hay que empezar a preparar el Black Friday de una tienda online?
Idealmente entre 14 y 16 semanas antes, es decir, entre julio y agosto. Las tareas de mayor impacto (test de carga, escalado de infraestructura, rediseño de caché, optimización de base de datos) requieren semanas de trabajo y ventanas de prueba. A partir de cuatro semanas antes solo deberían quedar verificaciones y el plan de contingencia.
¿Cuánto tráfico adicional debo esperar durante el Black Friday?
Depende del sector y de la agresividad de tu campaña, pero la referencia habitual es dimensionar para 3-5 veces el pico del año anterior. Analiza tus datos históricos de analítica y pedidos: el objetivo del test de carga debe salir de tus números, no de medias del sector.
¿Qué hago si mi tienda se cae en pleno Black Friday?
Ejecutar el runbook, no improvisar: activar el modo degradado (desactivar funcionalidades prescindibles), escalar capacidad si la maniobra está preparada, conmutar pasarela o base de datos si el fallo está ahí, y como último recurso servir la página estática de cortesía desde el CDN mientras se recupera el servicio. Si no tienes runbook, esa es exactamente la razón para prepararlo con antelación.
