Blog de Daniel Hidalgo

Un setup de IA, dos mundos: cómo uso agentes de IA como Tech Lead y como emprendedor

Fri, 23 Oct 2026 00:00:00 GMT

Antes escribí sobre qué funciona de verdad con la IA en el flujo de trabajo del desarrollador. Ese artículo trataba de principios. Este trata del setup en sí: las herramientas que corren en mi máquina todos los días, cómo el mismo setup sirve a dos contextos muy distintos y las reglas que sigo para que siga siendo una herramienta y no un riesgo.

Los dos contextos son mi trabajo como Tech Lead y Arupo, la empresa que estoy construyendo como socio, además de algunos proyectos personales. Restricciones muy diferentes, un solo ingeniero, una sola laptop.

La base: configurar una vez, usar en todos lados

El error más grande que veo es tratar cada herramienta de IA como una isla: unas instrucciones en un editor, otros hábitos en otro, nada compartido entre ellos. Yo fui por el camino contrario. Hay una sola base, y todos los agentes se apoyan en ella.

Un harness compartido. Uso Gentle AI para darle a cada agente el mismo flujo de trabajo, la misma persona y las mismas reglas de revisión. Está configurado para Claude Code, Codex, OpenCode, Gemini y Copilot. Abra el agente que abra, trabaja igual.
Memoria persistente. Engram guarda decisiones, correcciones de bugs, descubrimientos y preferencias entre sesiones y entre agentes. Cuando vuelvo a un proyecto después de dos semanas, el agente no arranca de cero, y yo tampoco.
Un mapa del código. Codegraph indexa cada repositorio para que un agente entienda la estructura sin leer archivo por archivo. Eso importa cuando el código es grande y la ventana de contexto no lo es.
Documentación actualizada. Context7 les da a los agentes la documentación vigente de las librerías que uso, en lugar de la versión que memorizaron durante el entrenamiento.
Una segunda terminal de IA. Pi, con Gentle Shell, es donde corro el trabajo orquestado más largo, con perfiles para distintos modelos.
Un guardián en los commits. Un revisor previo al commit revisa los cambios antes de que entren.
Un entorno cómodo. Ghostty, Starship y los dotfiles de Gentleman. Parece cosmético, pero ahí se pasa el día entero.

Ninguna de estas piezas es mágica por sí sola. El valor está en que están conectadas: las mismas reglas, la misma memoria, la misma forma de trabajar, sin importar el agente ni el proyecto.

Dos mundos en una sola máquina

Esta es la parte de la que casi nadie habla. Mi trabajo y mi empresa nunca deben mezclarse. Cuentas distintas, identidades distintas, reglas distintas sobre qué puede salir de la máquina.

Por eso la separación es automática, por carpeta. Cuando entro a la carpeta de proyectos personales, se activan solos el perfil personal de IA y mi identidad personal de git y SSH. Cuando entro a la carpeta de trabajo, toman el control el perfil corporativo de IA y la identidad corporativa de git. No tengo que acordarme de cambiar, y ese es justamente el punto: una regla que hay que recordar es una regla que tarde o temprano se rompe.

No es perfecto, y sé dónde están los huecos. La CLI de GitHub, por ejemplo, no cambia de cuenta por carpeta; usa una sola sesión global. Conocer los huecos de tu propio setup también es hacerte cargo de él.

En el trabajo: liderar dentro de las restricciones

Una empresa tiene reglas sobre herramientas y datos, y existen por buenas razones. Mi regla es simple: la forma de trabajar viaja conmigo, y las políticas de la empresa deciden qué herramientas puedo usar. Adapto el setup a esas políticas, nunca al revés.

Pero el cambio más grande en el trabajo no es técnico. Es cómo uso mi tiempo como Tech Lead. Los agentes se llevan buena parte del trabajo mecánico: explorar un servicio desconocido, preparar el borrador de una migración, escribir los tests aburridos. Eso me deja más tiempo para lo que realmente le toca a un Tech Lead: decisiones de diseño, revisiones de código, destrabar al equipo, incidentes y postmortems.

Hay algo que no cambia: la responsabilidad sigue siendo humana. Un agente puede proponer un cambio en un servicio de producción. El que responde por él a las 3 de la mañana soy yo.

En Arupo: velocidad sin bajar el estándar

En mi propia empresa la restricción es la opuesta. No hay reglas corporativas, pero hay muy poco tiempo y un equipo muy chico. La IA es lo que permite que un equipo chico entregue como uno más grande, siempre que el estándar de calidad no baje.

El mejor ejemplo es el sitio que estás leyendo. En unas pocas sesiones de trabajo pasó por:

Un rediseño completo, con versiones en inglés y en español.
Una limpieza de SEO.
Endurecimiento de seguridad: una Content Security Policy generada en el build, con un chequeo que hace fallar el build si a un script inline le falta su entrada.
Una migración de Astro 5 a Astro 7.
Una revisión de accesibilidad para cumplir el contraste WCAG AA, y una auditoría de dependencias llevada a cero vulnerabilidades conocidas.

Cada uno de esos cambios salió en su propio pull request, con deploys de preview, antes de llegar a producción. Los agentes escribieron la mayor parte del código. Yo tomé cada decisión que importaba: qué actualizar y qué dejar como estaba, qué trade-off de seguridad aceptar, cuándo algo estaba listo para mergear.

El mismo setup corre mis otros proyectos: productos personales de finanzas y fitness, una tesis y los distintos repositorios detrás de Arupo.

El flujo que lo une todo

Las herramientas son la parte fácil. Lo que hace que esto funcione es el proceso que sigo con ellas, igual en los dos mundos:

Aclarar primero. Si el pedido es ambiguo, el agente pregunta antes de escribir una sola línea.
Dimensionar la tarea. Los cambios chicos y bien entendidos se hacen directo. Los grandes se siguen con tareas.
Escribir la especificación. Un cambio grande tiene su documento: los requisitos citados tal como los dije, una lista numerada de tareas y un registro de decisiones. Cualquiera, humano o agente, puede retomar desde ahí.
Tests primero. Cuando el comportamiento se puede testear, el test que falla va antes que la corrección.
Commits chicos. Porciones revisables, nunca un diff gigante que nadie puede revisar de verdad.
Revisión según el riesgo. Cuando un cambio toca seguridad, datos, contratos o despliegues, lo mira un revisor independiente. Cuando no, no pago por una ceremonia que no necesito.
El merge lo hago yo. Hacer push, abrir el pull request y mergear siguen siendo decisiones mías. Siempre.

Lo que (todavía) no funciona

Para ser honesto:

Las herramientas se rompen. Algunas integraciones piden volver a autenticarse, otras no logran conectarse. Un setup tan conectado necesita mantenimiento.
La memoria se desactualiza. Una decisión guardada hace tres meses puede que ya no sea cierta. La memoria es contexto, no verdad.
Los agentes se equivocan con total seguridad. Te dicen que un build pasa cuando no pasa, o inventan una API. Por eso cada afirmación necesita evidencia: la salida del test, el log del build, el diff.

Reflexiones finales

La IA no me convirtió en otro ingeniero. Amplificó al que ya era. Los fundamentos que aprendí en ocho años, desde la infraestructura de red hasta liderar equipos de producto, son exactamente lo que me permite dirigir a estos agentes y atraparlos cuando se equivocan.

La habilidad que importa ahora no es escribir rápido. Es saber qué pedir, reconocer cuándo la respuesta está mal y hacerse cargo del resultado. Esa parte sigue siendo, y va a seguir siendo, nuestra.

Del monolito al BFF: cómo migramos de verdad sin quemarlo todo

Sun, 15 Mar 2026 00:00:00 GMT

Voy a contarte algo que todo ingeniero senior termina aprendiendo: nadie se despierta una mañana y decide migrar de un monolito por diversión. Lo haces porque el monolito está perjudicando activamente a tu equipo, tus deploys y tus clientes. Eso es exactamente lo que nos pasaba hace unos dos años, y quiero contarte cómo lo logramos en realidad: no la versión depurada de las charlas de conferencias, sino la real.

El monolito pedía ayuda a gritos

Nuestro monolito era una aplicación Node.js con Express que llevaba tres años creciendo. Empezó limpio. No se mantuvo así. Así se veían los síntomas:

Miedo a desplegar: un cambio en el módulo de pagos requería desplegar toda la aplicación. Un viernes por la tarde, un arreglo de CSS en el panel de administración tumbó el flujo de checkout. Fue un fin de semana muy divertido.
Dependencias enredadas: el servicio de órdenes importaba directamente el repositorio de usuarios. El módulo de notificaciones conocía los niveles de inventario. Todo conocía a todo.
Cuellos de botella entre equipos: tres squads trabajando sobre la misma base de código significaban conflictos de merge constantes y una cola de deploys que a veces se acumulaba durante días.
Techo de rendimiento: no podíamos escalar el módulo de reportes de forma independiente del flujo de checkout en tiempo real. Ambos vivían en el mismo proceso, compitiendo por los mismos recursos.

El monolito no era solo deuda técnica: era deuda organizacional. Y ahí es cuando sabes que llegó la hora.

Por qué BFF (y no solo "microservicios")

La reacción instintiva es "¡hagamos microservicios!". Pero los microservicios sin una estrategia clara de frontend solo mueven los espaguetis del backend a la capa de API. Teníamos tres clientes: una SPA web (Angular), una app móvil (React Native) y un dashboard interno de administración. Cada uno necesitaba formas de datos distintas, flujos de autenticación distintos y características de rendimiento distintas.

Ahí entra Backend for Frontend. La idea es simple: cada cliente tiene su propio backend liviano que orquesta las llamadas a los servicios de dominio y da forma a la respuesta según las necesidades de ese cliente en particular.

La clave fue esta: el BFF no es un servicio de dominio. Tiene cero lógica de negocio. Es una capa de orquestación y transformación. En el momento en que pones reglas de negocio en un BFF, acabas de construir otro monolito con saltos de red adicionales.

Arquitectura hexagonal en los servicios de dominio

Para los servicios de dominio propiamente dichos (órdenes, inventario, usuarios, pagos), optamos por la arquitectura hexagonal. La razón: queríamos que la lógica de dominio estuviera completamente desacoplada de las preocupaciones de infraestructura. ¿Base de datos? Eso es un adapter. ¿Cola de mensajes? Adapter. ¿Pasarela de pagos externa? Adapter.

Esta es la estructura que usamos en NestJS:

src/
├── domain/
│   ├── entities/
│   │   └── order.entity.ts
│   ├── ports/
│   │   ├── order.repository.port.ts
│   │   └── payment-gateway.port.ts
│   └── use-cases/
│       └── create-order.use-case.ts
├── infrastructure/
│   ├── adapters/
│   │   ├── postgres-order.repository.ts
│   │   └── stripe-payment.gateway.ts
│   └── modules/
│       └── order.module.ts
└── application/
    └── bff/
        └── web-bff.controller.ts

La definición del port es limpia y agnóstica a la infraestructura:

// domain/ports/order.repository.port.ts
export interface OrderRepositoryPort {
  findById(id: string): Promise<Order | null>;
  save(order: Order): Promise<Order>;
  findByCustomer(customerId: string, pagination: PaginationParams): Promise<PaginatedResult<Order>>;
}

Y el controller del BFF orquesta sin poseer lógica:

// application/bff/web-bff.controller.ts
@Controller('web/orders')
export class WebBffController {
  constructor(
    private readonly createOrderUseCase: CreateOrderUseCase,
    private readonly getCustomerUseCase: GetCustomerUseCase,
  ) {}

  @Post()
  async createOrder(@Body() dto: CreateOrderDto, @Req() req: AuthRequest) {
    const order = await this.createOrderUseCase.execute({
      customerId: req.user.id,
      items: dto.items,
      shippingAddress: dto.shippingAddress,
    });

    // Responsabilidad del BFF: dar forma a la respuesta para el cliente web
    return {
      orderId: order.id,
      status: order.status,
      estimatedDelivery: order.estimatedDelivery?.toISOString(),
      items: order.items.map(item => ({
        name: item.productName,
        qty: item.quantity,
        total: formatCurrency(item.totalPrice),
      })),
    };
  }
}

Fíjate: el BFF llama al use case y luego transforma la respuesta para el cliente web. El BFF móvil devolvería otra forma, quizás con menos datos para ahorrar ancho de banda, o con URLs de imágenes optimizadas para pantallas móviles.

La estrategia de migración: Strangler Fig

No hicimos una migración big bang. Así es como lo quemas todo. Usamos el patrón strangler fig, y así funcionó en la práctica:

API Gateway como router: pusimos un API Gateway (Kong) delante de todo. Al principio, el 100 % del tráfico iba al monolito.
Extraer un dominio a la vez: empezamos por el servicio de notificaciones porque era el más aislado y el de menor riesgo. Lo construimos como un servicio NestJS independiente con arquitectura hexagonal.
Período de doble escritura: durante unas dos semanas, tanto el monolito como el nuevo servicio procesaron notificaciones. Comparamos las salidas. Así encontramos tres bugs en el servicio nuevo.
Cambio de ruta: cuando tuvimos confianza, actualizamos el gateway para enrutar el tráfico de notificaciones al nuevo servicio. El código del monolito se quedó en su lugar, pero inactivo.
Repetir: órdenes fue lo siguiente, luego inventario y por último pagos (el más aterrador, que dejamos para el final).

Toda la migración tomó unos ocho meses. No ocho días, no ocho semanas. Ocho meses.

Los errores que cometimos

Mentiría si dijera que todo salió sin problemas. Estos son los errores que nos costaron tiempo real:

Error 1: compartir la base de datos durante demasiado tiempo. Al principio dejamos que el nuevo servicio de órdenes leyera de la base de datos del monolito. "Lo separamos después", dijimos. Ese después tardó cuatro meses, y durante ese tiempo tuvimos un acoplamiento de esquema que echó por tierra la mitad del propósito de extraer el servicio.

Error 2: un BFF que hacía demasiado. En la primera iteración, nuestro BFF web empezó a acumular lógica de negocio. "Es solo una validación pequeña", dijo alguien. Luego otra. En un mes, el BFF tenía 40 líneas de reglas de negocio que debían vivir en el servicio de dominio. Tuvimos que refactorizarlas de vuelta.

Error 3: no invertir en observabilidad desde el principio. Con un monolito puedes seguir un request en un único flujo de logs. Con servicios distribuidos necesitas trazado distribuido desde el primer día. Agregamos OpenTelemetry en el mes tres. Debió ser el día uno.

Error 4: subestimar la consistencia de datos. Pasar de una única transacción de base de datos a consistencia eventual entre servicios fue un cambio de mentalidad para todo el equipo. Tuvimos que implementar el patrón saga para el flujo orden-pago-inventario, y nos tomó tres iteraciones hacerlo bien.

Los trade-offs de los que nadie te habla

Seamos realistas sobre en qué te estás metiendo:

La complejidad operativa aumenta significativamente. Ahora tienes 6 servicios en lugar de 1. Eso son 6 pipelines de CI/CD, 6 conjuntos de logs, 6 health checks, 6 cosas que pueden fallar de forma independiente.
El desarrollo local se complica. Docker Compose pasó a ser obligatorio. Incorporar a un nuevo desarrollador pasó de "clonar y ejecutar" a un proceso de configuración de 45 minutos (que con el tiempo automatizamos).
La red ahora es un modo de falla. Las llamadas entre servicios pueden agotar el tiempo de espera, fallar o devolver datos desactualizados. Necesitas lógica de reintentos, circuit breakers y estrategias de fallback en todas partes.
Las pruebas cambian de raíz. Los tests unitarios son fáciles. ¿Tests de integración entre servicios? Eso requiere contract testing (usamos Pact) y un entorno de staging adecuado.

Pero esta es la otra cara:

Los equipos avanzan de forma independiente. El squad de pagos despliega tres veces al día sin coordinarse con nadie.
El escalado es quirúrgico. ¿Black Friday? Escala el servicio de órdenes y el de pagos. Deja tranquilo al BFF de administración.
Las fallas quedan aisladas. El servicio de notificaciones estuvo caído 20 minutos el mes pasado. Las órdenes siguieron fluyendo. En la época del monolito, eso habría sido una caída total.

La conclusión honesta

Si tu monolito funciona y tu equipo es pequeño, no migres. En serio. Un monolito bien estructurado le gana todos los días a un sistema distribuido mal implementado. Nosotros migramos porque teníamos un dolor real y medible, no porque los microservicios estuvieran de moda.

Pero si estás sintiendo ese dolor (miedo a desplegar, cuellos de botella entre equipos, techos de escalado), entonces una migración bien pensada con BFF + arquitectura hexagonal + strangler fig es un enfoque probado en batalla. Solo entra con los ojos abiertos respecto a los trade-offs, invierte en observabilidad desde el primer día y, por el amor de todo lo bueno en la ingeniería, mantén la lógica de negocio fuera del BFF.

La mejor arquitectura es la que le permite a tu equipo entregar con confianza. Todo lo demás son detalles.

Por qué la mayoría de los sistemas backend fallan a escala (y los errores que he visto de primera mano)

Tue, 10 Mar 2026 00:00:00 GMT

Llevo más de seis años construyendo y escalando sistemas backend, y puedo decirte esto con absoluta seguridad: la mayoría de los sistemas no fallan por algún caso borde exótico. Fallan por errores bien conocidos que los equipos siguen repitiendo. No porque los ingenieros sean malos, sino porque estos problemas son invisibles con poco tráfico y solo se vuelven letales a escala.

Estos son siete errores que he visto acabar con sistemas en producción, lo que pasó realmente y cómo los solucionamos. Cada uno de ellos viene de un proyecto real.

1. La query N+1 que nadie notó

Qué pasó: teníamos un endpoint que devolvía una lista de órdenes con sus productos asociados. Con 50 órdenes iba bien: 200 ms de tiempo de respuesta. Con 500 órdenes durante una venta relámpago, tardó 14 segundos y el CPU de la base de datos llegó al 98 %.

El ORM hacía exactamente lo que le pedimos: cargar las órdenes y, para cada orden, cargar sus productos. Una query para las órdenes, 500 queries para los productos. N+1 clásico.

Qué hicimos: la solución inmediata fue el eager loading: una sola query con un JOIN. El tiempo de respuesta bajó a 180 ms sin importar la cantidad de órdenes.

// Antes: desastre N+1
const orders = await orderRepo.find({ where: { userId } });
// Esto dispara 1 query por orden para cargar los productos

// Después: una sola query cargando las relaciones
const orders = await orderRepo.find({
  where: { userId },
  relations: ['items', 'items.product'],
});

Pero la solución de fondo fue agregar logging de queries en staging con una alerta por umbral. Cualquier endpoint que ejecute más de 10 queries por request queda marcado automáticamente. Ahora detectamos los N+1 antes de que lleguen a producción.

Lección: los ORMs hacen que las queries N+1 sean fáciles de escribir y difíciles de detectar. Necesitas detección automatizada, no solo code reviews.

2. Falta de circuit breakers

Qué pasó: nuestro servicio de órdenes llamaba a una API de tarifas de envío de un tercero. Una tarde, esa API empezó a responder con timeouts de 30 segundos en lugar de sus habituales 200 ms. Cada request al flujo de checkout quedó en cola esperando las tarifas de envío. Se agotó el thread pool. Todo nuestro checkout cayó, no porque NUESTRO sistema fallara, sino porque falló el de otro.

Qué hicimos: implementamos circuit breakers con un patrón similar al Hystrix de Netflix (usamos opossum en Node.js):

import CircuitBreaker from 'opossum';

const shippingBreaker = new CircuitBreaker(fetchShippingRates, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
});

shippingBreaker.fallback(() => ({
  rates: getCachedShippingRates(),
  isFallback: true,
}));

Cuando la API de envíos falla, el circuito se abre y servimos tarifas en cache con una marca que le indica al frontend que son estimaciones. Los clientes siguen comprando. Conciliamos los costos de envío reales de forma asíncrona.

Lección: toda dependencia externa es un pasivo. Si no tienes una estrategia de fallback para cada una, has acoplado tu uptime al de ellos.

3. Base de datos compartida entre servicios

Qué pasó: dos servicios, órdenes e inventario, leían y escribían en la misma base de datos PostgreSQL. El servicio de inventario ejecutaba cada 5 minutos una query analítica pesada para los reportes de stock. En horas pico, esa query bloqueaba filas que el servicio de órdenes necesitaba actualizar. Las órdenes empezaron a fallar con errores de lock timeout.

Qué hicimos: le dimos a cada servicio su propia base de datos. Los cambios de inventario se publican como eventos vía SNS, y el servicio de órdenes mantiene su propio modelo de lectura del stock disponible. Sí, es eventualmente consistente. Pero "eventualmente consistente con un checkout que funciona" le gana a "fuertemente consistente con un checkout que falla" siempre.

Lección: una base de datos compartida es un destino compartido. Si dos servicios comparten una base de datos, no son dos servicios: son un monolito distribuido.

4. Sin backpressure en las colas

Qué pasó: usábamos SQS para procesar las confirmaciones de órdenes. Cada mensaje disparaba un email, la generación de una factura en PDF y una actualización de inventario. Durante un evento promocional entraron 50.000 órdenes en una hora. La cola de SQS se acumuló hasta 200.000 mensajes (algunas órdenes generaban varios mensajes). Nuestro consumidor intentó procesarlos todos a máxima velocidad, saturó el servicio de email y empezó a recibir errores 429 de rate limit. Los mensajes fallidos fueron a la dead-letter queue. 12.000 clientes no recibieron su email de confirmación.

Qué hicimos: tres cambios:

Límites de concurrencia en los consumidores: en lugar de procesar lo más rápido posible, fijamos un tope de 20 mensajes concurrentes por instancia de consumidor.
Rate limiting por dependencia downstream: agregamos un rate limiter de tipo token bucket antes de llamar a la API de email.
Backoff exponencial con jitter: los mensajes fallidos se reintentan con retrasos crecientes más aleatoriedad para evitar un thundering herd durante la recuperación.

// Consumidor de SQS con concurrencia controlada
const consumer = Consumer.create({
  queueUrl: process.env.ORDER_QUEUE_URL,
  batchSize: 10,
  visibilityTimeout: 60,
  handleMessage: async (message) => {
    await rateLimiter.acquire('email-service', { maxPerSecond: 50 });
    await processOrderConfirmation(JSON.parse(message.Body));
  },
});

Lección: una cola sin backpressure es solo una forma de convertir un pico de tráfico en un fallo en cascada con pasos extra.

5. Ignorar los cold starts

Qué pasó: movimos un servicio crítico a AWS Lambda para ahorrar costos. Tiempo de respuesta promedio: 80 ms. Pero después de periodos de inactividad, el primer request tardaba entre 4 y 6 segundos por los cold starts. Era el servicio de autenticación. Los usuarios sufrían demoras aleatorias de 5 segundos al iniciar sesión. Los tickets de soporte se acumularon.

Qué hicimos: evaluamos tres opciones:

Provisioned concurrency: mantiene las instancias de Lambda calientes. Efectivo pero caro; anuló el ahorro de costos.
Pings de calentamiento: un evento programado de CloudWatch que invoca la función cada 5 minutos. Barato pero poco confiable bajo carga concurrente: solo mantiene caliente una instancia.
Volver a ECS Fargate: lo que terminamos haciendo. El servicio de auth necesita una latencia consistente por debajo de 100 ms. El modelo de Lambda no encaja con ese requisito.

Lección: serverless es fantástico, para las cargas de trabajo adecuadas. Los servicios sensibles a la latencia y siempre activos no lo son. Ajusta el modelo de cómputo a los requisitos reales, no a la moda.

6. Cache stampede

Qué pasó: cacheábamos nuestro catálogo de productos en Redis con un TTL de 5 minutos. En el momento exacto en que expiró el cache, 3.000 requests concurrentes llegaron al endpoint. Los 3.000 vieron un cache miss. Los 3.000 consultaron la base de datos al mismo tiempo. Se agotó el connection pool de la base de datos. Errores 500 para todos.

Qué hicimos: implementamos un patrón de cache lock (a veces llamado "probabilistic early expiration"):

async function getProductCatalog(categoryId: string): Promise<Product[]> {
  const cacheKey = `catalog:${categoryId}`;
  const cached = await redis.get(cacheKey);

  if (cached) {
    const { data, expiry, delta } = JSON.parse(cached);
    const now = Date.now();

    // Recómputo anticipado probabilístico
    // A medida que nos acercamos a la expiración, es cada vez más probable que se refresque
    if (now - delta * Math.log(Math.random()) < expiry) {
      return data;
    }
  }

  // Lock distribuido: solo un proceso reconstruye
  const lockKey = `lock:${cacheKey}`;
  const acquired = await redis.set(lockKey, '1', 'EX', 30, 'NX');

  if (!acquired) {
    // Otro proceso está reconstruyendo; servimos datos obsoletos si hay
    if (cached) return JSON.parse(cached).data;
    // No hay datos obsoletos; esperamos un momento y reintentamos
    await sleep(100);
    return getProductCatalog(categoryId);
  }

  try {
    const products = await productRepo.findByCategory(categoryId);
    const ttl = 300; // 5 minutos
    await redis.set(cacheKey, JSON.stringify({
      data: products,
      expiry: Date.now() + ttl * 1000,
      delta: ttl * 1000 * 0.1,
    }), 'EX', ttl + 60); // Margen extra para servir datos obsoletos
    return products;
  } finally {
    await redis.del(lockKey);
  }
}

Solo un proceso reconstruye el cache. Todos los demás reciben datos ligeramente desactualizados. En un catálogo de e-commerce, nadie nota datos de producto con 30 segundos de antigüedad. Todos notan un error 500.

Lección: la expiración del cache es un evento coordinado que puede generar thundering herds. Diséñalo de forma explícita.

7. No diseñar para el fallo

Qué pasó: este es el meta-error que engloba a todos los demás. Construimos la primera versión de la plataforma asumiendo que todo iba a funcionar. Camino feliz en todas partes. Sin reintentos, sin fallbacks, sin degradación elegante. El sistema funcionaba perfecto en desarrollo y en staging. Producción nos enseñó lo contrario durante la primera semana.

Qué hicimos: adoptamos un principio: toda llamada externa debe responder tres preguntas antes de escribirse:

¿Qué pasa si esta llamada falla?
¿Qué pasa si esta llamada es lenta (10 veces la latencia normal)?
¿Qué pasa si esta llamada devuelve datos inesperados?

Lo codificamos en nuestro checklist de code review. Los pull requests que agregan llamadas externas sin responder estas tres preguntas se devuelven.

También empezamos a hacer game days: inyectar fallos de forma intencional en staging con AWS Fault Injection Simulator. Te sorprendería cuántos supuestos se rompen cuando apagas una réplica de la base de datos o le agregas 500 ms de latencia a un servicio interno.

Lección: el fallo no es un caso borde. Es una característica de los sistemas distribuidos. Si no has diseñado para él, no has diseñado el sistema.

El patrón detrás de todos estos fallos

Mira los siete errores. Hay un hilo común: todos son invisibles a baja escala. Las queries N+1 son rápidas cuando N es pequeño. La falta de circuit breakers no importa cuando las dependencias están sanas. Los cache stampedes no ocurren con 10 usuarios concurrentes.

Por eso las pruebas de carga y la ingeniería del caos no son lujos opcionales: son la forma de encontrar estos problemas antes que tus clientes. Ejecutamos pruebas de carga que simulan 3 veces nuestro tráfico pico antes de cada release importante. Hacemos experimentos de caos todos los meses. No es paranoia. Es profesionalismo.

Los sistemas que sobreviven a escala no son los construidos por los ingenieros más brillantes. Son los construidos por ingenieros que asumieron que todo se iba a romper y planificaron en consecuencia. Construye primero para el caso de fallo. El camino feliz se cuida solo.

Redis en producción: estrategias de caching que realmente funcionan (y algunas que no)

Thu, 05 Mar 2026 00:00:00 GMT

Llevo varios años corriendo Redis en producción en plataformas de e-commerce y puedo decirte que la mayoría de los tutoriales de caching omiten las partes que realmente importan. Te muestran SET key value EX 300 y dan el trabajo por terminado. El caching real en producción trata de trade-offs, estrategias de invalidación, modos de falla y saber cuándo NO cachear algo.

Esto es todo lo que me hubiera gustado que alguien me contara antes de aprenderlo a golpes.

Las tres estrategias principales (y cuándo encaja cada una)

Cache-Aside (Lazy Loading)

Es el patrón más común, y con razón. La aplicación consulta primero el cache. Si no está (miss), lee de la base de datos, escribe en el cache y devuelve los datos.

async function getProduct(id: string): Promise<Product> {
  const cacheKey = `product:${id}`;

  // 1. Consultar el cache
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // 2. Cache miss: leer de la BD
  const product = await productRepo.findById(id);
  if (!product) throw new NotFoundException();

  // 3. Poblar el cache
  await redis.set(cacheKey, JSON.stringify(product), 'EX', 600);

  return product;
}

Cuándo funciona: cargas de trabajo con mucha lectura donde los datos desactualizados son aceptables por períodos cortos. Catálogos de productos, perfiles de usuario, datos de configuración.

Cuándo no funciona: datos que cambian con frecuencia y deben ser consistentes de inmediato. Si cacheas el carrito de un usuario con cache-aside y agrega un ítem, verá el carrito viejo hasta que expire el TTL (a menos que invalides activamente; más sobre eso adelante).

Trade-off: simple de implementar, pero cada cache miss es un request lento. Un cache frío después de un deploy o un reinicio de Redis significa una estampida (thundering herd) hacia la base de datos.

Write-Through

Cada escritura va al cache y a la base de datos de forma simultánea. Las lecturas siempre van al cache.

async function updateProduct(id: string, data: UpdateProductDto): Promise<Product> {
  // 1. Actualizar la base de datos
  const product = await productRepo.update(id, data);

  // 2. Actualizar el cache (de forma síncrona, como parte del camino de escritura)
  const cacheKey = `product:${id}`;
  await redis.set(cacheKey, JSON.stringify(product), 'EX', 600);

  return product;
}

Cuándo funciona: datos que se leen con frecuencia y se actualizan de vez en cuando, Y en los que necesitas una fuerte consistencia de lectura. Datos de sesión, feature flags, reglas de precios.

Cuándo no funciona: cargas con mucha escritura. Pagas el costo de latencia de una escritura en Redis en cada escritura a la base de datos, incluso para datos que quizás nadie lea.

Trade-off: el cache siempre está fresco, pero las escrituras son más lentas. Y aun así necesitas un TTL como red de seguridad: si el write-through falla en silencio, sin TTL el cache diverge para siempre.

Write-Behind (Write-Back)

Las escrituras van primero al cache, y el cache las vuelca a la base de datos de forma asíncrona. Es lo más rápido para escribir, pero lo más peligroso.

Cuándo funciona: contadores de alta frecuencia, eventos de analítica, métricas en tiempo real, donde perder algunos puntos de datos es aceptable.

Cuándo no funciona: cualquier cosa transaccional. Si Redis se cae antes de volcar a la base de datos, esos datos se pierden. Yo jamás lo usaría para órdenes, pagos ni nada financiero.

Trade-off: máximo rendimiento de escritura, pero aceptas una posible pérdida de datos. En mi experiencia, este patrón rara vez es la opción correcta para los datos centrales del negocio. Lo usamos para contadores de vistas y pipelines de analítica, y poco más.

Estrategias de TTL más allá de "ponlo en 5 minutos"

El antipatrón de TTL número uno que veo es ponerle el mismo TTL a todo. Tu catálogo de productos y tu conteo de inventario en tiempo real tienen requisitos de frescura totalmente distintos. Trátalos de forma diferente.

Así pensamos el diseño de TTL:

Datos de referencia estáticos (países, categorías, tasas de impuestos): TTL de 24 horas. Invalida explícitamente al cambiar.
Datos semiestáticos (detalles de producto, perfiles de usuario): TTL de 10-30 minutos. Los datos desactualizados molestan, pero no hacen daño.
Datos volátiles (conteos de inventario, precios): TTL de 30-60 segundos. O no cachees en absoluto: a veces la base de datos es la respuesta correcta.
Datos de sesión/autenticación: el TTL coincide con la duración de la sesión. Ni más, ni menos.

También usamos TTLs adaptativos según los patrones de acceso:

async function getWithAdaptiveTTL(key: string, fetcher: () => Promise<any>): Promise<any> {
  const cached = await redis.get(key);
  if (cached) {
    // Extender el TTL al acceder (lo usado más recientemente se mantiene caliente)
    const currentTTL = await redis.ttl(key);
    if (currentTTL < 120) {
      await redis.expire(key, 600); // Reiniciar a 10 min al acceder
    }
    return JSON.parse(cached);
  }

  const data = await fetcher();
  await redis.set(key, JSON.stringify(data), 'EX', 600);
  return data;
}

Los datos de acceso frecuente se mantienen calientes. Los de acceso poco frecuente se expulsan de forma natural. La memoria de tu cache se mantiene enfocada en lo que importa.

Invalidación de cache: el verdadero problema difícil

Phil Karlton dijo que hay dos cosas difíciles en ciencias de la computación: la invalidación de cache y ponerle nombres a las cosas. No se equivocaba con la primera.

Estos son los patrones de invalidación que usamos, del más simple al más robusto:

Expiración basada en TTL (pasiva)

Déjalo expirar de forma natural. Está bien cuando los datos desactualizados son aceptables. Es simple, y la simplicidad está subestimada.

Invalidación explícita (activa)

Cuando los datos cambian, borra la clave del cache:

async function updateProduct(id: string, data: UpdateProductDto): Promise<Product> {
  const product = await productRepo.update(id, data);

  // Borrar, no actualizar: deja que la siguiente lectura lo repueble
  await redis.del(`product:${id}`);

  // ¡No olvides los caches relacionados!
  await redis.del(`catalog:${product.categoryId}`);
  await redis.del(`search:products:*`); // Borrado por patrón para los caches de búsqueda

  return product;
}

Importante: borra, no actualices. Si actualizas el cache y la escritura en la base de datos falla o hace rollback, tu cache queda con datos fantasma. Borrar es idempotente y seguro.

Pero fíjate en search:products:*: ahí es donde la invalidación se pone fea. Un cambio de producto puede afectar listados de categorías, resultados de búsqueda, feeds de recomendaciones y destacados de la página de inicio. Olvidar aunque sea uno crea un bug de datos desactualizados increíblemente difícil de rastrear.

Invalidación basada en eventos

Esto es en lo que nos asentamos para cualquier caso no trivial. Los cambios en la base de datos publican eventos, y un consumidor dedicado a la invalidación del cache se encarga de la limpieza:

// Manejador de eventos: servicio/consumidor separado
@OnEvent('product.updated')
async handleProductUpdate(event: ProductUpdatedEvent) {
  const { productId, categoryId, previousCategoryId } = event;

  const keysToInvalidate = [
    `product:${productId}`,
    `catalog:${categoryId}`,
    `homepage:featured`,
  ];

  // Si cambió la categoría, invalidar también la categoría anterior
  if (previousCategoryId && previousCategoryId !== categoryId) {
    keysToInvalidate.push(`catalog:${previousCategoryId}`);
  }

  await Promise.all(keysToInvalidate.map(key => redis.del(key)));
}

Esto centraliza la lógica de invalidación. Cuando se agrega un cache nuevo, añades su regla de invalidación al manejador de eventos: un solo lugar que mantener en lugar de llamadas a redis.del() dispersas por toda la base de código.

Redis Cluster en AWS ElastiCache: lo que aprendimos

Correr Redis en ElastiCache en modo cluster tiene algunas aristas filosas:

La distribución de claves importa. Redis Cluster usa hash slots. Si usas MGET sobre claves que caen en slots distintos, falla. Usa hash tags ({product}:123, {product}:456) para ubicar las claves relacionadas en el mismo shard.
El failover no es instantáneo. Cuando falla un nodo primario, ElastiCache promueve una réplica. Esto toma entre 10 y 30 segundos. Tu aplicación debe manejar los errores de conexión con elegancia durante el failover. Nosotros usamos ioredis con retryStrategy y reconnectOnError bien configurados.
La gestión de memoria es crítica. Configura maxmemory-policy en allkeys-lru para cargas de caching. Hemos visto equipos dejarlo en noeviction (el valor por defecto) y luego preguntarse por qué Redis empieza a devolver errores cuando se llena.
Monitorea el lag de replicación. Si tus réplicas de lectura se atrasan, las lecturas desde réplicas sirven datos desactualizados. Alertamos con 1 segundo de lag de replicación.

Cuándo NO cachear

Esta es la sección que la mayoría de los artículos se salta. Estos son los casos en que cachear empeora las cosas:

Datos con mucha escritura y poca lectura. Si escribes 10 veces más de lo que lees, pagas el costo de escritura del cache sin el beneficio de lectura.
Datos muy personalizados con poca reutilización. Cachear un feed de recomendaciones único por usuario suena bien hasta que te das cuenta de que tu tasa de aciertos es del 3 %. Estás usando Redis como una segunda base de datos cara y volátil.
Datos que deben ser consistentes en tiempo real. Saldos de cuentas, inventario de lanzamientos de edición limitada, pujas de subastas. El costo de los datos desactualizados supera el costo de una consulta a la base de datos.
Objetos grandes que rara vez se repiten. Cachear en Redis un PDF de reporte de 2 MB es desperdiciar memoria. Ponlo en S3.

La regla general: si tu tasa de aciertos del cache está por debajo del 80 %, investiga si ese cache se está ganando su lugar. Por debajo del 50 %, probablemente perjudica más de lo que ayuda.

Monitoreo de la salud del cache

Un cache que no monitoreas es un cache esperando para traicionarte. Esto es lo que medimos:

Hit rate (objetivo: >90 %): cache_hits / (cache_hits + cache_misses). Lo exponemos como métrica de Prometheus y alertamos si baja del 80 %.
Percentiles de latencia: p50, p95, p99 para las operaciones de Redis. Si el p99 se dispara, puede haber una hot key o un problema de red.
Uso de memoria: porcentaje de la memoria disponible en uso. Alerta al 80 %.
Tasa de evicción: si las claves se expulsan más rápido de lo esperado, tu cache es demasiado pequeño para la carga de trabajo.
Cantidad de conexiones: un número de conexiones repentinamente alto puede indicar una fuga de conexiones en tu aplicación.

Usamos OpenTelemetry para instrumentar todas las llamadas a Redis y enviar los traces a nuestro stack de observabilidad. Cada operación de cache recibe un span con el patrón de la clave (no la clave completa: no quieres labels de alta cardinalidad), el tipo de operación y si fue un hit o un miss.

// Wrapper de instrumentación OTEL simplificado
async function cachedGet<T>(key: string, fetcher: () => Promise<T>, ttl: number): Promise<T> {
  const span = tracer.startSpan('cache.get', {
    attributes: { 'cache.key_pattern': key.split(':')[0], 'cache.ttl': ttl },
  });

  try {
    const cached = await redis.get(key);
    if (cached) {
      span.setAttribute('cache.hit', true);
      cacheHitCounter.inc({ pattern: key.split(':')[0] });
      return JSON.parse(cached);
    }

    span.setAttribute('cache.hit', false);
    cacheMissCounter.inc({ pattern: key.split(':')[0] });
    const data = await fetcher();
    await redis.set(key, JSON.stringify(data), 'EX', ttl);
    return data;
  } finally {
    span.end();
  }
}

La conclusión

Redis es una de las herramientas más poderosas del arsenal de un ingeniero de backend, pero no es magia. Es una máquina de trade-offs: memoria por velocidad, consistencia por rendimiento, simplicidad por resiliencia. Toda decisión de caching debería empezar con "¿cuál es el costo de los datos desactualizados?" y "¿cuál es el costo de un cache miss?", no con "cacheemos todo y esperemos lo mejor".

Empieza con cache-aside para la mayoría de las cosas. Agrega write-through solo donde la consistencia importe. Usa invalidación basada en eventos para todo lo complejo. Monitorea tus hit rates religiosamente. Y nunca, jamás olvides: el cache miss más rápido es el que evitas al no cachear datos que no deberían cachearse en primer lugar.

Cómo diseñar sistemas cuando no controlas todas las dependencias

Sat, 28 Feb 2026 00:00:00 GMT

Hay un momento en la carrera de todo ingeniero en el que te das cuenta de algo incómodo: el sistema del que eres responsable es tan confiable como su dependencia externa más débil. Y esa dependencia no la controlas tú.

Quizás sea una pasarela de pagos que agota el tiempo de espera en horas pico. Quizás sea un sistema de inventario legacy mantenido por un equipo en otra zona horaria que hace deploy los viernes. Quizás sea un proveedor de envíos cuya API devuelve 500 cada vez que publica una "actualización menor".

He vivido todo esto. Y esto es lo que aprendí: los sistemas resilientes no se diseñan esperando que todo funcione. Se diseñan asumiendo que todo va a fallar.

El concepto de trust boundary

Antes de entrar en los patrones, establezcamos un modelo mental que uso constantemente: el trust boundary (límite de confianza).

Todo sistema tiene un límite entre lo que controlas y lo que no. Dentro del límite, eres dueño del código, los deploys, el monitoreo y la rotación de guardias. Fuera del límite, estás a merced de las prioridades, el calendario de releases y la definición de "confiable" de alguien más.

El error que cometen la mayoría de los equipos es tratar las dependencias externas como si estuvieran dentro del trust boundary. Llaman a una API de terceros y asumen que responderá en 200 ms. Se integran con un servicio legacy interno y asumen que el contrato no cambiará. Confían.

No confíes. Verifica, aísla y planifica para el fallo.

Así es como trazo los trust boundaries en la práctica:

Nivel 1 (confianza total): Servicios que mi equipo posee y despliega. Nosotros controlamos los SLA.
Nivel 2 (confianza condicional): Servicios internos de otros equipos. Tenemos algo de influencia, pero ningún control.
Nivel 3 (confianza cero): APIs de terceros, sistemas legacy, cualquier cosa detrás de una VPN que no podemos monitorear.

Cada nivel recibe una estrategia de resiliencia distinta. Las dependencias de Nivel 3 reciben el tratamiento completo.

Patrón Circuit Breaker: deja de golpear servicios muertos

El circuit breaker es el primer patrón al que deberías recurrir cuando lidias con dependencias poco confiables. El concepto está tomado de la ingeniería eléctrica: cuando un servicio downstream está fallando, deja de enviarle solicitudes.

Aquí hay una implementación simplificada que he usado en servicios Node.js:

class CircuitBreaker {
  private failures = 0;
  private lastFailure: number = 0;
  private state: 'closed' | 'open' | 'half-open' = 'closed';

  constructor(
    private readonly threshold: number = 5,
    private readonly resetTimeout: number = 30_000
  ) {}

  async execute<T>(fn: () => Promise<T>, fallback: () => T): Promise<T> {
    if (this.state === 'open') {
      if (Date.now() - this.lastFailure > this.resetTimeout) {
        this.state = 'half-open';
      } else {
        return fallback();
      }
    }

    try {
      const result = await fn();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      return fallback();
    }
  }

  private onSuccess(): void {
    this.failures = 0;
    this.state = 'closed';
  }

  private onFailure(): void {
    this.failures++;
    this.lastFailure = Date.now();
    if (this.failures >= this.threshold) {
      this.state = 'open';
    }
  }
}

En un sistema de e-commerce en el que trabajé, envolvimos cada llamada a la pasarela de pagos con un circuit breaker. Cuando Stripe tenía problemas intermitentes (sí, hasta Stripe tiene malos días), el circuito se abría tras 5 fallos consecutivos. En lugar de encolar miles de intentos de pago fallidos y dejar a los usuarios mirando un spinner, redirigíamos de inmediato al flujo de fallback: mostrábamos un mensaje de "procesamiento de pago retrasado" y encolábamos el cobro para reintentarlo.

Idea clave: El circuit breaker no arregla el problema. Previene los fallos en cascada y le da al usuario una mejor experiencia durante las caídas.

Aislamiento con Bulkheads: no dejes que un fallo hunda el barco

Los bulkheads (mamparos) de un barco son compartimentos estancos. Si uno se inunda, el barco no se hunde. El mismo principio aplica al software.

En un escenario real: teníamos una plataforma de e-commerce en la que el calculador de tarifas de envío, el verificador de inventario y el procesador de pagos compartían el mismo pool de conexiones HTTP. Cuando el proveedor de envíos empezó a responder lento, consumió todas las conexiones disponibles. De pronto, los pagos tampoco se podían procesar. Una dependencia defectuosa tumbó una ruta crítica que no tenía relación con ella.

La solución fue el aislamiento con bulkheads:

Pools de conexiones separados por cada dependencia externa
Pools de hilos separados (o, en Node.js, workers de cola separados) para distintas categorías de trabajo
Timeouts separados ajustados al comportamiento esperado de cada dependencia

const paymentClient = new HttpClient({
  maxConnections: 20,
  timeout: 5_000,       // los pagos deberían ser rápidos
  retries: 2,
});

const shippingClient = new HttpClient({
  maxConnections: 10,
  timeout: 15_000,      // las APIs de envío son notoriamente lentas
  retries: 3,
});

const inventoryClient = new HttpClient({
  maxConnections: 15,
  timeout: 3_000,       // servicio interno, debería ser rápido
  retries: 1,
});

Esto no es sobreingeniería. Es la diferencia entre "la API de envíos está lenta hoy" y "todo el checkout está caído".

Estrategias de timeout: el asesino silencioso

La mayoría de los incidentes de producción que he depurado no empezaron con un crash. Empezaron con un timeout demasiado generoso o inexistente.

Esta es mi jerarquía de timeouts para llamadas externas:

Connect timeout: Cuánto esperar una conexión TCP. Mantenlo agresivo (1-3 segundos). Si un servicio no acepta conexiones, esperar más no ayudará.
Read timeout: Cuánto esperar una respuesta después de establecida la conexión. Depende de la operación, pero rara vez supero los 10 segundos en llamadas síncronas.
Total timeout: El presupuesto global de toda la operación, incluidos los reintentos. Es el que la mayoría olvida.

La regla que sigo: toda llamada HTTP a un servicio externo DEBE tener un timeout explícito. Sin excepciones. Los timeouts por defecto de las librerías HTTP suelen ser de 30 a 120 segundos, lo cual es una eternidad en un pipeline de solicitudes.

Un ejemplo práctico: en un flujo de checkout, el presupuesto total es quizás de 8 segundos antes de que el usuario se impaciente. Si llamas en secuencia a una API de pagos, un validador de direcciones y un calculador de impuestos, no tienes 30 segundos por llamada. Tienes quizás 2-3 segundos cada una, y el pago recibe la asignación más generosa.

Mecanismos de fallback: degradación elegante en la práctica

Aquí es donde se pone interesante. Los fallbacks no son solo devolver datos en cache. Se trata de decidir qué puede seguir haciendo tu sistema sin una dependencia.

Ejemplos reales de sistemas que he construido:

Pasarela de pagos caída: Encolar la orden, mostrar el estado "procesando" y cobrar de forma asíncrona cuando la pasarela se recupere. El usuario igual completa el checkout.
Calculador de tarifas de envío caído: Mostrar tarifas planas estimadas a partir de datos históricos. No es perfecto, pero el usuario puede comprar.
Servicio de inventario caído: Permitir la compra, pero marcarla para revisión manual. Aceptar el riesgo de vender de más unas pocas piezas frente a bloquear todas las ventas.
Motor de recomendaciones caído: Mostrar productos populares en lugar de personalizados. Nadie lo nota.

El patrón:

async function getShippingRates(order: Order): Promise<ShippingRate[]> {
  try {
    return await shippingCircuitBreaker.execute(
      () => shippingClient.calculateRates(order),
      () => getCachedFlatRates(order.destination)
    );
  } catch {
    return getDefaultFlatRates();  // último recurso
  }
}

La conversación con el negocio importa aquí. Los fallbacks tienen trade-offs. Mostrar tarifas planas cuando las tarifas reales son distintas significa que podrías perder dinero en algunos envíos. Encolar y cobrar después significa que podrías cobrarle a una tarjeta que luego será rechazada. Son decisiones de negocio, no solo técnicas. Ten esta conversación con producto antes de la caída, no durante.

Contract Testing: detecta los quiebres antes de producción

Una de las estrategias más efectivas que he adoptado es el contract testing dirigido por el consumidor. En lugar de rezar para que la API de envíos no cambie su formato de respuesta, codificamos lo que esperamos y lo probamos con regularidad.

Herramientas como Pact te permiten definir contratos:

describe('Shipping API Contract', () => {
  it('should return rates with expected structure', async () => {
    const response = await provider.executeTest(async (mockServer) => {
      const client = new ShippingClient(mockServer.url);
      const rates = await client.getRates(testOrder);

      expect(rates).toEqual(
        expect.arrayContaining([
          expect.objectContaining({
            carrier: expect.any(String),
            price: expect.any(Number),
            estimatedDays: expect.any(Number),
          }),
        ])
      );
    });
  });
});

Esto no evitará que la API externa se rompa. Pero te avisará de inmediato cuando se viole el contrato, en lugar de descubrirlo a través de errores en producción a las 2 AM.

El trade-off: resiliencia vs. simplicidad

Hay algo sobre lo que quiero ser honesto: todo esto añade complejidad. Circuit breakers, bulkheads, fallbacks, contract tests: todos añaden código, configuración y carga cognitiva.

No todos los sistemas necesitan todos estos patrones. ¿Un proyecto personal que llama a una sola API externa? Simplemente añade un timeout y maneja los errores con elegancia. ¿Una plataforma de e-commerce que procesa miles de órdenes por hora a través de una docena de servicios externos? Necesitas el kit completo.

Mi regla general:

Si la caída de la dependencia cuesta dinero: circuit breaker + fallback + monitoreo
Si la caída provoca pérdida de datos: aislamiento con bulkheads + reintentos con idempotencia
Si la dependencia pertenece a otro equipo: contract tests + SLA explícitos
Si es un tercero sobre el que no puedes influir en absoluto: todo lo anterior

Reflexiones finales

La lección más difícil del diseño de sistemas no es aprender patrones. Es aceptar que no puedes controlarlo todo. Tu proveedor de pagos tendrá caídas. El sistema legacy cambiará sin avisar. El equipo del otro lado del edificio desplegará un cambio que rompe todo un viernes.

Tu trabajo no es prevenir estos fallos. Es diseñar sistemas que los manejen con elegancia. Cada patrón de resiliencia es una apuesta: "Cuando esta dependencia falle (y va a fallar), así es como seguiremos funcionando".

Los ingenieros que construyen sistemas realmente confiables no son los que escriben el código más ingenioso. Son los que se han quemado las veces suficientes como para planificar el incendio.

El rol de un Tech Lead más allá de escribir código

Fri, 20 Feb 2026 00:00:00 GMT

Cuando me convertí en Tech Lead por primera vez, pensé que el trabajo era simple: ser el mejor programador del equipo y tomar las grandes decisiones técnicas. Me equivoqué en prácticamente todo.

El rol de Tech Lead es una de las posiciones más malinterpretadas en la ingeniería de software. No es un ascenso por escribir buen código. Es un trabajo fundamentalmente distinto. Y nadie te prepara para él.

Después de años liderando equipos en varios sistemas de producción, esto es lo que el rol realmente implica: las partes de las que nadie habla en las descripciones de puesto.

Las decisiones de arquitectura son decisiones organizacionales

Cada decisión de arquitectura que tomas tiene consecuencias organizacionales. ¿Eliges microservicios? Ahora necesitas límites entre equipos, contratos de API y coordinación de deploys. ¿Eliges un monolito? Ahora necesitas disciplina modular y estrategias para resolver conflictos de merge.

He visto equipos adoptar arquitecturas orientadas a eventos porque era "el patrón correcto", sin considerar que nadie en el equipo tenía experiencia con la consistencia eventual. La arquitectura era sólida sobre el papel. En la práctica, provocó meses de sesiones de depuración y un backlog de bugs de inconsistencia de datos.

Como Tech Lead, tu trabajo no es elegir la mejor arquitectura en teoría. Es elegir la mejor arquitectura para tu equipo, tus plazos y las restricciones de tu negocio.

Esto significa hacerte preguntas como:

¿Podrá nuestro equipo mantener esto dentro de 6 meses, cuando yo no esté revisando cada PR?
¿Esta arquitectura se ajusta a nuestras capacidades de deploy?
Si contratamos a dos desarrolladores junior el próximo trimestre, ¿podrán contribuir a esto?
¿Cuál es el costo de equivocarnos con esta decisión?

La mejor decisión de arquitectura que he tomado no fue elegir un patrón elegante. Fue elegir uno aburrido y bien entendido con el que todo el equipo pudiera trabajar de forma independiente. Lo aburrido está subestimado.

Mentoría: tu efecto multiplicador

Aquí va un problema de matemáticas: puedes escribir 8 horas de código al día, o puedes dedicar 2 horas a hacer mentoría a tres ingenieros que luego escriben cada uno 6 horas efectivas de código al día. La primera opción produce 8 horas de output. La segunda produce 18.

Este es el efecto multiplicador, y es lo más impactante que hace un Tech Lead.

Pero la mentoría no es solo responder preguntas o hacer pair programming (aunque ambos importan). La mentoría de verdad implica:

El code review como enseñanza: no te limites a aprobar o pedir cambios. Explica por qué algo debería ser distinto. Enlaza a la documentación. Muestra las consecuencias del enfoque actual. Un comentario en un PR que dice "usa inyección de dependencias aquí" no vale nada. Uno que dice "si inyectamos esta dependencia, podemos probar el flujo de pago sin llamar a Stripe — así se hace" enseña un principio.
Delegar los problemas difíciles: esto es contraintuitivo. Tu instinto es quedarte con las tareas complejas porque las harás más rápido. Resiste ese instinto. Dale el trabajo desafiante a ingenieros en crecimiento, con tu apoyo. Sí, va a tomar más tiempo. Sí, la primera implementación no será tan limpia. Pero ahora tienes a dos personas que pueden resolver ese tipo de problema en lugar de una.
Crear espacios seguros para fallar: los ingenieros que le temen a los errores no crecen. Les digo explícitamente a mi equipo: "Esta es una zona segura para experimentar. Si se rompe, lo arreglamos juntos." Los mejores ingenieros a los que he hecho mentoría cometieron errores espectaculares al principio porque se sintieron seguros para intentarlo.

Uno de mis momentos de mayor orgullo como Tech Lead no fue entregar una funcionalidad. Fue ver a un ingeniero de nivel intermedio al que llevaba un año haciendo mentoría liderar una discusión de arquitectura y tomar mejores decisiones de las que yo habría tomado.

Navegar las tensiones entre producto e ingeniería

Cada sprint planning es una negociación entre lo que quiere el equipo de producto y lo que el equipo de ingeniería sabe que es sostenible. Como Tech Lead, eres el traductor entre esos dos mundos.

Producto dice: "Necesitamos esta funcionalidad para el próximo sprint." Ingeniería sabe: el modelo de datos no la soporta, y forzarla creará una deuda que va a frenar todo durante meses.

Tu trabajo no es decir "no". Tu trabajo es decir "estas son las opciones con sus trade-offs".

Un marco que uso constantemente:

Opción A: hacerlo de la forma rápida. Entregar en 1 sprint. Genera X cantidad de deuda técnica. Costo estimado de arreglarlo después: Y sprints. Riesgo: Z.
Opción B: hacerlo bien. Entregar en 2 sprints. Sin deuda. Habilita las funcionalidades futuras P y Q sin retrabajo.
Opción C: entregar un alcance reducido en 1 sprint. Cubre el 80 % de la necesidad del usuario. Arquitectura adecuada. Iterar sobre el 20 % restante en el siguiente sprint.

Nueve de cada diez veces, gana la opción C. Pero solo puedes presentar la opción C si entiendes a fondo tanto el objetivo de negocio como el panorama técnico.

Los Tech Leads que terminan quemados son los que simplemente dicen "sí" a todo. Aprende a presentar opciones. Deja que los stakeholders decidan con toda la información. Eso no es resistencia: es colaboración.

Decir "no" al scope creep

El scope creep es el asesino silencioso de los proyectos. No llega como un gran cambio. Llega como una serie de adiciones "pequeñas" que parecen razonables por separado.

"¿Podemos agregar también filtros a esta página?" "¿Y si soportáramos también la exportación a CSV?" "¿Podría esta API manejar también el caso de uso del administrador?"

Cada pedido son 2-3 días de trabajo. Diez de ellos son un mes de trabajo no planificado que nadie presupuestó.

Como Tech Lead, muchas veces eres la única persona en la sala que puede ver el costo técnico acumulado. Es tu responsabilidad hacerlo visible.

Mantengo un documento permanente al que llamo el "scope ledger". Cada adición se registra con su esfuerzo estimado. Cuando los stakeholders preguntan por qué el proyecto se retrasó, puedo señalar 15 adiciones "pequeñas" que sumaron 6 semanas de trabajo extra. Los datos cambian las conversaciones.

La deuda técnica como conversación de negocio

Esto me tomó años aprenderlo: los ingenieros hablan de deuda técnica en términos de ingeniería. "El código es un desastre." "Necesitamos refactorizar este módulo." "Nuestra cobertura de pruebas es muy baja." Estas frases no significan nada para los stakeholders de negocio.

La deuda técnica hay que traducirla a impacto en el negocio:

No digas: "Necesitamos refactorizar el módulo de pagos."
Di: "Agregar cualquier método de pago nuevo al módulo de pagos toma 3 días. Nuestros competidores agregan métodos nuevos cada trimestre. Refactorizar lo reduce a medio día."
No digas: "Nuestra cobertura de pruebas es del 20 %."
Di: "Este trimestre tuvimos 4 incidentes en producción que las pruebas habrían detectado. Cada incidente nos costó en promedio $X en transacciones perdidas y Y horas de ingeniería."
No digas: "El código está muy acoplado."
Di: "Agregar la funcionalidad que quieres requiere modificar 12 archivos en 4 servicios por cómo están conectadas las cosas. Por eso las estimaciones siguen siendo más altas de lo esperado."

Cuando planteas la deuda como un problema de negocio con costos medibles, consigues presupuesto para resolverla. Cuando la planteas como una preferencia de ingeniería, te dicen que "lo hagas funcionar igual".

La soledad de liderar

Nadie te advierte sobre esta parte. Como Tech Lead, ocupas un terreno intermedio extraño. No eres management, pero tampoco eres ya "uno de los desarrolladores". Estás en reuniones en las que tu equipo no está. Te enteras de reorganizaciones, recortes de presupuesto y giros estratégicos antes que nadie. Y no siempre puedes compartir lo que sabes.

A veces tu equipo se frustrará con decisiones que tomaste o aceptaste. No siempre tendrán el contexto de por qué. Y no siempre podrás dárselo.

Hay días en los que eres el escudo entre tu equipo y el caos organizacional, y nadie lo sabrá jamás. El mejor elogio que puede recibir un Tech Lead no es "gran arquitectura". Es que un miembro del equipo diga "no sé por qué, pero aquí las cosas simplemente fluyen". Esa fluidez es que tú absorbes una fricción que ellos nunca ven.

Busca un grupo de pares. Habla con otros Tech Leads. Este rol es aislante si no tienes a personas que entiendan las presiones específicas bajo las que estás.

Cuándo programar y cuándo dar un paso atrás

Esta es la calibración más difícil. Si programas demasiado, te conviertes en un cuello de botella: el equipo depende de ti para el trabajo del camino crítico. Si programas muy poco, pierdes contacto con el código, y tu guía de arquitectura se vuelve cada vez más teórica.

Mi balance actual:

Escribo código para: pruebas de concepto de decisiones de arquitectura, piezas críticas de infraestructura donde hay que establecer los patrones, depuración de problemas de producción que requieren un conocimiento profundo del sistema.
No escribo código para: trabajo de funcionalidades que un miembro del equipo podría hacer (aunque tarde más), cualquier cosa en el camino crítico de un compromiso del sprint, tareas que serían mejores como oportunidades de aprendizaje para otra persona.

Una regla práctica: si quitarme del tablero del sprint bloquearía la entrega, estoy programando demasiadas cosas equivocadas. El equipo debería poder entregar sin que yo escriba una sola línea de código de funcionalidades.

La transición: de mejor programador a mejor facilitador

El cambio más difícil al convertirte en Tech Lead es redefinir qué significa ser "productivo". Durante toda tu carrera, productividad significó líneas de código, funcionalidades entregadas, problemas resueltos con tus propias manos.

Ahora, productividad significa:

Un ingeniero junior que entrega con confianza su primera funcionalidad en producción
Una arquitectura que le permite al equipo avanzar de forma independiente
Una cultura de code review donde los ingenieros se enseñan unos a otros
Un sprint que termina a tiempo porque identificaste los riesgos temprano
Un sistema en producción que maneja los fallos con elegancia porque invertiste en patrones de resiliencia

Tu producción de código va a bajar. Tu impacto se va a multiplicar. Eso no es un trade-off. Es todo el punto.

Reflexiones finales

Ser Tech Lead cambió mi forma de pensar sobre el software. Antes optimizaba por código elegante. Ahora optimizo por la velocidad del equipo, sistemas sostenibles y el crecimiento de las personas.

Si estás haciendo la transición a este rol, este es mi consejo honesto: suelta la idea de ser el mejor programador de la sala. Invierte en ser la persona que hace mejores a todos los demás. El código que escribas será olvidado. Los ingenieros que hagas crecer construirán cosas que tú jamás habrías podido construir solo.

Eso no es un descenso. Es apalancamiento.

La IA en el flujo de trabajo del desarrollador: qué funciona de verdad (y qué es puro hype)

Sun, 15 Feb 2026 00:00:00 GMT

Voy a ser directo: la IA no va a reemplazar a los desarrolladores. Pero tampoco es un juguete. La verdad, como siempre, está en algún punto intermedio, y la mayor parte del discurso sobre la IA en el desarrollo es o bien hype desbordado o bien cinismo despectivo. Ambos se equivocan.

Llevo más de un año usando herramientas de IA a diario en mi flujo de trabajo. No como experimento. En trabajo de producción, liderando equipos y entregando sistemas reales. Esta es mi evaluación honesta y sin hype de qué funciona de verdad, qué no y en qué deberías estar pensando.

En qué es realmente buena la IA

Empecemos por los aciertos. Estas son las áreas en las que las herramientas de IA mejoraron mi flujo de trabajo de forma medible:

Boilerplate y código repetitivo

Aquí es donde la IA brilla más. Escribir DTOs, funciones de mapeo, endpoints CRUD, archivos de configuración, definiciones de tipos a partir de especificaciones de API: el tipo de código en el que el patrón está bien establecido y básicamente estás traduciendo una estructura conocida a sintaxis.

// "Genera un DTO para la respuesta de la orden con estos campos"
// La IA produce esto en segundos, frente a minutos de tipeo:
interface OrderResponseDto {
  id: string;
  status: OrderStatus;
  items: OrderItemDto[];
  total: number;
  currency: string;
  createdAt: string;
  shippingAddress: AddressDto;
  estimatedDelivery: string | null;
}

¿Es revolucionario? No. ¿Ahorra 20 minutos de tipeo tedioso varias veces al día? Totalmente. Y eso se acumula.

Andamiaje de pruebas

Probablemente sea mi caso de uso favorito. La IA es notablemente buena generando el andamiaje de las pruebas: los bloques describe, la configuración y los casos básicos de camino feliz y de error. Acierta con la estructura aproximadamente el 80 % de las veces.

// Describo qué hace la función y la IA genera el andamiaje:
describe('OrderService.calculateTotal', () => {
  let service: OrderService;
  let mockTaxCalculator: jest.Mocked<TaxCalculator>;

  beforeEach(() => {
    mockTaxCalculator = { calculate: jest.fn() };
    service = new OrderService(mockTaxCalculator);
  });

  it('should sum item prices correctly', () => { /* ... */ });
  it('should apply tax from calculator', () => { /* ... */ });
  it('should handle empty order', () => { /* ... */ });
  it('should throw on negative quantities', () => { /* ... */ });
  it('should round to 2 decimal places', () => { /* ... */ });
});

Las aserciones reales y los casos borde los sigo escribiendo yo. Pero tener el andamiaje, los mocks configurados y la organización de las pruebas listos ahorra muchísimo tiempo. Es como tener a alguien que te prepara el banco de trabajo antes de empezar a construir.

Explorar bases de código desconocidas

Cuando entro a un proyecto nuevo o necesito entender una librería que nunca usé, la IA es una excelente compañera de exploración. "Explica cómo funciona esta cadena de middlewares." "¿Qué aprovisiona este módulo de Terraform?" "Guíame por el flujo de autenticación de este código."

No siempre acierta. Pero es más rápido que leer la documentación desde cero y me da un punto de partida para mi propia investigación. La trato como a un colega que ya trabajó en ese código: su aporte es útil, pero verifico todo lo crítico.

Documentación y mensajes de commit

Escribir comentarios JSDoc, secciones de README, documentación de APIs e incluso mensajes de commit bien pensados. La IA lo hace sorprendentemente bien porque documentar consiste, en esencia, en describir algo que ya existe, y el código está ahí como contexto.

Sugerencias de refactorización

"Aquí tienes una función de 200 líneas. Sugiere cómo dividirla." Las sugerencias no siempre están listas para producción, pero son un buen punto de partida para pensar la descomposición. La IA detecta oportunidades de extraer métodos más rápido de lo que yo leo una función larga.

En qué es pésima la IA

Ahora viene lo importante. Estas son las áreas en las que confiar en lo que genera la IA te va a costar caro:

Decisiones de arquitectura

La IA no puede tomar decisiones de arquitectura por tu sistema. No entiende las capacidades de tu equipo, tus restricciones de despliegue, los plazos del negocio, los requisitos regulatorios ni las dinámicas políticas que influyen en las decisiones técnicas.

He visto ingenieros preguntarle a la IA "¿uso microservicios o un monolito?" y tomar la respuesta como palabra santa. La respuesta va a ser coherente. Va a mencionar trade-offs. Va a sonar autorizada. Y va a ser un consejo genérico que ignora todo lo que realmente importa de tu situación concreta.

La arquitectura requiere un contexto que no entra en un prompt. Requiere entender la dinámica de la organización, las habilidades del equipo, la madurez operativa y el rumbo del negocio. La IA no tiene nada de eso.

Lógica de negocio

La lógica central que le da valor a tu sistema (los algoritmos de precios, las reglas de matching, los controles de cumplimiento, los cálculos propios del dominio) es exactamente donde la IA es más peligrosa.

¿Por qué? Porque genera código que parece correcto. Compila. Pasa las pruebas básicas. Pero codifica supuestos sobre tu dominio que pueden estar sutilmente equivocados. Y los bugs sutiles en la lógica de negocio son de los que cuestan dinero real y erosionan la confianza de los usuarios.

Tuve un caso en el que el código generado por IA para un cálculo de descuentos manejaba bien los descuentos porcentuales, pero los aplicaba en el orden equivocado cuando se combinaban con descuentos de monto fijo. El código se veía limpio. Las pruebas, que también generó la IA, pasaban. El bug llegó a staging y habría costado miles en órdenes con precios incorrectos.

Tu lógica de negocio es tu ventaja competitiva. Escríbela tú. Entiende cada línea.

Seguridad

No dejes que la IA escriba tus flujos de autenticación, tu lógica de autorización, tu validación de entradas ni nada relacionado con la seguridad. Los modelos de IA se entrenan con un corpus enorme de código, y una parte importante de ese código tiene vulnerabilidades.

La IA va a generar consultas SQL sin parametrizar. Va a crear validaciones de JWT que no revisan la expiración. Va a escribir manejadores de carga de archivos sin límite de tamaño ni validación de tipo. No siempre, pero sí con la frecuencia suficiente como para que no puedas confiar en ella.

La seguridad es un terreno en el que "funciona la mayoría de las veces" es completamente inaceptable.

La diferencia entre "asistido por IA" y "generado por IA"

Este es el marco que uso para pensar la IA en mi flujo de trabajo, y creo que es la distinción más importante de toda esta conversación.

Asistido por IA: yo manejo. Entiendo el problema, sé cómo debería verse la solución y uso la IA para acelerar las partes mecánicas de la implementación. Reviso cada línea, tomo las decisiones y la IA se encarga del tipeo.

Generado por IA: la IA maneja. Describo lo que quiero, la IA produce la solución y la entrego con una revisión mínima. En esencia, estoy tercerizando el entendimiento.

El primer enfoque te hace más rápido. El segundo te vuelve peligroso.

Mi regla es esta: si no puedes explicar cada línea del código generado por IA, no deberías entregarlo. No "entiendo más o menos lo que hace": deberías poder explicar por qué se tomó cada decisión, cuáles son los casos borde y cómo falla.

Si no puedes hacerlo, no tienes una solución. Tienes un pasivo.

Cómo uso la IA en el día a día

Este es mi flujo de trabajo real:

Acelerar la revisión de código por la mañana: uso la IA para obtener un resumen rápido de los PRs grandes antes de hacer mi revisión detallada. "Resume los cambios de este PR y señala posibles problemas." Eso me da un mapa antes de meterme en el terreno. Sigo revisando cada archivo, pero sé dónde concentrar la atención.

Generación de pruebas: cuando escribo un servicio nuevo, primero hago la implementación y después le pido a la IA el andamiaje de las pruebas. Las modifico mucho: agrego casos borde, corrijo aserciones y me aseguro de que las pruebas validen comportamiento y no implementación. Pero el andamiaje ahorra entre un 30 y un 40 % del tiempo.

Explorar librerías nuevas: antes de leer la documentación completa, le pido a la IA que me explique los conceptos centrales y los patrones comunes. Eso me da un modelo mental que hace la documentación más digerible. Siempre seguido de leer la documentación real.

Acelerar el boilerplate: DTOs, mappers, configuración, archivos de migración. Cualquier cosa en la que el patrón esté establecido y yo esté traduciendo una estructura conocida a código.

Para qué nunca uso la IA: decisiones de arquitectura, diseño de esquemas de base de datos, lógica de seguridad, caminos de código críticos para el rendimiento, implementación de reglas de negocio o cualquier código en el que equivocarse sutilmente tenga consecuencias importantes.

Por qué los fundamentos importan MÁS con IA, no menos

Esta es la postura que puede resultar polémica: la IA hace que los fundamentos de la ingeniería de software sean más importantes, no menos.

Si no entiendes los patrones de diseño, no puedes evaluar si el patrón que sugiere la IA es el adecuado. Si no entiendes los índices de base de datos, no vas a notar que la consulta que generó la IA va a hacer un escaneo completo sobre una tabla de un millón de filas. Si no entiendes la semántica de HTTP, no vas a detectar que la IA usó POST donde correspondía PUT.

La IA amplifica lo que ya sabes. Si entiendes el diseño de sistemas en profundidad, la IA te hace muchísimo más rápido. Si no entiendes los fundamentos, la IA te hace muchísimo más eficiente produciendo software roto.

Los desarrolladores a los que mejor les va con las herramientas de IA son los que ya tenían fundamentos sólidos. Usan la IA como una herramienta eléctrica, no como una muleta. Saben lo suficiente para:

Evaluar críticamente lo que produce la IA
Detectar errores sutiles que a primera vista parecen correctos
Dirigir a la IA hacia la solución correcta haciendo mejores preguntas
Saber cuándo NO usarla, que quizás sea la habilidad más importante de todas

El peligro de la zona de confort

Veo un patrón que me preocupa: desarrolladores que dejan de aprender porque la IA puede cubrir los huecos. No aprenden cómo funcionan las promesas porque la IA escribe su código asíncrono. No entienden los joins de SQL porque la IA genera sus consultas. No aprenden patrones de diseño porque la IA estructura su código.

Eso funciona hasta que deja de funcionar. Y cuando deja de funcionar (cuando estás depurando una condición de carrera a las 2 de la mañana, diseñando un sistema que tiene que soportar 10 veces el tráfico o intentando descubrir por qué el código generado por IA provoca una fuga de memoria) no hay atajos. O entiendes los fundamentos o no los entiendes.

La IA es una herramienta. El ingeniero eres tú. La herramienta no reemplaza la habilidad: la exige.

Reflexiones finales

La IA en el flujo de trabajo del desarrollador es realmente útil. Soy más productivo con ella que sin ella. Eso no es hype: es mi experiencia honesta después de un uso diario intensivo.

Pero las partes útiles son las mundanas. El boilerplate. El andamiaje. La exploración. La documentación. Lo que nunca fue la parte difícil de la ingeniería de software.

Las partes difíciles (entender los problemas a fondo, tomar decisiones de arquitectura con sus trade-offs, escribir lógica de negocio correcta, construir sistemas seguros, guiar a los equipos) siguen siendo habilidades completamente humanas. Y no veo que eso vaya a cambiar pronto.

Usa las herramientas de IA. Vuélvete más rápido en las partes mecánicas del desarrollo. Pero invierte todavía más tiempo en entender los fundamentos. Porque los desarrolladores a los que les va a ir bien en un mundo potenciado por la IA no son los que mejor escriben prompts. Son los que mejor piensan.

La IA es la herramienta eléctrica. El artesano sigues siendo tú. No olvides cuál de los dos importa más.

Cómo construir side projects mientras trabajas a tiempo completo: un sistema, no motivación

Tue, 10 Feb 2026 00:00:00 GMT

Seré sincero contigo: la motivación es una pésima estrategia para entregar side projects. Llevo años construyendo cosas por mi cuenta mientras desempeño un rol exigente de tech lead a tiempo completo, y los proyectos que de verdad salieron adelante no tuvieron nada que ver con arranques de inspiración. Fueron el resultado de sistemas aburridos y repetibles.

Si esperas "sentirte motivado" para trabajar en tu side project después de un día largo, vas a esperar para siempre. Esto es lo que realmente funciona.

Por qué la motivación falla y los sistemas ganan

La motivación es una emoción. Llega a su punto máximo después de ver un video de YouTube de alguien que construyó un SaaS en un fin de semana y se desploma en el momento en que te topas con una migración de base de datos complicada a las 9 de la noche de un martes. No puedes construir nada significativo solo con emociones.

Los sistemas, en cambio, son decisiones que tomas una vez y luego sigues. Eliminan la necesidad de decidir cada día si "tienes ganas" de trabajar. La decisión ya está tomada.

Mi sistema es simple:

Bloques nocturnos de dos horas, tres noches por semana (martes, miércoles y jueves)
Sábados por la mañana, de 7 a 11 AM — mi ventana más productiva
El domingo es libre. Sin excepciones. Tu cerebro necesita recuperarse.

La clave: esos bloques de dos horas son sagrados. No reviso Slack, no arreglo "rápidamente" un bug de producción, no me pierdo en el doom-scrolling. El bloque empieza, abro mi editor y trabajo en la siguiente tarea. Eso es todo.

En seis meses, esos bloques suman aproximadamente 400 horas. Es suficiente para entregar un producto real. No un juguete: un producto real y utilizable.

Elegir proyectos de forma estratégica

Aquí es donde la mayoría de los desarrolladores se equivoca: construyen lo que suena genial en lugar de lo que resuelve un problema real. Yo también he caído en eso. Una vez pasé tres meses construyendo un gestor de tareas "revolucionario" que nadie necesitaba, empezando por mí.

Los mejores side projects nacen de tus propios puntos de dolor. Ya entiendes el problema a fondo, eres tu propio primer usuario y puedes validar al instante si la solución funciona.

Algunas de mis mejores ideas surgieron de fricciones que viví en el trabajo:

Una herramienta de legaltech nacida de ver a abogados procesar a mano documentos que podrían automatizarse en minutos
Una automatización interna que le ahorró a mi equipo horas de tareas repetitivas de deploy
Un dashboard de monitoreo porque las herramientas existentes eran demasiado caras o demasiado complejas para equipos pequeños

El filtro que uso ahora:

¿Este problema le cuesta a alguien (a mí o a alguien que conozco) tiempo o dinero reales?
¿Puedo construir una V1 utilizable en menos de 8 semanas de tiempo de side project?
¿Me interesa lo suficiente como para usarlo yo mismo durante meses?

Si alguna respuesta es no, sigo adelante. Las ideas son infinitas. Tu tiempo es el recurso escaso.

La mentalidad de MVP para quien construye en solitario

Cuando eres un equipo de una sola persona, tu MVP tiene que ser implacablemente pequeño. No hablo de la versión de MVP del pitch deck de una startup. Me refiero a esto: ¿cuál es lo mínimo absoluto que entrega valor a una persona (tú)?

Para un SaaS que estaba construyendo para automatizar la revisión de contratos, mi MVP fue:

Subir un PDF
Extraer cláusulas clave con un pipeline de NLP sencillo
Mostrarlas en una lista

Sin cuentas de usuario. Sin sistema de pagos. Sin una interfaz bonita. Solo la propuesta de valor central funcionando de punta a punta. Lo construí en tres fines de semana.

Todo lo demás —auth, facturación, un frontend como Dios manda— vino después, cuando confirmé que la idea central realmente funcionaba y que la gente la quería.

# Mi checklist de MVP antes de escribir una sola línea de código:
1. Definir la ÚNICA cosa que esto hace
2. Dibujar el camino feliz (literalmente en papel)
3. Listar lo que NO voy a construir en la V1
4. Fijar una fecha límite (normalmente 4-6 sesiones de fin de semana)
5. Entregarlo, aunque esté feo

La lista de "lo que no voy a construir" es más importante que la lista de funcionalidades. Te mantiene honesto cuando el scope creep te susurra dulces palabras a las 10 de la noche.

Decisiones de stack tecnológico para ganar velocidad

Aquí es donde los desarrolladores con experiencia tienen en realidad una desventaja. Conocemos demasiadas herramientas y nos tienta elegir la "correcta" para cada situación. En un side project, el stack correcto es aquel con el que puedes avanzar más rápido.

Mi stack para side projects:

Backend: Go o Node.js con TypeScript, según lo que encaje mejor con el problema
Frontend: Astro para sitios de contenido, Angular o React para aplicaciones (lo que domine más en ese momento)
Base de datos: PostgreSQL. Siempre. No voy a aprender una base de datos nueva a las 9 de la noche
Hosting: Railway o Fly.io para backends, Vercel o Cloudflare Pages para frontends
Auth: Lucia o un proveedor externo. Nunca implementes el tuyo

El principio: minimiza las decisiones que no se relacionan directamente con tu problema central. Cada hora que pasas debatiendo sobre ORMs es una hora que no dedicas a la funcionalidad que importa.

He visto desarrolladores pasar semanas configurando el monorepo "perfecto" con Nx, Turborepo, configuraciones personalizadas de ESLint y pipelines de CI/CD, para un proyecto que nunca entregó una sola funcionalidad. No seas esa persona.

Cómo lidiar con el burnout

Hablemos del elefante en la habitación. Trabajar a tiempo completo y construir por tu cuenta es agotador. Si no administras tu energía de forma intencional, te vas a quemar. Yo ya pasé por ahí.

Señales que aprendí a reconocer:

Temerle al bloque de la noche en lugar de sentirme neutral al respecto
Escribir código que sé que es malo, pero sin importarme lo suficiente como para arreglarlo
Saltarme bloques durante dos semanas seguidas y poner excusas
Sentir resentimiento hacia el side project

Cuando noto estas señales, sigo un protocolo estricto:

Me tomo una semana completa libre del side project. Sin culpa.
Reevalúo si todavía me importa el problema. Si no, mato el proyecto. En serio.
Reduzco el calendario de forma temporal. Dos bloques en lugar de tres. Una mañana de sábado en lugar de la sesión completa.
Hablo con alguien que no sea desarrollador. La perspectiva externa de mi pareja me ha salvado de varios callejones sin salida.

El objetivo no es esforzarte hasta romperte. El objetivo es construir de forma constante durante años. No puedes hacerlo si te apagas cada tres meses.

El efecto compuesto

Esto es lo que nadie te cuenta sobre los side projects: el valor no está solo en el proyecto en sí. Está en lo que se acumula a su alrededor.

Después de dos años de trabajo constante en side projects, tenía:

Un portafolio de productos reales y entregados (no clones de tutoriales)
Conocimiento profundo en áreas ajenas a mi trabajo diario (legaltech, automatización, NLP)
Una red de personas a quienes mis proyectos les resultaron útiles
Opiniones probadas en batalla sobre arquitectura, porque cometí todos los errores yo mismo
Confianza para tomar decisiones técnicas más rápido, lo cual mejoró directamente mi trabajo de tiempo completo

Cada proyecto me enseñó algo que hizo más rápido al siguiente. Mi primer intento de SaaS tardó seis meses y nunca se lanzó. El más reciente pasó de la idea a tener usuarios de pago en cinco semanas. La misma cantidad de bloques nocturnos, solo que con la experiencia acumulada.

Una reflexión final

Construir side projects mientras trabajas a tiempo completo no se trata de ser una persona de la "cultura del hustle". Se trata de tener control sobre tu crecimiento como ingeniero y, potencialmente, sobre tu futuro financiero.

Los desarrolladores que más admiro no son los que se matan trabajando 80 horas a la semana. Son los que se presentan con constancia, construyen cosas que les importan y saben cuándo descansar.

Arma tu sistema. Protege tus bloques. Entrega algo pequeño. Y luego hazlo de nuevo.

La motivación va y viene. El sistema se queda.

De desarrollador a arquitecto: el cambio de mentalidad del que nadie habla

Thu, 05 Feb 2026 00:00:00 GMT

Hay un momento en la carrera de todo desarrollador senior en el que te das cuenta de que escribir gran código ya no es suficiente. Los problemas que enfrentas no se resuelven con un algoritmo ingenioso ni con un patrón de diseño bien ubicado. Requieren que tomes distancia (mucha distancia) y pienses en los sistemas como un todo.

Esa transición de desarrollador a arquitecto me desordenó la cabeza durante un tiempo. No porque sea técnicamente más difícil, sino porque exige que desaprendas hábitos que te hicieron exitoso como desarrollador. Esto es lo que ese cambio significa en realidad.

Pensar en trade-offs, no en absolutos

Como desarrollador, solía pensar en términos de "la forma correcta" de hacer las cosas. Las bases de datos normalizadas son mejores. Los microservicios son el futuro. El tipado fuerte previene bugs. Todo eso me parecía verdad universal.

Como arquitecto, aprendí que casi nada es universalmente cierto. Todo es un trade-off, y tu trabajo es elegir el que menos duele en tu contexto específico.

¿Deberías usar microservicios? Depende del tamaño de tu equipo, de tu capacidad de deploy y de qué tan bien entiendas los límites de tu dominio. ¿Deberías normalizar tu base de datos? Depende de tu proporción de lecturas y escrituras y de si puedes permitirte la complejidad de los joins a escala.

El reflejo de "depende" del que se burlan los desarrolladores junior es, en realidad, sabiduría ganada a pulso. Significa que has visto suficientes sistemas triunfar y fracasar como para saber que el contexto lo determina todo.

Un ejemplo real. En un proyecto del año pasado, tuve que decidir entre:

Opción A: Arquitectura orientada a eventos con Kafka: técnicamente elegante, excelente para escalar, compleja de operar
Opción B: Llamadas REST simples entre servicios con una base de datos PostgreSQL compartida: "aburrida", pero el equipo podía entregarla y mantenerla

Elegí la Opción B. El equipo eran cuatro desarrolladores, ninguno tenía experiencia con Kafka y teníamos un plazo de tres meses. La Opción A habría sido arquitectónicamente "mejor" en el vacío. En nuestro contexto, habría sido un desastre.

El trabajo del arquitecto no es elegir la mejor solución. Es elegir la mejor solución para este equipo, este calendario y este conjunto de restricciones.

El peligro de la arquitectura de torre de marfil

He trabajado con arquitectos que diseñan sistemas desde una pizarra y nunca miran el código. Producen diagramas hermosos, ADRs exhaustivos y arquitecturas que se desmoronan en cuanto los desarrolladores empiezan a implementarlas.

Los mejores arquitectos que conozco, aquellos cuyos sistemas realmente funcionan en producción, todavía leen código a diario. No porque desconfíen de sus equipos, sino porque el código es donde la arquitectura se encuentra con la realidad.

Cuando reviso pull requests, no busco problemas de estilo ni nombres de variables. Busco:

¿Los límites que diseñé realmente se sostienen, o los desarrolladores los están rodeando?
¿La abstracción que propuse realmente reduce la complejidad, o la aumenta?
¿Están surgiendo en el código patrones que sugieren que la arquitectura necesita evolucionar?

// Este es un code smell que busco en las revisiones de código.
// Cuando ves que un servicio importa directamente los tipos
// internos de otro servicio, se ha violado el límite arquitectónico.

import (
    "github.com/company/user-service/internal/models"  // BANDERA ROJA
    "github.com/company/order-service/domain"
)

// Cómo debería verse:
import (
    "github.com/company/shared/contracts"  // Interfaz compartida
    "github.com/company/order-service/domain"
)

Si tu arquitectura no puede sobrevivir al contacto con desarrolladores reales escribiendo código real bajo plazos reales, no es arquitectura: es ficción.

La comunicación es la herramienta principal del arquitecto

Esto me tomó por sorpresa. Pensaba que convertirme en arquitecto significaba dedicar más tiempo a problemas técnicos. En realidad, paso más tiempo comunicando que programando.

Una decisión de arquitectura que el equipo no entiende no vale nada. Necesitas:

Explicar el "por qué" detrás de cada decisión importante. No solo qué estamos haciendo, sino por qué este enfoque y no las alternativas
Crear modelos mentales compartidos. Cuando digo "bounded context", todos los desarrolladores del equipo deberían imaginar lo mismo
Escuchar las objeciones. Los desarrolladores en el terreno ven cosas que tú no puedes ver desde el nivel de la arquitectura. Si tres desarrolladores te dicen que la abstracción es dolorosa, créeles
Dejarlo por escrito. Los Architecture Decision Records (ADRs) no son burocracia: son la memoria de tu equipo

Una vez diseñé lo que pensaba que era un elegante sistema de event sourcing. Durante la revisión del diseño, un desarrollador de nivel intermedio preguntó: "¿Cómo depuramos esto cuando algo falle a las 3 AM?". No tenía una buena respuesta. Esa pregunta nos ahorró meses de dolor. El desarrollador no necesitaba entender la teoría de event sourcing; necesitaba entender la realidad operativa. Y tenía razón.

Cómo DDD cambió mi forma de pensar

Domain-Driven Design fue la mayor influencia en mi transición hacia el pensamiento arquitectónico. No por los patrones tácticos (aggregates, repositories, value objects), sino por los estratégicos.

DDD me enseñó a:

Empezar por el dominio, no por la tecnología. Antes de pensar en bases de datos o frameworks, dedico tiempo a entender el problema de negocio. ¿Cuáles son las entidades? ¿Cuáles son los procesos? ¿Dónde están los límites?
Hablar el lenguaje del dominio. Si el negocio lo llama "póliza" y tu código lo llama "contrato", has creado una capa de traducción que causará bugs y malentendidos para siempre.
Identificar bounded contexts. Este es el concepto más poderoso de DDD. No todo necesita compartir el mismo modelo. El "Usuario" en el contexto de facturación es distinto del "Usuario" en el contexto social, y eso no solo está bien: es lo correcto.

# Antes de pensar con DDD:
Un modelo User gigante con 47 campos que sirve a 6 contextos distintos

# Después de pensar con DDD:
- Billing::Customer (email, payment_method, subscription_tier)
- Social::Profile (display_name, avatar, bio)
- Auth::Identity (credentials, mfa_settings, sessions)
- Support::Requester (name, contact_info, ticket_history)

Cada contexto es dueño de su modelo. Se comunican mediante interfaces bien definidas. Los cambios en uno no se propagan a los demás. Esto no es sobreingeniería: es reconocer que un único modelo que sirve a todos en realidad no sirve bien a nadie.

Tomar decisiones con información incompleta

Como desarrollador, podía reunir todos los requisitos, entender el alcance completo y luego construir. Como arquitecto, casi nunca tengo información completa cuando debo tomar decisiones.

Eliges un sistema de mensajería antes de conocer los requisitos finales de escala. Diseñas los límites de los servicios antes de que el modelo de negocio esté plenamente validado. Eliges un proveedor de nube antes de saber qué regiones vas a necesitar.

Esto solía paralizarme. ¿Y si me equivoco? A esta escala, equivocarse sale caro.

Esto es lo que he aprendido: el costo de no decidir casi siempre es mayor que el costo de una decisión equivocada. Una decisión equivocada se puede corregir. La indecisión bloquea a equipos enteros.

Mi marco para decidir bajo incertidumbre:

Haz la decisión reversible si es posible. Usa abstracciones que te permitan cambiar las implementaciones más adelante. Aquí es donde la arquitectura de puertos y adaptadores brilla
Fija una fecha de revisión. "Por ahora vamos con PostgreSQL. En tres meses evaluaremos si necesitamos migrar a una base de datos distribuida según datos reales de carga"
Documenta tus supuestos. Cuando escribes "Asumimos menos de 10 000 usuarios concurrentes en el Año 1", creas una alarma que le avisa a tu yo del futuro cuándo hay que revisar la decisión
Acepta que algunas decisiones serán erróneas. Diseña tu sistema para que las decisiones equivocadas no lo tumben todo. El bajo acoplamiento no es solo una palabra de moda: es un seguro

El miedo a equivocarse a escala

Cuando eres desarrollador y escribes un bug, afecta a una funcionalidad. Quizás unos pocos usuarios ven un mensaje de error. Lo corriges, haces deploy y sigues adelante.

Cuando eres arquitecto y tomas una mala decisión estructural, puede afectar a todos los equipos, todos los servicios y todos los deploys durante meses o años. Ese peso es real, y fingir que no existe no ayuda.

Lo manejo así:

Construyendo pruebas de concepto antes de comprometerme con decisiones arquitectónicas importantes. Un spike de dos semanas es barato comparado con una reescritura de seis meses
Pidiendo opinión a otros ingenieros con experiencia. Las revisiones de arquitectura no son señal de debilidad, sino de madurez
Estudiando los fracasos. Aprendo más de los post-mortems que de las historias de éxito. Cuando un sistema falla, las debilidades de la arquitectura se hacen visibles

De "yo lo construyo" a "lo diseño para que otros puedan construirlo"

La parte más difícil de esta transición fue soltar el código. Como desarrollador, mi identidad estaba ligada a lo que construía. Como arquitecto, mi valor viene de permitir que otros construyan bien.

Esto significa:

Escribir especificaciones claras en lugar de escribir tú mismo el código
Confiar en que tu equipo tomará las decisiones de implementación dentro de los límites que has fijado
Medir el éxito por el resultado del equipo, no por el personal
Estar tranquilo con soluciones que no son como tú las habrías programado, siempre que respeten la arquitectura

Es un tipo distinto de satisfacción. En lugar de mirar una funcionalidad y pensar "yo construí eso", miras un sistema y piensas "yo diseñé la estructura que permitió que doce personas construyeran eso sin pisarse unas a otras".

Una reflexión final

La transición de desarrollador a arquitecto no es un ascenso: es un cambio de carrera. Las habilidades que te hicieron un gran desarrollador (concentración profunda, atención al detalle, resolución práctica de problemas) no desaparecen, pero pasan a ser habilidades de apoyo en lugar de principales.

Tus habilidades principales pasan a ser: pensamiento sistémico, comunicación, toma de decisiones bajo incertidumbre y la humildad de saber que tu hermosa arquitectura será doblada, rota y parchada por la realidad.

¿Y sinceramente? Eso es lo que lo hace fascinante. Ya no estás construyendo software. Estás diseñando el entorno donde se construye el software. Haz bien eso, y todo lo demás viene solo.

Lo que entrenar para una media maratón me enseñó sobre ingeniería

Fri, 30 Jan 2026 00:00:00 GMT

La línea de salida que nadie ve

Me inscribí en mi primera media maratón pensando que sería algo divertido para un fin de semana. Algo para tachar de una lista. Lo que no esperaba era cuánto iba a reflejar el entrenamiento los mismos desafíos que enfrento cada día como Tech Lead construyendo sistemas en producción.

Llevo más de un año con entrenamiento híbrido (gimnasio tres días a la semana combinado con progresiones de carrera de 10K a 21K). Y alrededor del cuarto mes empecé a notar que casi todos los principios que me hicieron mejor corredor también me hicieron mejor ingeniero. No de una forma bonita, de póster motivacional. De una forma real y práctica, de esas que cambian cómo planifico los sprints.

Vamos por partes.

Sobrecarga progresiva = complejidad incremental

En el entrenamiento, la sobrecarga progresiva significa que no pasas de correr 5K a 21K en una semana. Aumentas un 10 % de volumen por semana. Te ganas el siguiente nivel.

En ingeniería, es el mismo principio detrás de la entrega incremental. No pasas de un monolito a microservicios en un sprint. Extraes un bounded context, validas que funciona y luego extraes el siguiente. Cada vez que he visto a un equipo intentar una migración "big bang", terminó en lágrimas. Todas y cada una de las veces.

El cuerpo se adapta al estrés de forma gradual. También lo hace un codebase. También lo hace un equipo.

Cuando incorporo a nuevos ingenieros, les doy tareas progresivamente más difíciles, no porque sea un guardián del acceso, sino porque el contexto se construye sobre el contexto. Necesitas entender el modelo de datos antes de tocar el pipeline de eventos. La sobrecarga progresiva no es solo un principio de entrenamiento. Es un principio de liderazgo.

Días de descanso = prevenir el burnout

Aquí hay algo que la cultura del gimnasio entiende mal y la cultura tech todavía peor: descansar no es pereza. El descanso es donde ocurre la adaptación.

Tus músculos no crecen durante el entrenamiento. Crecen durante la recuperación. Tus mejores ideas de ingeniería no llegan durante una sesión de código de 12 horas. Llegan en la ducha a la mañana siguiente, después de que tu cerebro ha tenido tiempo de procesar.

Respeto los días de descanso en mi plan de entrenamiento con la misma disciplina con la que exijo un ritmo sostenible a mis equipos. Nada de sprints heroicos. Nada de "aguantemos el fin de semana". He visto lo que pasa cuando te saltas los días de descanso en el entrenamiento: te lesionas. He visto lo que pasa cuando los equipos se saltan el descanso: obtienes rotación, bugs y gente que deja de importarle.

Idea clave: Si tu equipo trabaja horas extra de forma constante, no tienes un problema de capacidad. Tienes un problema de planificación.

El plan de entrenamiento = el plan del sprint

Un buen plan de entrenamiento tiene:

Periodización: ciclos de acumulación y de descarga
Especificidad: entrenamientos que apuntan a las exigencias reales de la carrera
Hitos medibles: pruebas contrarreloj, marcadores de distancia
Flexibilidad: ajustes según cómo responde el cuerpo

Reemplaza "entrenamientos" por "tareas" y "carrera" por "release" y tienes una sólida filosofía de planificación de sprints. Los mejores planes de sprint que he llevado tenían todos estos elementos. Los peores eran rígidos, poco realistas e ignoraban el feedback del equipo.

Antes planificaba los sprints como planifica un principiante su entrenamiento: meter tanto como sea posible en cada semana. Ahora planifico como un corredor con experiencia: dejo espacio para lo inesperado, incluyo la recuperación y siempre sé cuál es el entrenamiento prioritario de esa semana.

La constancia le gana a la intensidad

Esto me cambió todo.

Correr 5K cuatro veces por semana te hará más rápido que correr 15K una vez por semana y desplomarte. Desplegar a diario cambios pequeños y bien probados te llevará más lejos que releases masivos cada dos semanas.

En el entrenamiento, la constancia construye tu base aeróbica. En ingeniería, la constancia construye confianza en el deploy. Los equipos que lidero y que entregan poco y a menudo tienen menos incidentes, tiempos de recuperación más rápidos y (esta es la parte contraintuitiva) más producción total que los equipos que agrupan todo en grandes releases.

Lo mismo aplica al aprendizaje. Leer 30 minutos de documentación cada día supera a una maratón de fin de semana. Escribir un PR pequeño al día supera a un monstruo de 2000 líneas un viernes por la tarde.

El muro del km 18 = el muro del mes 6

Todo corredor de fondo conoce "el muro". En una media maratón, suele aparecer alrededor del kilómetro 18. Tu glucógeno se agotó, tus piernas gritan y tu cerebro busca cualquier excusa para parar.

En los proyectos largos hay un muro parecido. Alrededor del mes 5 o 6, la emoción inicial se acabó. Los problemas arquitectónicos difíciles ya están resueltos, pero ahora estás lidiando con integraciones, casos límite y el tipo de trabajo que nadie celebra. La moral del equipo baja. La gente empieza a cuestionar decisiones tomadas en el mes 1.

Cómo manejas el muro en el entrenamiento:

Lo esperabas. Es parte del plan.
Tienes una estrategia de nutrición. Geles, hidratación, ajustes de ritmo.
Te concentras en el siguiente kilómetro, no en la meta.

Cómo manejo el muro en los proyectos:

Aviso al equipo con anticipación. "Los meses 5-6 serán duros. Es normal."
Divido el trabajo restante en hitos visibles y completables.
Celebro las pequeñas victorias en público. ¿Entregamos el servicio de notificaciones? Eso es una victoria. Dilo en voz alta.

El juego mental es real. En ambos terrenos.

Seguimiento de métricas: ritmo/FC = observabilidad/monitoreo

Al correr, registro ritmo, frecuencia cardíaca, cadencia y variabilidad de la frecuencia cardíaca. No porque esté obsesionado con los números, sino porque sin datos solo estoy adivinando si mejoro o si estoy sobreentrenando.

En producción, medimos latencia, tasas de error, throughput y saturación. Por la misma razón.

Esto es lo que ambos me han enseñado sobre las métricas:

Las métricas de vanidad son peligrosas. El total de kilómetros corridos no te dice si te estás volviendo más rápido. El total de deploys no te dice si estás entregando valor.
Las tendencias importan más que las fotos instantáneas. Una mala carrera no significa nada. Un pico en la tasa de errores no significa nada. ¿Pero una tendencia a la baja de tres semanas en ambas? Presta atención.
Necesitas líneas base. Mi frecuencia cardíaca en reposo es de 52 lpm. Si salta a 60, algo anda mal, aunque 60 sea "normal" para otra persona. Lo mismo con tu latencia p99. Conoce TU normalidad.

// Tu observabilidad debería contar una historia, no solo mostrar números
// Mal: alertar cuando errors > 100
// Bien: alertar cuando error_rate se desvíe > 2σ de la línea base de 7 días

alert:
  name: error_rate_anomaly
  condition: |
    abs(current_error_rate - avg_error_rate_7d) > 2 * stddev_error_rate_7d
  severity: warning

Prevención de lesiones = gestión de la deuda técnica

Los corredores que se saltan el trabajo de movilidad, ignoran los dolores leves y nunca descargan terminan lesionándose. No es cuestión de si, sino de cuándo.

Los ingenieros que se saltan el refactoring, ignoran los code smells y nunca pagan la deuda técnica terminan enfrentando un incidente de producción causado por el descuido acumulado. La misma certeza.

El paralelismo es casi demasiado limpio:

Estirar y usar el foam roller = sesiones regulares de refactoring
Ignorar el dolor de rodilla = ignorar los tests inestables (flaky)
Correr con una fractura por estrés = entregar sobre bugs críticos conocidos
Buenas zapatillas = buenas herramientas e infraestructura

Programo "semanas de descarga" para mis equipos: sprints en los que reducimos deliberadamente el trabajo de funcionalidades y nos enfocamos en herramientas, cobertura de tests, actualización de dependencias y refactoring. No es productividad perdida. Es prevención de lesiones.

El juego mental

Lo más difícil de correr 21K no es lo físico. El día de la carrera, tu cuerpo está listo. Lo difícil es la voz en tu cabeza en el kilómetro 15 diciéndote "podrías simplemente caminar".

Lo más difícil de liderar un proyecto largo no es lo técnico. Tu equipo tiene suficiente habilidad. Lo difícil es mantener la convicción cuando los stakeholders están ansiosos, cuando la competencia lanzó algo llamativo, cuando el atajo fácil está ahí mismo.

En ambos casos, la respuesta es la misma: confía en el entrenamiento. Confía en el proceso que construiste. Confía en el plan. Confía en que la constancia se acumula. Y cuando se ponga difícil (y se va a poner difícil), recuerda que te preparaste para este momento específicamente.

Cruzar la línea de meta

Terminé mi primera media maratón en 1:52. No es de élite. No es un récord. Pero terminé. Y terminé porque respeté el proceso, escuché a mi cuerpo, me mantuve constante y no abandoné en el kilómetro 18.

Todo proyecto exitoso que he liderado siguió el mismo patrón. Nada glamoroso. Nada revolucionario. Solo esfuerzo constante, evaluación honesta, recuperación planificada y la disciplina de seguir adelante cuando dejó de ser divertido.

La línea de meta, ya sea de una carrera o de un release, es solo el resultado visible de meses de trabajo invisible. ¿Y ese trabajo invisible? Ahí es donde ocurre la verdadera ingeniería.

Átate los cordones. Entrega en pequeño. Mantente constante. El muro viene, y estás listo para él.

Lecciones de operar sistemas en producción con equipos distribuidos

Sun, 25 Jan 2026 00:00:00 GMT

La alerta de las 3 AM que cambió mi forma de pensar sobre los equipos

Dormía profundamente cuando llegó la alerta de PagerDuty. Un servicio de checkout de un e-commerce estaba devolviendo errores 500 a un ritmo que haría que tu dashboard de monitoreo pareciera un sismógrafo. El servicio corría en EKS, la cola se acumulaba en SQS y nuestro equipo estaba repartido en tres zonas horarias: Ecuador, Argentina y España.

Esa noche me enseñó más sobre sistemas distribuidos Y equipos distribuidos que cualquier libro de arquitectura. Porque cuando producción está en llamas, no le importa dónde vive tu equipo.

Esto es lo que he aprendido tras años operando sistemas en producción con equipos que nunca comparten una oficina.

La observabilidad es el gran igualador

Cuando tu equipo está distribuido, nadie puede darle un toque en el hombro a un colega y preguntarle "oye, ¿esto te parece raro?". La observabilidad llena ese vacío. Se convierte en el lenguaje común que tu equipo habla entre zonas horarias.

Estandarizamos OpenTelemetry para la instrumentación y el logging estructurado en todas partes. No porque esté de moda, sino porque cuando un ingeniero en Argentina toma un incidente a las 9 AM de su hora, necesita ver el MISMO contexto que vio el ingeniero en Ecuador a las 2 AM.

Lo que realmente funciona:

Logging estructurado con correlation IDs. Cada request recibe un trace ID que fluye por cada servicio, cada mensaje de cola y cada llamada a la base de datos. Cuando algo se rompe, sigues un solo ID a través de todo el sistema. Sin adivinar.
Métricas a nivel de negocio, no solo de infraestructura. El uso de CPU está bien. "Las órdenes por minuto cayeron un 40 % en los últimos 5 minutos" es accionable.
Dashboards que cuentan historias. Construimos los dashboards alrededor de los recorridos del usuario, no de los servicios. El dashboard "Checkout Health" muestra todo, desde la creación del carrito hasta la confirmación del pago, en una sola vista.

// Logging estructurado que de verdad ayuda durante los incidentes
// Mal: logger.error("Payment failed")
// Bien:
logger.error({
  event: 'payment_processing_failed',
  orderId: order.id,
  paymentProvider: 'stripe',
  errorCode: err.code,
  amount: order.total,
  currency: order.currency,
  traceId: context.traceId,
  customerSegment: order.customer.tier,
  retryAttempt: attempt,
  latencyMs: Date.now() - startTime,
});

La diferencia entre esas dos líneas de log es la diferencia entre "algo se rompió" y "sé exactamente qué se rompió, para quién y cómo arreglarlo".

Gestión de incidentes entre zonas horarias

Gestionar incidentes con un equipo distribuido requiere una estructura explícita. No puedes depender de "todos se conectan a una llamada" cuando son las 3 AM para la mitad de tu equipo.

Este es el sistema que construimos:

Rotación de guardia follow-the-sun. Cada zona horaria tiene un on-call primario y uno secundario. El incidente se queda con quien lo tome hasta que se resuelva O se traspase explícitamente con un resumen escrito.
Canales de incidente, no hilos. Cada P1/P2 tiene un canal de Slack dedicado con un bot que registra la hora de cada actualización. Cuando despierta la siguiente zona horaria, lee el canal de arriba abajo y sabe exactamente en qué punto están las cosas.
La regla de los 15 minutos. Si no puedes identificar la causa raíz en 15 minutos, escala. No porque seas incompetente, sino porque estás gestionando el tiempo, no el ego. Cuanto antes traigas ayuda, antes se desbloquean los usuarios.

El traspaso es la parte más difícil. Usamos una plantilla:

## Incident Handoff — [INC-2024-0847]
**Status:** Investigating / Mitigated / Monitoring
**Impact:** ~12% of checkout attempts failing in US-East
**What we know:** SQS consumer lag spiking on payment-processor queue
**What we've tried:** Scaled consumers to 8 replicas (no improvement)
**Current hypothesis:** Stripe webhook endpoint is rate-limiting us
**Next steps:** Check Stripe dashboard, consider circuit breaker activation
**Key links:** [Dashboard](link) | [Logs query](link) | [Trace](link)

Esa plantilla nos ha ahorrado horas de "espera, ¿qué pasó mientras dormía?".

Runbooks que realmente se usan

La mayoría de los runbooks son documentos de cementerio. Se escriben una vez, nunca se actualizan y nunca se consultan durante un incidente real. Yo también he sido culpable de esto. Esto es lo que cambió.

Los runbooks funcionan cuando están:

Enlazados directamente desde las alertas. Cada alerta de PagerDuty incluye un enlace al runbook. No lo buscas: está ahí, en la notificación.
Escritos como árboles de decisión, no como novelas. "Si la métrica X supera Y, haz Z." No tres párrafos de contexto.
Probados con regularidad. Hacemos "simulacros de runbook" cada mes. Eliges un escenario, sigues el runbook y compruebas si todavía funciona. Si no, lo actualizas en el momento.
A cargo del equipo de guardia. Quienes usan los runbooks son quienes los mantienen. No un equipo de documentación aparte.

# runbook: payment-queue-lag
trigger: sqs_queue_depth > 10000 for 5m
steps:
  - check: "Are consumers running?"
    command: "kubectl get pods -l app=payment-consumer -n production"
    if_no: "kubectl rollout restart deployment/payment-consumer -n production"
    if_yes: "continue"
  - check: "Is Stripe responding?"
    command: "curl -o /dev/null -s -w '%{http_code}' https://api.stripe.com/v1/health"
    if_5xx: "Activate circuit breaker: kubectl set env deployment/payment-consumer STRIPE_CIRCUIT=open"
    if_200: "continue"
  - check: "Consumer error logs"
    command: "kubectl logs -l app=payment-consumer --tail=100 | grep ERROR"
    action: "Analyze error pattern and escalate if unknown"

"You Build It, You Run It" en la práctica

Esta filosofía suena genial en las charlas de conferencias. En la práctica, con un equipo distribuido, requiere infraestructura.

No puedes esperar que los desarrolladores "operen" lo que construyen si:

No tienen acceso a los logs de producción
No pueden hacer deploy sin abrir un ticket
Las alertas llegan a un equipo de operaciones aparte en lugar de al equipo que construye
No existe una forma segura de revertir sus cambios

Lo que implementamos en realidad:

Cada equipo es dueño de las alertas, dashboards y runbooks de su servicio. No ops. No SRE. El equipo que escribe el código.
Pipelines de deploy con análisis canary automatizado. Los ingenieros despliegan su propio código. El pipeline vigila las tasas de error durante 10 minutos. Si se disparan, hace rollback automáticamente. Esto le da a los desarrolladores confianza al desplegar sin necesidad de un guardián de operaciones.
Feature flags para todo lo que ve el usuario. Despliega el código cuando quieras. Activa las funcionalidades en horario laboral, cuando el equipo está despierto y atento.

# Estrategia de deploy canary en EKS
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: checkout-service
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-service
  progressDeadlineSeconds: 600
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m

Patrones de comunicación asíncrona que funcionan

Los equipos distribuidos viven y mueren por su comunicación asíncrona. Las reuniones entre zonas horarias son caras y a menudo innecesarias. Esto es lo que reemplazó a la mayoría de las nuestras:

ADRs (Architecture Decision Records) para cada decisión importante. No porque amemos la documentación, sino porque cuando tu compañero en España despierta, necesita entender POR QUÉ elegimos SQS en lugar de Kafka, no solo que lo hicimos.
Videos en Loom en lugar de reuniones. Un recorrido en video de cinco minutos por un PR o un documento de diseño. Quien lo recibe lo ve a 1.5x en su horario. La respuesta, por escrito.
Documentos RFC con fechas límite explícitas. "Comentarios hasta el jueves EOD UTC." Sin ambigüedad.
Standups asíncronos diarios en Slack. Tres líneas: qué hice, qué estoy haciendo y si tengo bloqueos. Se publican cuando empieza tu día. Se leen cuando empieza el de ellos.

La regla general: si la información tiene que sobrevivir más tiempo que la reunión, nunca debió ser una reunión.

El problema de la confianza al desplegar

El momento más aterrador en la operación de un equipo distribuido es desplegar un viernes por la tarde cuando el equipo que construyó la funcionalidad está a punto de desconectarse por el fin de semana.

Lo resolvimos con capas de confianza:

Feature flags: despliega el código apagado y actívalo cuando el equipo esté en línea
Canary releases: desplazamiento automático de tráfico con rollback automático
Ventanas de deploy: desplegamos en cualquier momento, pero las activaciones ocurren durante las horas de solapamiento (nuestra "ventana dorada" es de 10 AM a 1 PM UTC, cuando todas las zonas horarias están despiertas)
Notificaciones SNS: cada deploy dispara una notificación al canal del equipo con el resumen del commit, el autor y las instrucciones de rollback

El objetivo no es frenar los deploys. Es hacer que cada deploy sea aburrido. Los deploys aburridos significan que tu sistema está sano.

Historia de guerra: la cola silenciosa

Un sábado, nuestra cola de procesamiento de órdenes (SQS) dejó de consumir mensajes. Sin errores. Sin alertas. Solo... silencio. Las órdenes se acumulaban, pero todo se veía verde en nuestros dashboards.

¿La causa raíz? Un nodo de Kubernetes había sido acordonado (cordoned) durante el mantenimiento, los pods consumidores fueron desalojados y el Horizontal Pod Autoscaler tenía un mínimo de réplicas igual a cero. Así que cuando los pods fueron desalojados, el HPA estaba perfectamente conforme con cero réplicas procesando cero mensajes.

Lo que cambiamos después:

El mínimo de réplicas para los consumidores críticos ahora es 2. Siempre.
Agregamos una alerta de "cero consumidores": si cualquier cola SQS crítica tiene cero consumidores activos por más de 2 minutos, se avisa de inmediato.
Runbook actualizado el mismo día.
Post-mortem compartido con todos los equipos, no solo con el afectado.

Sin culpas. Solo aprendizaje.

Construir una cultura de responsabilidad, no de culpa

Los post-mortems sin culpa no son solo una buena idea. Son un mecanismo de supervivencia para los equipos distribuidos. Y la razón es esta: si la gente teme que le echen la culpa, esconde los problemas. Si esconde los problemas, los problemas crecen. Y si los problemas crecen entre zonas horarias, te enteras cuando ya es un desastre.

Nuestra plantilla de post-mortem tiene una sola regla: ningún nombre de persona en la sección de causa raíz. Falló el sistema. No una persona.

Nos enfocamos en:

¿Qué controles faltaban que permitieron que esto ocurriera?
¿Qué señales pasamos por alto y por qué?
¿Qué automatización lo habría detectado antes de que los usuarios lo notaran?

¿El resultado? Los ingenieros reportan de forma proactiva los casi-incidentes. Avisan "esto se siente frágil" sin miedo. Y todo el equipo mejora porque la información fluye libremente.

La documentación es una dependencia de producción

Lo diré sin rodeos: si tu sistema no puede ser operado por alguien que no estuvo en la sala cuando se construyó, tu documentación está fallando. Y con equipos distribuidos, SIEMPRE hay alguien que no estuvo en la sala.

Tratamos la documentación como tratamos las pruebas. No es opcional. No es "deseable". Es una dependencia de producción. Si entregas un servicio nuevo sin un README actualizado, un runbook operativo y un diagrama de arquitectura, tu PR no se mergea.

¿Es trabajo extra? Sí. ¿Se paga solo la primera vez que alguien en otra zona horaria tiene que depurar tu servicio a las 3 AM? Totalmente.

La verdad honesta

Operar sistemas en producción con equipos distribuidos es más difícil que hacerlo en una oficina compartida. Quien te diga lo contrario te está vendiendo algo. Pero también es posible, sostenible y, cuando lo haces bien, increíblemente gratificante.

La clave no son las herramientas sofisticadas ni los procesos complejos. Es construir sistemas (tanto técnicos como humanos) que asuman que siempre hay alguien durmiendo, siempre hay alguien depurando y la documentación es lo primero que va a leer.

Haz que esa experiencia sea excelente y todo lo demás vendrá solo.