Preparación para Black Friday: planificación de capacidad y escenarios de prueba de carga que importan

Tu prueba de carga del homepage pasó a 2.000 req/s—y checkout igual colapsó a las 11:00 cuando salieron los códigos de cupón. Los picos retail castigan rutas write-heavy: mutaciones de carrito, locks de inventario, callbacks de pago y checks de fraude compiten por las mismas filas de base de datos. Scripts que solo martillan el sitio de marketing cuentan una historia reconfortante mientras el camino de ingresos queda sin probar.

La preparación para Black Friday es un problema de mezcla: ratios navegación-a-compra, sesiones autenticadas con carritos calientes y latencia de pagos de terceros que los sandbox suelen ignorar. En esta guía modelarás escenarios k6 en paralelo que reflejan porcentajes reales del funnel, etiquetarás métricas por etapa del journey y definirás umbrales que le importan a liderazgo—no un p95 aislado de búsqueda en catálogo anónimo.

Por qué los picos de ecommerce rompen superficies distintas al tráfico de marketing

Homepage y assets cacheados en CDN escalan horizontalmente. Checkout no:

• Contención de inventario — dos usuarios por el último SKU golpean la misma fila; los locks hacen cola bajo tráfico spike.
• Estado de carrito — escrituras autenticadas estresan session stores y gateways distinto que GETs anónimos.
• Saltos de pago — latencia del PSP y reintentos de webhooks suman segundos en la cola aunque tu API sea «rápida» (APIs de terceros).
• Ráfagas promo — validación de cupones dispara reglas extra y escrituras de auditoría en una ventana estrecha.

Piensa en el tráfico pico como la salida de un estadio: la concourse (browse) fluye hasta que todos golpean las mismas puertas estrechas (checkout) a la vez (stress vs carga vs spike).

Cuando la latencia de búsqueda se ve bien pero los ingresos fallan

Liderazgo lee conversión de checkout, errores de pago y duplicación de pedidos—no medianas de búsqueda en catálogo. Las pruebas de carga deben etiquetar etapas del funnel y poner umbrales en los caminos que mapean a ingresos (cómo leer reportes).

Implementación práctica en k6: mezcla browse-to-buy con etapa spike

Modela browse, carrito y checkout como escenarios paralelos con tasas del analytics del Black Friday anterior—o pronósticos de merchandising si es storefront nuevo. Agrega una etapa spike corta antes del hold para simular minutos doorbuster.

Script de ejemplo (ilustrativo—no listo para producción). URLs, SKUs y tasas ficticias; adapta a tu funnel.

Qué demuestra este ejemplo:

• Mezcla realista: browse 60 req/s, carrito 25 req/s, checkout 15 req/s (split ~60/25/15).
• Tags de etapa (journey:browse, journey:checkout) para umbrales por funnel.
• Ejecutor spike que sube checkout a 40 req/s cinco minutos a mitad de corrida.
• Delay de sandbox de pago simulado vía sleep configurable por env tras POST checkout.

import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging-shop.example.com';
const TOKEN = __ENV.AUTH_TOKEN;

export const options = {
  scenarios: {
    browse: {
      executor: 'constant-arrival-rate',
      rate: 60,
      timeUnit: '1s',
      duration: '20m',
      preAllocatedVUs: 30,
      maxVUs: 120,
      tags: { journey: 'browse' },
      exec: 'browseCatalog',
    },
    cart_updates: {
      executor: 'constant-arrival-rate',
      rate: 25,
      timeUnit: '1s',
      duration: '20m',
      preAllocatedVUs: 15,
      maxVUs: 60,
      tags: { journey: 'cart' },
      exec: 'updateCart',
    },
    checkout_steady: {
      executor: 'constant-arrival-rate',
      rate: 15,
      timeUnit: '1s',
      duration: '20m',
      preAllocatedVUs: 20,
      maxVUs: 80,
      tags: { journey: 'checkout' },
      exec: 'checkoutFlow',
    },
    checkout_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 15,
      timeUnit: '1s',
      stages: [
        { duration: '10m', target: 15 },
        { duration: '5m', target: 40 },
        { duration: '5m', target: 15 },
      ],
      preAllocatedVUs: 25,
      maxVUs: 100,
      tags: { journey: 'checkout', phase: 'spike' },
      exec: 'checkoutFlow',
      startTime: '0s',
    },
  },
  thresholds: {
    'http_req_duration{journey:checkout}': ['p(95)<1500', 'p(99)<2500'],
    'http_req_duration{journey:browse}': ['p(95)<600'],
    http_req_failed: ['rate<0.02'],
  },
};

export function browseCatalog() {
  const res = http.get(`${BASE}/v1/catalog?category=deals&page=1`, {
    tags: { journey: 'browse' },
  });
  check(res, { 'browse 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.5);
}

export function updateCart() {
  const body = JSON.stringify({ sku: 'DEAL-42', qty: 1 });
  const res = http.post(`${BASE}/v1/cart/items`, body, {
    headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${TOKEN}` },
    tags: { journey: 'cart' },
  });
  check(res, { 'cart 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.3);
}

export function checkoutFlow() {
  const body = JSON.stringify({ cartId: 'cart-demo', paymentMethod: 'sandbox' });
  const res = http.post(`${BASE}/v1/checkout`, body, {
    headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${TOKEN}` },
    tags: { journey: 'checkout' },
  });
  check(res, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(Number(__ENV.PSP_DELAY_SEC || 0.8));
}

Patrones que funcionan

• Sesiones autenticadas calientes con payloads de carrito realistas—no POST bodies vacíos.
• Etapa spike solo en checkout mientras browse se mantiene—refleja minutos promo (tráfico festivo ecommerce).
• Umbrales separados por journey para que browse verde no oculte checkout rojo.
• Ventanas de prueba declaradas con ops on-call—carga no declarada sigue provocando incidentes (ética de pruebas).

Antipatrones a evitar

• Scripts solo de homepage antes del sign-off de temporada pico.
• Ignorar slowdowns del sandbox de pagos—la latencia del PSP en producción domina las colas.
• Correr spike tests sin datos de inventario seed—resultados de contención no reproducen.

Pro tip (comando de ejemplo):

k6 run black-friday-mix.js --summary-trend-stats="p(95),p(99)" -e PSP_DELAY_SEC=1.2

Qué demuestra este comando: stats de cola por tag de journey exponen regresión de checkout durante la etapa spike de cinco minutos.

Marco de decisión: mezcla de escenario vs forma de pico

Usa escenarios paralelos estables si necesitas línea base de regresión entre cambios de copy de merchandising.

Agrega etapa spike si marketing confirma ráfagas por minuto (doorbusters, drops de email).

Bloquea sign-off de pico si p99 o http_req_failed de checkout violan umbrales durante spike—aunque browse siga verde.

Observabilidad, documentación y próximos pasos

La preparación para pico es un ensayo operativo, no solo un exit code de k6:

• Documenta porcentajes del funnel y fuente de datos (analytics BF anterior o pronóstico).
• Asigna contactos de abort y monitores de profundidad de cola antes de corridas largas.
• Correlaciona tags journey:checkout con dashboards del proveedor de pagos durante pruebas.
• Rastrea duplicación de pedidos y fallos de idempotencia como métricas custom si hay riesgo de ingresos.
• Archiva JSON de escenario y git SHA por ensayo general (planificación de capacidad desde k6).

Cómo Performate simplifica pruebas de carga para Black Friday

Merchandising cambia copy semanalmente; forks de scripts no sobreviven noviembre. Abajo un flujo concreto para escenarios browse + carrito + checkout—adapta tasas a tu funnel.

Ejemplo: iterar mezcla pico 60/25/15 sin proliferación de scripts

1. Importa colecciones Postman para paths checkout mobile y web (GET browse, POST carrito, POST checkout). Problema resuelto: una fuente de verdad cuando merchandising actualiza endpoints.
2. Crea tres escenarios paralelos en el editor—browse 60 req/s, carrito 25 req/s, checkout 15 req/s—con tags journey:browse, journey:cart, journey:checkout. Problema resuelto: mezcla honesta del funnel sin editar cuatro archivos a mano.
3. Agrega overlay spike en checkout: ramp a 40 req/s cinco minutos a mitad de corrida. Problema resuelto: ensayo doorbuster es cambio de parámetro, no repo nuevo.
4. Define umbrales de checkout (p95 < 1500 ms, fallos < 2 %) en la UI y corre el ensayo general de 20 minutos. Problema resuelto: liderazgo lee el mismo reporte que ingeniería.
5. Compara corridas semana a semana en la vista integrada mientras cambian reglas de cupón y tamaño de catálogo. Problema resuelto: regresiones visibles antes del code freeze.
6. Exporta script k6 para smoke nocturno CI solo en paths checkout tras merges de integración.

Ese flujo coincide con el cta de este post: corre, ajusta y reporta escenarios de pico desde una app de escritorio mientras el calendario comprime hacia Black Friday.

Cierre

La preparación para Black Friday es un problema de checkout y pagos disfrazado de gráfico de tráfico. Modela mezclas browse-to-buy, haz spike de checkout por separado y pon umbrales en los journeys que llevan ingresos—no hits de vanidad al homepage.

Corre esta semana la mezcla del funnel contra staging antes de que merchandising congele copy—y anota si la cola de latencia de checkout sobrevive el spike de cinco minutos que disparará tu email promo.

Try Performate free | Patrones de tráfico festivo | k6 thresholds