La industria del software tiene una relación exasperante con los problemas ya resueltos. Una vez que algo se descubre, documenta y envía, una década después la mitad del campo lo reconstruye desde cero, aunque la solución original rara vez estuviera mal. El autor repasa casos emblematicos: autenticación, trabajos en segundo plano, reintentos y timeouts, rate limiting, claves de idempotencia, feature flags, caché, configuración y secretos, búsqueda, máquinas de estado y aislamiento multi-tenant. En cada caso existen soluciones maduras —Heroku para despliegues, Sidekiq o Celery para colas, Keycloak para identidad, Postgres o Elasticsearch para búsqueda, Temporal o Step Functions para flujos— y, aun así, los equipos reimplementan la misma maquinaria con bugs sutiles.
El patrón es siempre el mismo: una solución existe, el ecosistema asegura que una plataforma ya la cubre, y el ingeniero la reconstruye porque la abstracción no encaja exactamente o deja un hueco justo en la parte difícil. El resultado es media solución no deseada más media solución escrita a mano, el peor de los dos mundos. Construir sobre estándares y protocolos conocidos —OIDC para autenticación, protocolos documentados para mensajería— mantiene abierta la puerta a futuros cambios. El error opuesto —dependencias codificadas de proveedores, formatos propietarios y patrones sin documentar— parece simple el primer día y se convierte en una caja cerrada.
Evitar el servicio gestionado por miedo a perder el control es legítimo, pero no obliga a construir desde cero. El término medio es un subsistema ejecutable en local y propiedad del equipo, como Keycloak, Postgres, Redis o NATS. La clave está en no dedicar más esfuerzo a infraestructura reinventada que al producto que hace única a la empresa; cuando los datos de sprints muestran que auth, colas o rate limiting ganan la partida, conviene leer esos números.