Todos los proyectos
visualización · sistemas · AWS
Request Journey 3D
Qué pasa desde que escribes una URL hasta que responde la base de datos, en 3D: DNS, CDN, balanceador, servidores, Redis y BD, con unas DevTools tipo Chrome. Incluye escenarios con averías típicas de producción: N+1, Redis caído, CORS, 429…
Qué es
Un proyecto para entender (y enseñar) el recorrido completo de una petición web en una arquitectura típica de AWS, juntando los dos mundos en los que me muevo: el desarrollo web y la infraestructura.
No es una animación pregrabada: un simulador calcula qué le pasa a cada petición en cada equipo, y la escena 3D solo reproduce ese resultado.
Qué incluye
- Infraestructura realista: DNS (Route 53), CDN (CloudFront) delante de S3, balanceador (ALB) con health checks, dos instancias EC2 con la API, caché Redis (ElastiCache) y base de datos PostgreSQL (RDS).
- Cachés de verdad: caché de disco del navegador, caché DNS, conexiones reutilizadas, HIT/MISS en la CDN con su cabecera
x-cachey Redis con caducidad de 60 s. - DevTools: pestaña Network con la cascada de tiempos (DNS, TCP + TLS, TTFB y descarga), Console con los errores tal como los escribe Chrome y los logs de los servidores con cada consulta SQL.
- Averías: se puede apagar cualquier equipo y activar fallos de código (N+1, CORS, límite de peticiones) desde el panel.
Escenarios guiados
- Primera visita: cachés vacías, consulta DNS, conexión TCP + TLS y MISS en la CDN.
- Segunda visita: todo sale de caché y la carga es más de 3 veces más rápida.
- La web va lenta (N+1): una petición genera 51 consultas; con un JOIN, una sola.
- Se cae Redis: la API sigue respondiendo, pero cada petición va a la base de datos.
- Se cae un servidor: el balanceador devuelve 502 hasta que los health checks lo sacan del reparto.
- Error de CORS y límite de peticiones (429) con
Retry-After.
Cada escenario se comprueba también con tests automáticos que ejecutan el simulador sin navegador.