Tengo una frustración que me viene carcomiendo hace años.
Los seniors escriben código, no artículos. Los que enseñan muchas veces no tienen experiencia real. Y los juniors se quedan sin referentes — navegando entre tutoriales genéricos y cursos que te venden “arquitectura de microservicios” sin haber mantenido un monolito en producción.
Así que decidí hacer algo al respecto.
El reto
110 días. Un problema real de arquitectura por día. Código que compila. Métricas reales. Cero pseudocódigo.
No voy a explicarte qué es el patrón Strategy con un ejemplo de animales que hacen sonidos. Voy a mostrarte cómo una decisión de diseño te arruina el response time en producción, y cómo la corregís con un refactor que podés aplicar mañana en tu proyecto.
Cada día vas a ver:
- Un problema real — de esos que te aparecen un martes a las 3pm y nadie sabe por qué.
- Código ANTES — el que escribimos cuando tenemos prisa, presión, o simplemente no sabemos algo mejor.
- Código DESPUÉS — la solución con contexto, trade-offs, y explicación de por qué funciona.
- Métricas reales — no “es más rápido”. Cuánto más rápido. Medido. Con números.
Los 5 bloques
Organicé los 110 días en bloques que siguen el camino que recorre cualquier dev que quiere pensar como arquitecto:
Días 1-25: “¿Por qué mi app es tan lenta?”
Performance, diagnóstico y optimización. N+1 queries, connection pools, caching que realmente funciona, procesamiento asíncrono. Todo lo que necesitás para dejar de adivinar y empezar a medir.
Días 26-50: “Mi código es un desastre y nadie lo entiende”
Patrones de diseño aplicados a problemas reales. Clean code que no es solo “nombres bonitos de variables”. Refactors que transforman código frágil en código que tu equipo puede mantener sin llamarte a las 11 de la noche.
Días 51-70: “El sistema se cayó y era viernes a las 6pm”
Resiliencia. Circuit breakers, retry policies, graceful degradation, health checks que sirven para algo. Cómo diseñar sistemas que fallan elegantemente en vez de explotar.
Días 71-90: “Deployear me da miedo”
CI/CD, feature flags, blue-green deployments, rollback strategies. Si deployear te genera ansiedad, este bloque es para vos.
Días 91-110: “Nadie entiende mis decisiones técnicas”
ADRs, diagramas que comunican, cómo defender una decisión técnica frente a negocio sin sonar como un robot. Porque la mejor arquitectura del mundo no sirve si no podés explicarla.
Las reglas
Me puse reglas estrictas. Si no las cumplo, el ejercicio no tiene sentido:
- Todo el código compila. Si lo ves en un artículo, lo podés clonar y correr.
- Métricas reales. Benchmarks, profiling, datos concretos. No “esto es más performante” sin evidencia.
- Nada de pseudocódigo. Spring Boot, Java, herramientas que usamos en la vida real.
- Sin consejos genéricos. No voy a decirte “usá caché”. Voy a mostrarte cuándo, cómo, y qué pasa cuando lo hacés mal.
¿Por qué 110 si se llama #100?
Porque los últimos 10 días son checkpoints y retrospectivas — no son problemas nuevos, son pausas para consolidar lo aprendido. Los 100 días de contenido técnico puro están ahí. Los 10 extras son los respiros que necesitás para no volverte loco y para conectar los conceptos entre sí. Podría haberlos escondido, pero preferí ser transparente. Ingeniería sin filtros, ¿no?
Para quién es esto
Si sos un developer que sabe programar pero quiere entender por qué se toman ciertas decisiones. Si querés dejar de ser la persona que implementa y empezar a ser la persona que diseña. Si estás cansado de leer “depende” como respuesta a todo y querés ver los trade-offs con código real.
Esto es para vos.
No necesitás ser senior. Necesitás tener curiosidad y ganas de entender cómo funcionan las cosas por debajo.
Por qué lo hago
Porque me hubiera encantado tener algo así cuando estaba creciendo como developer. Porque la arquitectura de software no debería ser un conocimiento reservado para los que tuvieron la suerte de trabajar con buenos mentores. Y porque estoy convencido de que la mejor forma de aprender es hacer — y la mejor forma de enseñar es mostrar.
110 días. 110 problemas. Código real.
El Día 1 ya está arriba: “Tu app tarda 11 segundos en arrancar y vos pensás que es normal”. Diagnóstico, código ANTES/DESPUÉS, y una mejora del 88% en tiempo de startup.
Si querés seguir la serie, suscribite al newsletter o seguime en redes. Cada nuevo artículo, directo en tu inbox.
Esto recién empieza.
💻 Todo el código de la serie está en GitHub. Si te copa el proyecto, dejame una ⭐ — es gratis y ayuda a que más gente lo encuentre.
Architecture Red Flags & The Modern Backend Blueprint
La guía definitiva para detectar fallos de diseño y el mapa de referencia para construir sistemas resilientes.
Recibí el War Manual en tu inbox:
Prometido: nada de spam, solo ingeniería cruda cada 15 días.
¿Necesitás ayuda con tu proyecto? Agendá una sesión 1:1 →
