Casos de Producción
Incidentes que colapsaron sistemas en producción. Levantas el stack vulnerable, reproduces el escenario exacto y construyes la solución desde cero.
Curso intensivo · en vivo · 4 sábados · 18 h
Ticketmaster Eras Tour · 18 noviembre 2022
¿Qué es un Caso de Producción?
Cada caso sigue este flujo completo, de teoría a post-mortem. Es la secuencia que se vive en producción cuando algo se rompe — aquí el ambiente es controlado y cada fase es evaluada.
Conceptos técnicos del incidente y de la solución. Sin esto, no entiendes el porqué de cada etapa — son los programadores que ya hoy está reemplazando la IA.
Stop-the-bleed: parche inmediato en los primeros 15–30 minutos del incidente — contención, no solución final. Lees Grafana, identificas el servicio afectado y aplicas la mitigación antes de diseñar la solución correcta.
Llegas a la causa raíz, diseñas la arquitectura de la solución y la documentas antes de tocar código.
Implementas la solución y abres el PR. El código pasa por code review antes del merge — el mismo estándar que aplica un equipo Senior en producción.
Re-ejecutas el ataque con la solución implementada activa y validas que Grafana muestre métricas sanas. Si no se sanan, regresas al diseño.
Causa raíz, decisiones técnicas, métricas pre/post y propuestas adicionales. Checkpoint evaluado al cierre.
Al terminar el laboratorio vas a poder
System design
Resuelves rounds de system design que usan incidentes reales como caso de estudio.
Incident response
Diagnosticas y respondes a incidentes en producción con criterio técnico aplicado.
Post-mortem
Lees y escribes post-mortems técnicos — entiendes los públicos de Stripe o Cloudflare y documentas los tuyos de la misma manera.
Criterio técnico
Construyes la base del criterio para identificar la causa raíz y proponer la solución técnica — sobre un caso real, con metodología que puedes aplicar al siguiente incidente.
● Disponible ahora
Experiencia inmersiva
Antes de comprar, mira
Ver el incidente Taylor Swift
Te lleva por el incidente paso a paso: timeline del ataque, métricas que se disparan y la lógica de las defensas explicadas.
El incidente
En noviembre de 2022, la preventa del Eras Tour tenía 2.4 millones de fans verificados en lista de espera. El sistema no tenía rate limiting por IP, no distinguía bots de usuarios reales y no tenía cola virtual. Resultado: 14 millones de requests concurrentes saturaron los pods de checkout en los primeros 90 segundos. El circuit breaker nunca se activó. Los bots consumieron el inventario antes de que un solo fan pudiera comprar.
14M
req / 90s
2.4M
fans en cola
0
tickets servidos
Stack que levantas
Conceptos que implementas
Lo que vas a poder hacer al terminar
¿Prefieres trabajarlo por tu cuenta?
El mismo escenario se practica como entregable en la Academia: Laboratorio 03 · La Venta del Año, con evaluación y repositorio propio.
Ir a LaboratoriosCasos próximos
Cada uno reproduce un incidente real. Suscríbete a la comunidad WhatsApp para enterarte cuando uno se libera.
DDoS simulado — defensa en 5 capas en producción real
Mientras tanto, el mismo tema se practica como entregable evaluado en Laboratorio 04 · El Ataque.
Ir al laboratorioEl bug que le cuesta millones a empresas reales
Mientras tanto, el mismo tema se practica como entregable evaluado en Laboratorio 02 · El Doble Cobro.
Ir al laboratorioLa API responde 200 pero el usuario ve 8 segundos de spinner
Mientras tanto, el mismo tema se practica como entregable evaluado en Laboratorio 01 · La API Lenta.
Ir al laboratorioEl 60% de los ataques internos vienen de ex-empleados
Mientras tanto, el mismo tema se practica como entregable evaluado en Laboratorio 05 · El Enemigo Interno.
Ir al laboratorioPreguntas frecuentes