📋 Resumen ejecutivo — los 20 casos en una pagina#

Vista de portafolio para evaluadores no tecnicos (reclutadores, lideres de producto, finanzas, CTO sin tiempo). Cada caso resume problema → valor de negocio → evidencia reproducible → link al detalle tecnico.

Esta pagina no reemplaza el catalogo tecnico generado ni los README.md por caso — los complementa con un foco editorial: que problema de negocio resuelve cada caso y que evidencia deja en pocos minutos.

Fuente de verdad: shared/catalog/cases.json. Los textos de esta pagina derivan de ahi, curados para lectura ejecutiva.

🧭 ¿Sin base tecnica? Empeza por ¿Que es esto? — explicacion en lenguaje simple.

Mapa rapido#

Los 20 casos estan OPERATIVOS en los 7 stacks: PHP/Python/Node.js/Java 21/.NET 8/Go 1.23/Rust 1.83. Detalle de paridad: docs/case-catalog.md.

Caso 01 — API lenta bajo carga#

Categoria: Rendimiento · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. La API responde bien con pocos usuarios, pero degrada latencia y estabilidad al aumentar la concurrencia. Filtros no sargables + patron N+1 + worker concurrente compitiendo por la DB.

Valor. Reduce latencia visible y evita sobredimensionar infra a ciegas — ataca causa raiz, no sintoma.

Evidencia. Compara /report-legacy vs /report-optimized con latencia, p95 y queries promedio sobre la misma data. Worker concurrente refresca tabla resumen sin esconder presion real. Metricas locales + Prometheus/Grafana.

Honestidad. No benchmarkea lenguajes. Demuestra diagnostico y remediacion del problema de latencia bajo carga.

→ Detalle: cases/01-api-latency-under-load/README.md

Caso 02 — N+1 queries y cuellos de botella en DB#

Categoria: Rendimiento · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Demasiadas consultas por solicitud o acceso a datos ineficiente — el clasico N+1 dentro de bucles + relaciones cargadas innecesariamente.

Valor. Reduce round-trips, costo por request y desgaste sobre la DB. Aterriza criterio de acceso a datos mas alla del ORM: el problema no es la herramienta, es el patron de carga.

Evidencia. /orders-legacy vs /orders-optimized sobre la misma base relacional y mismos datos semilla. Mide cantidad de queries y tiempo de DB por request. diagnostics/summary explica por que escala mal.

Honestidad. No representa un ORM especifico. Reproduce el patron real de round-trips repetidos.

→ Detalle: cases/02-n-plus-one-and-db-bottlenecks/README.md

Caso 03 — Observabilidad deficiente y logs inutiles#

Categoria: Observabilidad · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Hay errores, pero no hay trazabilidad para identificar causa raiz rapido. Logs sin correlacion + sin contexto + sin metricas.

Valor. Reduce MTTR. Convierte "el sistema fallo" en "el sistema fallo aqui, por esto, en este request".

Evidencia. checkout-legacy vs checkout-observable — cambia que hay correlacion real, logs estructurados, trazas, metricas y diagnostics/summary para reconstruir incidentes con evidencia. Demostrado en los 3 runtimes sin vender paridad falsa.

Honestidad. No reemplaza una plataforma de tracing distribuido. Si deja base reproducible para mostrar por que logs pobres alargan MTTR.

→ Detalle: cases/03-poor-observability-and-useless-logs/README.md

Caso 04 — Cadena de timeouts y tormentas de reintentos#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Una integracion lenta dispara reintentos sin control → bloqueos → cascadas de fallas entre servicios.

Valor. Reduce fallas en cascada. Ayuda a disenar limites sanos de timeout, retry y backoff con evidencia, no con intuicion.

Evidencia. /quote-legacy vs /quote-resilient sobre el mismo proveedor simulado. Visibiliza el costo de retries agresivos. Circuit breaker con estados leibles via dependency/state, incidents, diagnostics/summary.

Honestidad. No reemplaza una malla de servicios. Reproduce la logica operacional clave: timeouts, retry storm, circuit breaker, fallback.

→ Detalle: cases/04-timeout-chain-and-retry-storms/README.md

Caso 05 — Presion de memoria y fugas de recursos#

Categoria: Rendimiento · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. El sistema acumula memoria, descriptores o conexiones de forma progresiva hasta degradar o caerse. Problemas silenciosos que no fallan de inmediato.

Valor. Razonamiento sobre estabilidad y degradacion progresiva antes del colapso. Discusion sobre limites de recursos y necesidad de reinicios.

Evidencia. /batch-legacy vs /batch-optimized con estado acumulado entre requests. Expone retained_kb, descriptor_pressure, pressure_level en el tiempo. Node mide con process.memoryUsage() (heap V8 + RSS + external), Python con tracemalloc.

Honestidad. No copia al milimetro el modelo de memoria de cada runtime. Si deja visible la senal operacional: crecimiento silencioso → degradacion → necesidad de limpieza.

→ Detalle: cases/05-memory-pressure-and-resource-leaks/README.md

Caso 06 — Pipeline roto y entrega fragil#

Categoria: Entrega · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. El software funciona en dev, pero falla al desplegar, promover o revertir. Drift entre ambientes, secretos perdidos, smoke tests que pasan tarde.

Valor. Reduce riesgo en despliegues. Fortalece rollback, promotion y entrega continua sin teatro de checklists.

Evidencia. /deploy-legacy vs /deploy-controlled sobre los mismos escenarios de riesgo. Visibiliza cuando un pipeline falla tarde y deja el ambiente degradado, versus cuando bloquea en preflight o revierte limpio. environments, deployments, diagnostics/summary.

Honestidad. No reemplaza un CI/CD real ni IaC completo. Reproduce la logica de delivery que importa: validaciones previas, canary, smoke tests, rollback.

→ Detalle: cases/06-broken-pipeline-and-fragile-delivery/README.md

Caso 07 — Modernizacion incremental de monolito#

Categoria: Arquitectura · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. El legacy sigue siendo critico, pero su evolucion es lenta, riesgosa y cara. Cada cambio amenaza con romper algo no relacionado.

Valor. Modernizar sin convertir cada cambio en reescritura. Foco en evolucion segura de sistemas vivos, no greenfield idealizado.

Evidencia. /change-legacy vs /change-strangler sobre shared_schema, billing_change y trabajo paralelo. Mide blast_radius_score, risk_score y progreso de migracion por consumidor. migration/state, flows, diagnostics/summary.

Honestidad. No reemplaza un programa real con multiples servicios y equipos. Reproduce blast radius, migracion por consumidor, contratos, avance incremental.

→ Detalle: cases/07-incremental-monolith-modernization/README.md

Caso 08 — Extraccion de modulo critico sin romper operacion#

Categoria: Arquitectura · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Hay que desacoplar una parte clave, pero esa parte participa en flujos sensibles (checkout, partners, backoffice) y no admite quiebres.

Valor. Extraer un modulo critico sin cortar operacion. Criterio de refactor y separacion de dominios sobre sistemas vivos.

Evidencia. /pricing-bigbang vs /pricing-compatible sobre los mismos consumidores sensibles. Visibiliza compatibility_proxy_hits, contract_tests, progreso de cutover por consumidor. Node usa Proxy nativo para compat de contrato + EventEmitter para eventos de cutover.

Honestidad. No simula un rollout distribuido completo ni feature flags globales. Reproduce la logica clave: proxy de compatibilidad, contratos, cutover gradual.

→ Detalle: cases/08-critical-module-extraction-without-breaking-operations/README.md

Caso 09 — Integracion externa inestable#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Una API externa introduce latencia, errores intermitentes o reglas cambiantes que afectan el sistema propio. No controlamos al tercero.

Valor. Razonamiento de protecciones frente a dependencias externas. Resiliencia realista frente a terceros, no solo manejo local de excepciones.

Evidencia. /catalog-legacy vs /catalog-hardened sobre drift de esquema, rate limit y maintenance window. Visibiliza budget restante, schema mappings, snapshot cacheado. integration/state, sync-events.

Honestidad. No reemplaza una integracion real con DLQ ni proveedores externos verdaderos. Reproduce contratos variables, cuota, cache, adaptacion defensiva.

→ Detalle: cases/09-unstable-external-integration/README.md

Caso 10 — Arquitectura cara para un problema simple#

Categoria: Arquitectura · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. La solucion tecnica consume mas servicios, complejidad y costo del que el problema de negocio realmente necesita. Sobre-ingenieria disfrazada de "estandar".

Valor. Decisiones tecnologicas proporcionales al problema. Criterio para decir no a complejidad innecesaria cuando la situacion pide simplicidad.

Evidencia. /feature-complex vs /feature-right-sized con costo mensual estimado, servicios tocados y lead time. Backlog de simplificacion y coordinacion requerida. architecture/state, decisions. Node mide CPU real como N rondas de JSON.stringify/parse.

Honestidad. No modela una organizacion real ni FinOps completo. Deja visible la tension entre complejidad innecesaria, costo y adecuacion real al problema.

→ Detalle: cases/10-expensive-architecture-for-simple-needs/README.md

Caso 11 — Reportes pesados que bloquean la operacion#

Categoria: Operaciones · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Reporting compite con operacion transaccional y degrada el sistema completo. Aparece tarde y cuesta caro porque no se detecta hasta que ya bloquea ventas.

Valor. Aislamiento de cargas. Reporting deja de degradar la operacion. Conecta datos y operacion en un problema cotidiano.

Evidencia. /report-legacy vs /report-isolated sobre la misma presion operativa. Visibiliza primary_load, lock_pressure, replica_lag_s, queue_depth. Node usa monitorEventLoopDelay() para medir lag real del event loop. /order-write confirma si la operacion conserva aire.

Honestidad. No reemplaza una replica real ni un data warehouse. Reproduce el problema operativo: reporting sobre el primario vs aislamiento de cargas.

→ Detalle: cases/11-heavy-reporting-blocks-operations/README.md

Caso 12 — Punto unico de conocimiento y riesgo operacional#

Categoria: Operaciones · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8

Problema. Una persona o procedimiento concentra tanto conocimiento que el sistema se vuelve fragil ante ausencias o rotacion. Bus factor = 1.

Valor. Continuidad operacional. Reduccion de dependencia critica en personas. Riesgo operacional y sostenibilidad del conocimiento como parte de la calidad del sistema, no solo del codigo.

Evidencia. /incident-legacy vs /incident-distributed sobre owner_absent, night_shift, tribal_script. Visibiliza mttr_min, blocker_count, handoff_quality, bus_factor_min. /share-knowledge muestra como cambia la continuidad al distribuir conocimiento.

Honestidad. No reemplaza una organizacion real ni un programa formal de on-call. Reproduce el riesgo central: memoria tribal, bus factor, continuidad operacional.

→ Detalle: cases/12-single-point-of-knowledge-and-operational-risk/README.md

Caso 13 — Cache stampede y thundering herd#

Categoria: Rendimiento · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. Una clave de cache caliente expira y los N requests que la estaban usando van todos al origen a recalcular el mismo valor. La cache marca 99% de hit rate mientras el sistema se cae en el 1% restante.

Valor. Evita caidas autoinfligidas en la franja horaria mas fragil del sistema y reduce la capacidad reservada del origen. El indicador honesto no es el hit rate sino cuantos recalculos simultaneos recibe el origen cuando la cache deja de proteger.

Evidencia. /cache-naive vs /cache-singleflight sobre la misma rafaga. Con 16 llamadores: 16 recalculos sin coordinacion, 1 con ella y 15 coalesced_waiters. Visibiliza origin_computations, stampede_depth, served_stale y el jitter aplicado por clave en /cache/state.

Honestidad. El origen es CPU real (un digest iterativo), no una consulta a una base de datos. Lo que se mide con fidelidad es origin_computations; la latencia absoluta depende del runtime y no es comparable entre stacks.

→ Detalle: cases/13-cache-stampede-and-thundering-herd/README.md

Caso 14 — Agotamiento del pool de conexiones#

Categoria: Rendimiento · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. El pool pierde una conexion cada vez que una query lanza, porque la devolucion esta solo en el camino feliz. Sin deadline de adquisicion, el que llega cuando ya no hay conexiones no falla: se queda. El servicio deja de responder sin que ningun proceso muera y sin que ninguna alerta dispare.

Valor. Elimina el reinicio preventivo como parte del runbook y reemplaza el dimensionado por intuicion con la ley de Little sobre throughput medido. Un pool de 100 para 5 req/s con queries de 20 ms son 99 conexiones ociosas que la base sostiene igual.

Evidencia. /pool-leaky vs /pool-managed sobre la misma carga. Con pool de 4 y 24 requests de las que fallan 7: 4 conexiones perdidas y 12 requests colgadas en la variante con fuga; 0 perdidas y el pool intacto en la corregida. Visibiliza leaked, hung, pool_available_after y littles_law.

Honestidad. Las conexiones son objetos en memoria, no sockets contra una base real, y el tiempo de query es un sleep — deliberado y mas fiel que quemar CPU, porque una conexion se retiene mientras se espera a la red.

→ Detalle: cases/14-connection-pool-exhaustion/README.md

Caso 15 — Backpressure en colas de mensajes#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. El productor va mas rapido que el consumidor y la cola absorbe la diferencia. Sin limite crece hasta el OOM, y el throughput se ve perfecto hasta el segundo antes. Con limite hay que elegir que pasa cuando se llena — y las tres opciones cuestan algo.

Valor. Evita caidas por memoria y perdidas silenciosas de mensajes, y convierte el sacrificio en una decision explicita y documentada en vez de un accidente. El indicador honesto no es el throughput sino la profundidad de la cola y la edad de su mensaje mas viejo.

Evidencia. /produce-unbounded vs /produce-bounded con las tres politicas. Con 120 mensajes y un consumidor 3x mas lento: la cola sin limite acumula los 120 y el mas viejo espera ~280 ms; acotada a 32 esa espera baja a ~80 ms, pero cuesta 218 ms de productor frenado, u 88 mensajes descartados, u 88 a la DLQ.

Honestidad. La cola vive dentro del proceso y no hay broker real detras. En PHP el productor y el consumidor son pasos del mismo bucle, porque el lenguaje no tiene concurrencia dentro del proceso.

→ Detalle: cases/15-message-queue-backpressure/README.md

Caso 16 — Idempotencia y efectos duplicados#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. El cliente reintenta porque el primer intento dio timeout. Pero el primer intento SI llego — lo que se perdio fue la respuesta. El cliente no puede distinguir 'no llego' de 'llego y no me entere', y sin una Idempotency-Key el servidor tampoco.

Valor. Elimina cobros y notificaciones duplicadas, y el costo de soporte y devolucion que cada uno genera. overcharged_cents es plata real, en la unidad en que el negocio discute.

Evidencia. /charge-unsafe vs /charge-idempotent sobre los mismos 5 reintentos: 5 cargos y 100 pesos de mas contra 1 cargo y 4 duplicados evitados. /outbox muestra que el efecto que cruza el boundary sale una sola vez y en la misma escritura que el cargo.

Honestidad. Las estructuras son en memoria, no una base con UNIQUE real. Y el caso documenta una asimetria en vez de esconderla: seis de las siete versiones resuelven la carrera dentro de su proceso, asi que con dos replicas dejan de ser correctas. Solo la de PHP sobrevive a eso.

→ Detalle: cases/16-idempotency-and-duplicate-effects/README.md

Caso 17 — Migracion de esquema sin downtime#

Categoria: Entrega · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. Un ALTER TABLE sobre una tabla caliente toma el lock exclusivo y no lo suelta hasta terminar. Veinte minutos de 503 por agregar una columna — con el proceso vivo y el healthcheck en verde todo el tiempo.

Valor. Permite cambiar el esquema sin ventana de mantenimiento, y elimina el despliegue nocturno como forma de convivir con el problema. El indicador honesto no es cuanto tarda la migracion sino cuanto dura su lock mas largo.

Evidencia. /migrate-blocking vs /migrate-expand-contract con lectores concurrentes midiendo disponibilidad DURANTE la migracion. Con 20.000 filas y 8 lectores: 400 ms de lock de corrido y lectores rechazados, contra 10 lotes de 40 ms y cero rechazados. lock_held_ms total es casi identico: el trabajo no desaparece, se reparte.

Honestidad. No hay PostgreSQL detras: el lock se modela con el read-write lock de cada runtime. La excepcion es PHP, donde flock SI es un lock del sistema operativo entre procesos.

→ Detalle: cases/17-zero-downtime-schema-migration/README.md

Caso 18 — Arranque en frio y retraso del autoescalado#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. El autoescalador suma instancias y la tasa de error sube con cada una. El proceso esta vivo desde el milisegundo cero y el healthcheck lo confirma, pero la instancia no puede servir hasta terminar de inicializar — y el balanceador que enruta por liveness manda trafico a ese hueco.

Valor. Elimina los 503 durante los escalados y habilita autoescalado agresivo con confianza. El indicador honesto no es cuanto tarda un servicio en arrancar sino cuanto tiempo afirma estar disponible sin estarlo.

Evidencia. Es el unico caso del lab que MIDE una propiedad del runtime en vez de simularla: el mismo lazo entero puro corre en los 7 stacks y warmup_speedup_x compara el p99 de las primeras 100 peticiones contra el p99 despues de 1000. Java sale 51,9x, .NET 2,3x, Rust 1,00x. Con 2.400 peticiones y 3 instancias, la variante fria rechaza entre el 12% y el 42% del trafico; la templada rechaza cero, con 100% de disponibilidad.

Honestidad. La curva de calentamiento se mide de verdad, sin sleep. Lo modelado es la parte de I/O de la inicializacion (abrir pool, DNS, TLS). En la variante fria, p99_first_100_ms mezcla el calentamiento del runtime con la contencion de las instancias que estan inicializando — los dos efectos son reales en produccion, pero es una mezcla.

→ Detalle: cases/18-cold-start-and-autoscale-lag/README.md

Caso 19 — Deriva del indice de busqueda y CDC roto#

Categoria: Observabilidad · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. La aplicacion escribe en la base y despues en el indice de busqueda. Dos sistemas, ninguna transaccion que los ate: cuando la segunda escritura falla, el codigo sigue. La busqueda no rompe — devuelve mal.

Valor. Elimina la categoria entera de 'el producto existe pero no aparece'. Se subestima porque no se ve como un incidente: el costo aparece con otro nombre —conversion que baja, tickets sobre un producto que no se encuentra— y ninguno se rastrea hasta un indice desincronizado.

Evidencia. Con 2.000 escrituras y 8% de fallo del indice, el dual-write deja 79 documentos derivados sobre 951: recall 98,95%, precision 98,02%. Con outbox + checkpoint + barrido: cero, con recall y precision en 100%. Las tres caras de la deriva van separadas, porque se arreglan distinto: missing no se encuentra, stale se encuentra mal, orphan es un fantasma.

Honestidad. El indice es un diccionario en memoria, no Elasticsearch — lo que define el caso no es el motor sino que la base y el indice son dos sistemas sin transaccion comun. La falla de escritura es deterministica, asi que los 7 stacks dan resultados identicos y lo unico comparable es como se escribe.

→ Detalle: cases/19-search-index-drift-and-broken-cdc/README.md

Caso 20 — La dead letter queue olvidada#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. El consumidor falla, manda el mensaje a la DLQ y sigue: sin clasificar el error, sin reintentar, sin medir, sin alerta. El pipeline se ve sano —throughput normal, error rate en cero— porque los errores se fueron a otro lado. Cierra el arco del caso 15, donde la DLQ nace como politica de rechazo.

Valor. Elimina la perdida silenciosa de datos. El consumidor que no clasifica esta haciendo exactamente lo que se le pidio —capturar el error, no morirse, seguir— y sin la otra mitad eso es perdida de datos con buenos modales.

Evidencia. Con 3.000 mensajes, 12% transitorios y 4% venenosos: el consumidor silencioso manda a la DLQ el 13,87% sin clasificar y sin alertar; el observado manda el 3,97% —solo veneno— con desglose por clase, muestras de payload y alerta disparada. Y la medicion que cierra el caso: drenar la DLQ del silencioso recupera el 71,39%, que era trabajo que se podia salvar con un reintento.

Honestidad. La DLQ es una lista en memoria, no SQS. Lo que define el caso no es el broker sino que un mensaje que falla necesita profundidad, antiguedad, clasificacion y una salida. El escenario es determinista, asi que los 7 stacks dan resultados identicos y lo unico comparable es que tan dificil hace cada lenguaje clasificar MAL.

→ Detalle: cases/20-forgotten-dead-letter-queue/README.md

Caso 20 — La dead letter queue olvidada#

Categoria: Resiliencia · Stacks operativos: PHP, Python, Node.js, Java 21, .NET 8, Go 1.23, Rust 1.83

Problema. El consumidor falla, manda el mensaje a la DLQ y sigue: sin clasificar el error, sin reintentar, sin medir, sin alerta. El pipeline se ve sano —throughput normal, error rate en cero— porque los errores se fueron a otro lado. Cierra el arco del caso 15, donde la DLQ nace como politica de rechazo.

Valor. Elimina la perdida silenciosa de datos. El consumidor que no clasifica esta haciendo exactamente lo que se le pidio —capturar el error, no morirse, seguir— y sin la otra mitad eso es perdida de datos con buenos modales.

Evidencia. Con 3.000 mensajes, 12% transitorios y 4% venenosos: el consumidor silencioso manda a la DLQ el 13,87% sin clasificar y sin alertar; el observado manda el 3,97% —solo veneno— con desglose por clase, muestras de payload y alerta disparada. Y la medicion que cierra el caso: drenar la DLQ del silencioso recupera el 71,39%, que era trabajo que se podia salvar con un reintento.

Honestidad. La DLQ es una lista en memoria, no SQS. Lo que define el caso no es el broker sino que un mensaje que falla necesita profundidad, antiguedad, clasificacion y una salida. El escenario es determinista, asi que los 7 stacks dan resultados identicos y lo unico comparable es que tan dificil hace cada lenguaje clasificar MAL.

→ Detalle: cases/20-forgotten-dead-letter-queue/README.md

Que NO encontraras en este laboratorio#

Honestidad explicita para no vender lo que no es:

• No es un benchmark de lenguajes. Los 7 stacks (PHP/Python/Node/Java/.NET/Go/Rust) resuelven los 20 problemas con primitivas nativas distintas; el contraste muestra criterio, no "cual es mas rapido". El caso 10 lo dice explicito: lo comparable es la forma de la curva dentro de cada stack, no los milisegundos entre stacks.
• No reemplaza plataformas reales. Tracing distribuido, CI/CD enterprise, mallas de servicios y feature flags globales quedan fuera. Lo que si esta: reproduccion fiel de la logica operativa de cada problema.
• No es production-grade tal cual. Modelo de amenaza: localhost / LAN confiable. Para Internet ver SECURITY.md (auth, rate limit, TLS son responsabilidad de quien expone).
• Paridad multi-stack completa hoy. PHP + Python + Node.js + Java + .NET cubren los 20 casos cada uno con primitivas idiomaticas distintas. Cualquier caso nuevo se incorpora siguiendo el mismo patron.

Postmortems narrativos por caso#

Cada caso tiene un postmortem.md en formato incidente real (severidad, timeline, causa raiz, action items, metrica antes/despues). Es el otro lado del criterio: como se piensa el incidente, no solo como se resuelve.

Rutas rapidas#

• Reclutador / lider no tecnico: esta pagina + RECRUITER.md + los 12 postmortems.
• CTO / arquitecto: ARCHITECTURE.md → 1-2 casos en detalle → postmortem del caso.
• Developer: INSTALL.md → make portal-up → recorrer el portal.
• Operacion / SRE: RUNBOOK.md + SECURITY.md + postmortems para entender el modelo de incidente.