20 problemas reales de ingenieria, resueltos y verificables
Laboratorio de ingeniería enfocado en resolver problemas reales de rendimiento, observabilidad, resiliencia y arquitectura. Cada caso parte de un sintoma medible, nombra la causa, compara opciones y deja evidencia observable — en 7 lenguajes, con la primitiva nativa de cada runtime y no con la misma solucion traducida siete veces.
Que demuestra este laboratorio
No es una coleccion de demos que devuelven 200 OK. Cada caso existe porque
el problema aparece en produccion y cuesta dinero, tiempo o confianza.
Diagnostico tecnico
Cada caso parte de sintomas observados, nombra causas y compara opciones antes de proponer solucion.
Ejecucion reproducible
Cada caso y cada stack traen su propio Dockerfile y su compose. La via oficial es Docker, no un README optimista.
Operacion realista
Los casos usan base de datos, workers, metricas y trazas segun corresponda. No hay demos vacias que solo devuelven 200.
Honestidad tecnica
El repositorio declara donde el substrato es real y donde es simulado, y que garantiza y que no garantiza su seguridad.
Empieza por tu rol
Diseñado para especialistas en selección, líderes técnicos y equipos de ingeniería que buscan validar criterio técnico con escenarios reproducibles.
Los 20 casos
Cada ficha abre el problema completo: sintomas, diagnostico, causas raiz, opciones, trade-offs, la solucion en los 7 stacks y que mirar para comprobarlo.
API lenta bajo carga
La aplicacion responde bien con pocos usuarios, pero degrada su latencia y estabilidad al aumentar la concurrencia.
N+1 queries y cuellos de botella en base de datos
La aplicacion ejecuta demasiadas consultas por solicitud o usa el acceso a datos de forma ineficiente, generando saturacion de base de datos.
Observabilidad deficiente y logs inutiles
Existen errores e incidentes, pero no hay trazabilidad suficiente para identificar causa raiz de forma rapida y confiable.
Cadena de timeouts y tormentas de reintentos
Una integracion lenta o inestable dispara reintentos, bloqueos y cascadas de fallas entre servicios.
Presion de memoria y fugas de recursos
El sistema consume memoria, descriptores o conexiones de forma progresiva hasta degradar o caerse.
Pipeline roto y entrega fragil
El software funciona en desarrollo, pero falla al desplegar, promover cambios o revertir incidentes con seguridad.
Modernizacion incremental de monolito
El sistema legacy sigue siendo critico, pero su evolucion se vuelve lenta, riesgosa y costosa.
Extraccion de modulo critico sin romper operacion
Se necesita desacoplar una parte clave del sistema, pero esa parte participa en flujos sensibles y no admite quiebres.
Integracion externa inestable
Una API, servicio o proveedor externo introduce latencia, errores intermitentes o reglas cambiantes que afectan el sistema propio.
Arquitectura cara para un problema simple
La solucion tecnica consume mas servicios, complejidad y costo del que el problema de negocio realmente necesita.
Reportes pesados que bloquean la operacion
Consultas y procesos de reporting compiten con la operacion transaccional y degradan el sistema completo.
Punto unico de conocimiento y riesgo operacional
Una persona, modulo o procedimiento concentra tanto conocimiento que el sistema se vuelve fragil ante ausencias o rotacion.
Cache stampede y thundering herd
Cuando la clave caliente expira, los N llamadores concurrentes recalculan el mismo valor y el origen recibe la rafaga entera.
Agotamiento del pool de conexiones
Un pool chico, sin timeout de adquisicion y con fugas en el camino de excepcion deja de dar conexiones para siempre.
Backpressure en colas de mensajes
Productores mas rapidos que consumidores: la cola sin limite crece hasta el OOM y la acotada obliga a elegir entre frenar, perder o mudar el problema.
Idempotencia y efectos duplicados
Un reintento por timeout se convierte en un segundo cobro salvo que el servidor pueda distinguir 'es la primera vez que veo esto' de 'ya procese esto'.
Migracion de esquema sin downtime
Un ALTER TABLE sobre una tabla caliente bloquea la aplicacion entera; expand-contract reparte el mismo trabajo en lotes que nadie nota.
Arranque en frio y retraso del autoescalado
El autoescalador suma instancias y la tasa de error sube con cada una: el proceso esta vivo y el healthcheck en verde mucho antes de que la instancia pueda servir.
Deriva del indice de busqueda y CDC roto
La busqueda responde 200 y lo que devuelve esta mal: el indice se desincroniza de a un documento por vez y nada dispara una alerta.
La dead letter queue olvidada
El pipeline muestra throughput normal y cero errores mientras pierde el 14% de los mensajes: los errores se fueron a una cola que nadie mira.
Los 7 stacks
El mismo problema resuelto con la herramienta que cada runtime trae de fabrica. Donde un lenguaje no tiene la primitiva, el perfil lo dice en vez de disimularlo.
php:8.3-cli-alpinePython 3.12Threads reales con GIL: paralelismo de I/O, no de CPUpython:3.12-alpineNode.js 22Event loop de un solo hilo con I/O asincronico delegadonode:22-alpineJava 21Threads del SO con paralelismo real; JVM con JIT y GC generacionaleclipse-temurin:21-jdk-alpine.NET 8ThreadPool con async/await que libera el hilo durante la esperamcr.microsoft.com/dotnet/sdk:8.0Go 1.23Goroutines multiplexadas por el runtime sobre threads del SOgolang:1.23-alpineRust 1.83Threads del SO sin GC; liberacion deterministica por Droprust:1.83-alpine
Como se ejecuta
Docker es la via oficial. Un comando levanta el hub de un stack completo con sus 20 casos detras de un unico puerto.
Laboratorio PHP + portal
git clone https://github.com/vladimiracunadev-create/problem-driven-systems-lab.git
cd problem-driven-systems-lab
docker compose -f compose.root.yml up -d --build
# portal en http://localhost:8080El portal es el hub de evaluacion: rutas por audiencia, seleccion por lenguaje y probes server-side.
Que es real y que no
La honestidad tecnica es parte del producto. El repositorio declara la frontera en vez de dejar que el lector la asuma.
🔍 Fidelidad del substrato
Los casos 01 y 02 ejecutan SQL real contra un
motor en los 7 stacks: db_hits cuenta ejecuciones, no
iteraciones de un bucle. La asimetria que queda — solo PHP cruza un socket TCP contra
PostgreSQL — esta documentada caso por caso.
🔒 Postura de seguridad
El laboratorio esta pensado para
localhost. Lo que el codigo garantiza (prepared statements, allowlists,
clamping) y lo que no (auth, rate limiting, TLS) esta escrito, no insinuado.
Documentacion
Los 407 documentos del repositorio estan publicados aqui como HTML.
Ninguno obliga a bajar un .md ni a salir del sitio.