Test de Carga Checkout: Plantilla Black Friday

El checkout de BFCM falla de forma distinta al resto del año. La fila de inventario que decrementaba a 5 RPS hace deadlock a 500; el tag de terceros que añadía 80ms en octubre añade 2s cuando su CDN se degrada. Esta plantilla carga el funnel tal como lo configura un día de flash-sale — mutación del carrito, init de pago, order-create — no impactos aislados a páginas.

Decremento de inventario bajo concurrencia

El patrón de fila caliente catalog_product_entity + cataloginventory_stock_item de Magento colapsa cuando 2.000 carritos golpean el mismo SKU dentro de una ventana de 30 segundos. La misma historia en stacks que envuelven SELECT ... FOR UPDATE alrededor de la reserva de stock. Martillee un conjunto pequeño de SKUs (10-50 productos) para que la contención aflore — la distribución uniforme sobre un catálogo entero esconde el deadlock. La reserva asíncrona mueve el problema; ahora vigile el lag de reservation-confirm y los oversells.

Los tags de terceros inflan el TTFB del checkout

GTM, FB pixel, un SDK de A/B testing, un tag de session-replay, un beacon de fraud-scoring — todos disparan en la página de checkout, ninguno en su dashboard de latencia. Pruebe la página renderizada, no solo la API: un checkout-init que devuelve en 400ms pero bloquea sobre seis scripts de terceros sigue siendo un checkout de 4 segundos. Quite tags uno a uno entre ejecuciones y vea cómo se mueve el p95.

Envenenamiento de caché del carrito

El endpoint /cart detrás de Cloudflare o Fastly es un clásico pisado en falso: si la cache key omite la cookie de sesión, el carrito de un comprador se sirve al siguiente. Verifique bajo carga — VUs con cookies de sesión únicas en la misma ruta nunca deben ver las líneas de pedido de otro VU. La misma trampa en storefronts de Shopify con lógica edge custom y en Magento sobre Varnish variando por la cabecera equivocada.

No teste contra PSPs en vivo

Stripe Elements, Adyen, Braintree añaden cada uno uno o dos round-trips entre checkout-init y order-confirm. Apuntar tests a PSPs en vivo consume rate limits y marca la cuenta. Mockéelos a latencia equivalente a producción (Stripe p95 ~250ms, Adyen ~400ms) e inyecte 0,5-2% de fallo para ejercitar los caminos de reintento. Verifique que order-create es idempotente: una clave duplicada devuelve el pedido existente, no un segundo. Cobrar dos veces es peor que no cobrar.

Qué tumba carritos legítimos

Timeouts de reglas de fraude que fallan cerrado en vez de fallar abierto, lookups de saldo de gift-card contra un servicio legacy lento, topes de reutilización de cart-token de Shopify devolviendo 429 bajo ráfaga, salas de queue-it liberando más de lo que el origen absorbe. Todo aflora como "subió la tasa de error de checkout" sin un stack trace limpio. Etiquete cada VU fallido con el subsistema en el que murió.

Objetivos de latencia con sentido

• add-to-cart p95 < 800ms — el abandono sube medible más allá de esto
• checkout-init p99 < 2s — formulario interactivo antes de que el comprador dude
• payment-redirect TTFB < 600ms — salto del gateway antes del redirect al PSP
• order-confirm p99 < 3s — incl. PSP y commit de inventario

Rastree por-paso. Un order-confirm de 4s está bien si 3s son del PSP; un incendio si 3s son de su código.

Cómo ejecutarla

La plantilla viene en modos JMeter y k6. Ejecute desde LoadFocus a través de las 26+ regiones cloud — la latencia Sídney-a-us-east-1 es la experiencia real del comprador. Miles de VUs escalados en pasos de 5 minutos para que los pools de BD y los autoscalers se estabilicen. Conéctelo al CI (Jenkins, GitHub Actions, CircleCI) y falle los builds por regresión de p99 contra el baseline. Ejecútelo antes del email de marketing, no después.