He construido un agente que hace merge de más de 100 PRs en mi trabajo en Amazon. Este framework es el que uso realmente, y en este artículo incluyo un paso a paso para crear un agente de respuesta a incidentes para cuando estés on-call.

Todo el mundo habla de agentes de IA, pero muy pocas personas los están construyendo realmente. Conectar un chatbot a tu sitio web es solo una actualización de la UI. La mayor oportunidad está en la IA agéntica, y la mayoría de la gente se la está perdiendo.

Diferencia entre un LLM y un agente de IA

Imagina que acabas de comprar unos muebles y ahora tienes que montarlos. El conjunto fijo de instrucciones que viene en la caja es un workflow. Es un camino lineal que funciona perfectamente siempre que todo vaya bien. Es el equivalente a los scripts y lenguajes de programación. Pero si cometes un error y rompes una pieza de madera, las instrucciones no pueden ayudarte. No hay forma de recuperarse de eso.

Un LLM sería como tener una línea de atención al cliente disponible para llamar. Puedes describir la pieza rota y te darán una respuesta brillante y empática. Incluso podrían explicar por qué se rompió la madera. Pero al final de la llamada, sigues sentado en el suelo con una pieza rota. No importa lo amable que sea la otra persona, no tiene manos para ayudarte con tu pieza rota.

Tú eres el agente en este escenario. Eres quien tiene las herramientas, como un martillo, clavos, pegamento y un taladro. Eres quien tiene el cerebro para tomar decisiones sobre cómo usar mejor esas herramientas y cómo recuperarte de errores que nunca estuvieron en las instrucciones iniciales.

En este artículo, quiero mostrarte cómo construir agentes de IA, dándoles las herramientas y el conocimiento que necesitan para trabajar en tu nombre. Usaré un agente de respuesta a incidentes como ejemplo, pero los principios de darle a una IA tanto un cerebro como un par de manos se aplican a casi cualquier proceso.

Vamos a empezar.

Suscríbete ahora

Qué vas a aprender sobre agentes de IA

• Las diferencias entre LLMs, workflows y agentes de IA.

• Por qué la naturaleza no determinista de los agentes de IA es una ventaja.

• Un framework de 10 pasos para construir tu primer agente de IA autónomo desde cero.

¿Qué es un agente de IA?

Un agente de IA es un programa que usa un LLM como cerebro para tomar decisiones, combinado con herramientas que le permiten actuar en el mundo real. A diferencia de un chatbot, un agente no solo genera texto: percibe su entorno, planifica una secuencia de pasos y ejecuta acciones reales. El agente busca información, llama a APIs, escribe código, y envía notificaciones hasta completar un objetivo.

La clave está en el bucle de retroalimentación. El agente actúa, observa el resultado y decide el siguiente paso. Si algo falla, no se detiene: ajusta su enfoque. Esto lo hace útil para procesos complejos que requieren adaptación en tiempo real, no solo respuestas predefinidas.

Un agente de IA tiene cuatro componentes esenciales:

1. Un modelo de lenguaje que razona,

2. Herramientas que le dan acceso al mundo exterior,

3. Memoria para recordar el contexto entre sesiones,

4. Un mecanismo de orquestación que coordina los pasos.

Sin los cuatro, tienes un chatbot, no un agente.

Tipos de agentes de IA

• Agentes reactivos: responden al entorno sin memoria de estados anteriores.

• Agentes basados en objetivos: planifican pasos para alcanzar un estado deseado.

• Agentes de aprendizaje: mejoran con retroalimentación.

• Sistemas multi-agente: varios agentes especializados colaboran.

Suscríbete ahora

¿Por qué los agentes de IA son más fiables que el código tradicional?

Veo mucho escepticismo sobre la IA porque no es tan fiable como el código tradicional. Estamos acostumbrados al código que hace exactamente lo mismo cada vez. Sin embargo, creo que esta falta de determinismo es realmente algo bueno para ciertas tareas.

Los humanos no somos tan fiables como una máquina, pero somos nosotros quienes arreglamos las máquinas cuando se rompen. Preferimos a los humanos usando máquinas porque aporta lo mejor de ambos mundos. Las máquinas nos dan la velocidad y precisión del determinismo, mientras que los humanos hacen que las cosas funcionen cuando no salen como se esperaba.

Un agente imita esta capacidad humana de adaptarse a nuevas situaciones. Cuando un sistema falla de una manera que no habías previsto, un agente puede mirar los logs y cambiar su enfoque. Es self-healing.

Sin embargo, para sacar el máximo provecho de los agentes, en lugar de usar la herramienta genérica estándar, necesitas crear tus propios agentes adaptados a tu caso de uso.

Cómo construir tu primer agente de IA

Las empresas de IA nos proporcionan agentes genéricos que tienen capacidades de planificación y herramientas integradas. Aunque son útiles, no creo que queramos un asistente genérico para tareas especializadas.

También ofrecen puntos de integración para nuestras propias memorias y herramientas. Aquí es donde está la oportunidad. De la misma manera que una empresa contrataría a un ingeniero de software en lugar de a un “humano genérico”, queremos ese mismo nivel de experiencia en nuestros agentes.

Construir un agente no es un proceso de un solo paso en el que simplemente pulsas un interruptor y todo funciona perfectamente. Es un proceso iterativo en el que descargas poco a poco partes de tu carga cognitiva en la máquina mientras vigilas de cerca su rendimiento.

He seguido este framework de 10 pasos que comienza con trabajo puramente manual y termina con una flota de agentes autónomos trabajando juntos. Este proceso comienza con la forma en que siempre hemos trabajado: resolviéndolo manualmente.

Suscríbete ahora

Paso 1. Haz el trabajo manualmente

El primer paso es siempre hacer el trabajo tú mismo. Recomiendo esbozar los pasos tal como si tuvieras que documentar el runbook para que otra persona lo siga.

• Abres el dashboard de monitorización y revisas cualquier métrica fuera del patrón habitual.

• Revisas los runbooks para obtener información de resolución de problemas para esa métrica en particular.

• Consultas los logs de errores de los últimos quince minutos, buscando peticiones que terminen con un error HTTP 500.
  

Estado actual: En esta etapa, tú eres el cuello de botella en todo el proceso. Cada paso requiere tu intervención manual y tu atención. Esta es la base que queremos mejorar.

Suscríbete ahora

Paso 2. Empieza a usar un LLM

Ahora que tienes un proceso manual sólido, puedes usarlo como guía para un LLM. Esto nos mueve del trabajo manual a tener un asistente que puede analizar los datos por ti. Puedes promptear a la IA copiando y pegando los logs de tu terminal o las métricas de tu dashboard. Sugiero prestar mucha atención a los prompts que usas habitualmente.

“Revisa estos logs para encontrar qué error está ocurriendo: [copia y pega de logs]”

En este punto, es importante notar las áreas donde la IA no hace lo que quieres y cómo la rediriges al camino correcto cuando se desvía.

Estado actual: La IA puede empezar a analizar patrones, pero todavía tienes que orquestarlo todo y mover los datos manualmente.

Suscríbete ahora

Paso 3. Añade herramientas MCP

En esta etapa, tienes un socio de IA que ayuda con el análisis, pero sigues atrapado en medio actuando como un puente. El siguiente paso es dejar de copiar y pegar datos. Puedes usar el Model Context Protocol (MCP1) para permitir que la IA tome acciones por ti. MCP es como HTTP para agentes de IA. Es una API que permite al modelo ejecutar una operación en otros sistemas.

Una vez que te conectas a los servidores MCP adecuados y habilitas las herramientas MCP, tus prompts se verían así:

• “Obtén las alarmas que se activaron en los últimos 15 minutos. Solo debes darme el nombre de la alarma...”
  

• “Revisa los logs en busca de peticiones que terminen con un error HTTP 500. Debes darme el mensaje del log, el mensaje de error y el stack trace...”
  

La IA puede obtener los detalles del incidente por su cuenta.

Estado actual: El humano puede dirigir todo el proceso desde la interfaz de la IA sin tener que cambiar entre diferentes pestañas y herramientas.

Suscríbete ahora

Paso 4. Añade Skills del agente

Hasta este punto, todavía tienes que ser un experto en respuesta a incidentes. La IA es útil para hacerlo todo desde un solo lugar. Este es el momento en el que empezaremos a mirar las notas que hemos estado tomando sobre cómo resolver el proceso y dónde la IA suele tomar el camino equivocado.

Tenemos que preparar a la IA para la respuesta a incidentes de la misma manera que prepararíamos a un ingeniero junior recién contratado:

• Enseña exactamente cómo usar cada herramienta.

• Enseña cómo quieres que se haga el trabajo.

Podemos combinar guías y SOP. Estos proporcionan instrucciones paso a paso para tareas rutinarias. Los escribiríamos en lenguaje humano con pequeños scripts para resolver un problema con determinismo.

Por ejemplo, si las herramientas MCP requieren una consulta como entrada, podemos crear la Skill de construir una consulta. Combinaremos una guía en markdown que contenga los campos de los logs con algunos scripts para construir consultas a partir de una plantilla. Esto es mucho mejor que hacer que la IA escriba consultas complejas cada vez. Reduce las alucinaciones de campos que no existen en tus logs. Llamamos a estas piezas de lógica reutilizables Skills del agente.

Las Skills del agente son geniales porque se cargan en el modelo solo cuando es necesario. El agente puede tener habilidades para métricas y logs. Si solo preguntamos por alarmas activadas, el agente ignora los datos de los logs. Simplemente no los necesita. Esto ahorra memoria.

Con las skills del agente, nuestra interacción sería así (la barra diagonal es la sintaxis utilizada en IDEs como Cursor2 para forzar al agente a cargar una skill en particular).

/Metrics-and-alarm-management Encuentra las alarmas activadas

<Respuesta del LLM con información de métricas>

/My-service-logs-management Encuentra los logs con errores en estos endpoints

<Respuesta del LLM con la información de los logs>

/Code-expert ¿En qué parte del código se emite este log?

<Respuesta del LLM con la información del código>

Estado actual: Ahora le hemos enseñado a la IA cómo queremos que se hagan ciertas cosas, como la gestión de métricas e información de logs. El humano está orquestando el proceso para hacer las cosas en orden.

Suscríbete ahora

Paso 5. Añade memoria

Hemos dado a nuestro agente herramientas y experiencia en el dominio, pero cada vez que inicias un nuevo chat, es como si el agente tuviera amnesia. Sabe cómo resolver un incidente, pero no recuerda el que arreglaste ayer.

Un agente necesita contexto para ser efectivo a lo largo del tiempo. Puedes añadir archivos simples de memoria a corto y largo plazo a tu sistema.

La memoria a corto plazo está integrada por diseño en el agente. Esta es esencialmente la capacidad de la IA para recordar los mensajes anteriores de tu conversación actual. Le ayuda a mantenerse en el camino sin que tengas que repetirte. Al hacer una llamada a la API para obtener la respuesta del modelo, se envían los mensajes anteriores junto con los nuevos.

Para un agente de respuesta a incidentes, también queremos algo de memoria a largo plazo. Hemos añadido un tipo de memoria gracias a las skills, pero podemos añadir más contexto creando archivos a los que la IA pueda acceder.

Hace un tiempo, cada empresa tenía su propio formato, pero ahora se han puesto de acuerdo en un estándar llamado Agents.md3. Esto significa que la información dentro de un archivo Agents.md será leída por la IA sin importar qué IA sea. Además, cada implementación te permite señalar qué carpetas o archivos usar para el contexto del agente.

Estado actual: Seguimos prompteando a la IA de la misma manera. Utiliza datos de skills y logs. También lee archivos para entender el sistema que está depurando. Esto ayuda a la IA a encontrar errores pasados y las soluciones que funcionaron.

Suscríbete ahora

Paso 6. Orquesta con SOP del agente

Hasta ahora, hemos dado a nuestro agente un cerebro, un par de manos a través de herramientas MCP y una memoria. Sin embargo, tú sigues siendo quien dirige cada movimiento. Aunque el agente es ahora más capaz, todavía requiere que decidas manualmente qué usar y cuándo. Este es el cuello de botella que resolvemos con los SOP del agente.

En lugar de promptear a la IA para que use una serie de skills una por una, puedes crear un proceso paso a paso para que la IA lo siga. Esto es lo que se llama un Procedimiento Operativo Estándar o SOP para tu agente.

Un SOP del agente es un archivo escrito según el RFC 21194. Este RFC define palabras clave en mayúsculas (MUST, SHOULD, MAY, etc.) para especificar niveles de requisitos. Además de eso, contiene los pasos en orden.

Aprendí sobre este concepto en el trabajo, ya que Amazon lo usa en sus agentes Kiro5 y Strands6. Sin embargo, también estoy usando SOP del agente con Cursor y Claude Code7 fácilmente. Solo tienes que escribir el archivo markdown como una Skill del agente.

Ahora, en lugar de promptear paso a paso, simplemente ejecutamos nuestro agente con ese SOP. Por ejemplo, si envolvemos nuestro SOP en una skill:

/Incident-response-agent-sop Investiga el incidente reportado en JIRA-1234

Estado actual: Esto hace que el agente sea mucho más autónomo. El humano solo invoca el SOP correcto y el agente se encarga del resto. Es como un gerente de alto nivel encontrando al ingeniero adecuado para incluirlo en una llamada.

Suscríbete ahora

Paso 7. Define un agente

En este punto, tenemos muchas herramientas MCP, skills y SOP del agente que deben estar configurados y disponibles para que nuestro agente funcione.

Esto es fácil si es tu primer agente, pero cuando tienes docenas de ellos, cada uno usando su propio conjunto de artefactos, las cosas se vuelven difíciles. Resolvimos este problema en el software tradicional con las dependencias. Declaramos de qué paquetes depende nuestro software para que pueda ejecutarse en diferentes entornos.

Ahora es el momento de declarar esas dependencias con un nuevo artefacto llamado agente. De esta manera tendríamos nuestro agente de respuesta a incidentes y podemos definir otros agentes para otros fines.

Esto garantiza que la IA tenga todas sus herramientas juntas y no necesites proporcionarlas manualmente. Actualmente no existe un gestor de paquetes adecuado para instalar todo esto, pero es solo cuestión de tiempo.

Estado actual: Ahora tenemos nuestro agente y podemos delegarle todo el trabajo de la investigación de respuesta a incidentes. Solo lo invocamos y esperamos los resultados.

Suscríbete ahora

Paso 8. Ejecuta tu agente periódicamente

Hasta este punto, tenemos un agente totalmente definido que sabe exactamente qué hacer, pero solo se mueve cuando se lo pides. Has construido una gran herramienta, pero sigues siendo tú quien tiene el botón de encendido.

Ahora que podemos delegar la mayor parte del trabajo a la IA, podrías preguntar, ¿por qué sigo recibiendo avisos a las 3 de la mañana solo para invocar al agente y esperar? Es hora de configurar el agente de IA para que se ejecute de forma autónoma.

Recomiendo usar herramientas de CLI para ejecutar tu agente de IA de forma independiente. Podemos empezar con un script simple que busque trabajo y ejecute el agente de IA cuando lo encuentre, de lo contrario, que duerma N minutos.

Estado actual: Ahora el humano no está involucrado en activar al agente, sino que encontrará la alarma y la salida del agente juntas.

Suscríbete ahora

Paso 9. Mejora la gestión del estado

El agente ahora funciona por su cuenta, pero sigue aislado en tu máquina local usando bucles básicos. Para que sea una parte real de tu equipo, debe integrarse en tu entorno de producción.

El objetivo es definir un workflow completo que active a los agentes de IA en el momento adecuado sin intervención humana. Por ejemplo, un webhook de PagerDuty podría activar automáticamente el agente de IA en una Lambda.

Para informes periódicos, es posible que desees configurar un cron8 job que active el agente de IA en ciertos períodos de tiempo. El agente de IA realiza la investigación y luego publica un resumen de la root cause o un informe periódico en un canal de Slack. Esto significa que tu agente está trabajando mientras duermes, incluso si solo hace una cosa específica bien.

Estado actual: Ahora nuestro agente es como un ingeniero real involucrado cuando ocurre un incidente, o un ingeniero que tiene trabajo programado en su calendario.

Suscríbete ahora

Paso 10. Escala a múltiples agentes

En esta etapa, tienes un agente especializado trabajando las 24 horas del día, los 7 días de la semana. Sin embargo, a medida que tu sistema crece, un agente puede sobrecargarse con demasiadas responsabilidades. Al igual que no le pedirías a un solo ingeniero que maneje cada microservicio, no deberíamos pedirle a un solo agente que lo haga todo.

El paso final es tener múltiples agentes colaborando en el mismo incidente. Cada agente puede tener una función diferente basada en su experiencia.

• Un agente recopila los logs sin procesar mientras otro busca problemas de infraestructura conocidos.

• Otro agente podría revisar los despliegues de código recientes en busca de errores.

Existen diferentes paradigmas de orquestación que puedes usar, como secuencial, enrutamiento o swarms. Incluso para la misma función, no hay límite en cuánto te especialices. Si un agente de respuesta a incidentes termina teniendo demasiados detalles, puedes crear agentes para revisar diferentes partes del sistema.

Necesitas un poco de abstracción para gestionar tu fuerza de trabajo de IA, al igual que un gerente coordina un equipo de especialistas. Tú haces lo mismo, múltiples agentes especialistas y un gerente que invoca a cada subagente.

Puedes usar diferentes disparadores, como horarios o eventos, para que los agentes colaboren a través del sistema de archivos. No es necesario empezar con protocolos complejos de comunicación entre agentes, sino más bien:

• Empieza con un agente orquestador activado por eventos, programación o consultas periódicas.

• El orquestador invoca a otros subagentes que también has definido. La mayoría de las empresas de IA ya implementan subagentes.

• Todos los agentes escriben en el sistema de archivos, por lo que ven el trabajo de los demás.

Te sugeriría ejecutar los agentes en tu propia computadora y dejar que trabajen juntos compartiendo archivos.

Estado actual: En este punto, la IA realiza un trabajo complejo con múltiples pasos sin que tú estés involucrado. El humano ya no es el cuello de botella.

¡Lo logramos! Ahora tenemos nuestro agente de IA autónomo para la respuesta a incidentes. Lo sé, parece más fácil en los diagramas que al construirlo, y la IA no siempre funciona como se espera.

Te comparto también algunas lecciones de la construcción de agentes de IA.

Suscríbete ahora

Lecciones aprendidas construyendo agentes de IA

He pasado mucho tiempo construyendo estos agentes y quiero compartir algunos consejos prácticos que te ahorrarán horas de frustración.

1. Asegúrate de tener suficientes ejemplos para construir un agente robusto. No querrías automatizar una tarea que no sea frecuente, por lo que lo más probable es que tengas varios casos para iterar. Le pedí a mi equipo que manejara todas las entradas de un servicio durante un mes. Estoy seguro de que tu gerente estará encantado de que asumas más trabajo.

2. Itera varias veces por paso. No pases al siguiente paso de la automatización hasta que hayas resuelto varios tickets o tareas diferentes para encontrar los patrones reales y los modos de fallo.

3. No cambies de pestaña mientras la IA trabaja. Observa al agente trabajar en vivo para detectar sus errores en lugar de dejarlo funcionar en segundo plano.

4. Usa tmux9 para bucles persistentes. Ejecuta tus agentes desde tu ordenador en una sesión de tmux para que sigan trabajando incluso si pierdes la conexión de la terminal.

5. Registra todo para la observabilidad. Dirige toda la salida del agente a un archivo de log dedicado para darte el mismo nivel de visibilidad cuando pases a ejecutarlo las 24 horas del día, los 7 días de la semana.

6. Refina los prompts basándote en las observaciones. Incluso después de considerar terminados los 10 pasos, aparecerán nuevos casos atípicos. Haz que la IA siga aprendiendo, ya sea actualizándola tú mismo o permitiendo que la IA actualice sus archivos de memoria entre iteraciones.

Suscríbete ahora

El papel del humano en un sistema de agentes de IA

Quiero dejar claro que no se trata de sistemas totalmente humanos o totalmente de IA. He centrado los ejemplos del agente de respuesta a incidentes en tareas de solo lectura como revisar alarmas, métricas y logs.

Cada uno de nosotros tiene que definir dónde y cuándo involucrar al humano para obtener el mayor beneficio. Puedes hacer que el agente clasifique el incidente y sugiera una solución, luego esperar tu aprobación y ejecución. Quizás alguien más quiera conectar la IA al código para crear un PR con la solución y esperar a que un humano la apruebe y despliegue el hotfix.

Sigo pensando que no queremos que la IA realice cambios en producción sin supervisión humana. He leído informes de fallos donde la IA realizó operaciones de producción no autorizadas en una cuenta de AWS sin ninguna revisión humana. Si pensamos en el proceso de respuesta a incidentes y en realizar un cambio de código, hay muchos pasos hasta que cambiamos algo en el sistema.

Mi postura actual sobre los agentes es empujar al humano hacia la derecha tanto como sea posible. Se trata de hacer que el humano trabaje menos, pero que siga supervisando. Esto es importante porque nadie pedirá cuentas ni responsabilidad a la IA. Se las pedirán a los humanos.

Resumen: Las piezas de los agentes de IA

• El cerebro (LLM): El modelo de lenguaje grande procesa información, toma decisiones y determina qué pasos seguir.

• Las manos (herramientas y MCP): Son las interfaces que permiten a la IA interactuar con el mundo real. Usando el MCP, un agente puede ejecutar código, consultar bases de datos o recuperar logs en lugar de simplemente “hablarte”.

• Las Skills (Skills del agente y SOP): Enseñan al modelo cómo realizar tareas. Esto es como un ingeniero junior siguiendo un runbook. Reduce errores y alucinaciones.

• La memoria (Contexto y Agents.md): Permite al agente recordar acciones pasadas. La memoria a corto plazo maneja la conversación actual. La memoria a largo plazo proporciona contexto histórico a través de archivos compartidos. Esto evita que el agente repita errores.

• El gerente (Orquestador): Usa un orquestador para gestionar múltiples agentes especializados a medida que escalas. Un agente puede encontrar el error, mientras que otro sugiere una solución, trabajando todos juntos hacia un resultado final.

• El despertador (Cron job): Permite que el agente se ejecute según un horario sin que tengas que iniciarlo manualmente.

• El espacio de trabajo (sistema de archivos local): Un área común donde los agentes leen y escriben. Esto les permite colaborar en problemas complejos.

  Suscríbete ahora

Conclusión: El futuro de los agentes de IA

A menudo se dice que la IA no te quitará el trabajo, pero alguien que use la IA sí lo hará. Realmente lo creo. Pero “usar la IA” no significa solo instalar una nueva extensión en tu IDE. He visto a mucha gente frustrarse cuando la IA no hace exactamente lo que quiere al primer intento, pensando que la IA es simplemente tonta.

Las personas que tienen éxito son las que construyen un ejército de agentes de IA para que hagan el trabajo pesado por ellas. Todas esas empresas de IA nos dan herramientas por defecto, pero nosotros somos quienes debemos adaptarlas a nuestras necesidades específicas.

Espero que esta guía te haya sido útil y que empieces a construir tus propios agentes hoy mismo.

Compartir

Preguntas frecuentes sobre agentes de IA

¿Qué puede hacer un agente de IA?

Un agente de IA puede ejecutar tareas de forma autónoma: leer logs, consultar APIs, escribir código, enviar notificaciones y coordinar con otros sistemas. A diferencia de un chatbot, no espera instrucciones para cada paso: actúa, evalúa el resultado y decide el siguiente movimiento.

¿Cuáles son los agentes de IA más utilizados?

Los frameworks más usados en 2025 son Claude Code, Cursor, y los agentes nativos de AWS Bedrock y Google Vertex AI. Para casos de uso propios, frameworks como LangGraph, CrewAI y Strands (Amazon) son populares para construir agentes multi-step con memoria.

¿Cómo los agentes de IA cambian el trabajo de un desarrollador?

El desarrollador pasa de ejecutar tareas repetitivas a diseñar los procesos que los agentes ejecutan. El trabajo se desplaza hacia la definición de SOP, la gestión de herramientas y la supervisión de resultados, en lugar de hacerlo todo manualmente.

¿Cómo empezar a construir un agente de IA?

El paso 1 es documentar el proceso que quieres automatizar como si fuera un runbook. El framework de 10 pasos de este artículo lleva desde ese runbook manual hasta una flota de agentes autónomos colaborando.

Suscríbete ahora

Algunos veían respuestas en tailandés, otros código roto. Muchos decían que ya no era el mismo. Otros, que seguía perfecto.

Nadie entendía por qué.

Ahí comenzó una investigación que llevó semanas. Y lo que encontraron fue inesperado: no era un bug, sino tres. Tres fallos independientes, solapados, que se reforzaban entre sí.

📌 Contexto rápido

Este post resume la arquitectura para servir peticiones de Claude, el LLM de Anthropic, y cómo tres errores técnicos solapados degradaron su calidad de respuesta durante semanas.

Al final encontrarás referencias técnicas y ejemplos reales. Y si te interesa construir sistemas de este nivel, cada semana comparto un nuevo caso con diagramas, decisiones reales y plantillas listas para aplicar.

Bug 1: Sticky routing

Claude tenía un sistema de enrutamiento “inteligente” con algunas decisiones arriesgadas:

• Separaba los servidores según el tamaño de contexto. Los que soportaban ventanas de 1M tokens estaban en un pool distinto a los normales.

• Usaba sticky routing. Una vez que tu conversación era atendida por un servidor, todas tus siguientes peticiones iban al mismo nodo.

• No detectaba desbalances en producción. Confiaba en pruebas previas, sin monitoreo continuo de calidad.

Un cambio en el load balancer hizo que algunas requests normales terminaran ahí por error.

Ese desvío afectaba la calidad. Los servidores de contexto largo estaban optimizados para otra cosa, y las respuestas se volvían incoherentes. Como había sticky routing, los usuarios quedaban atascados en ese pool.

En su pico, el 16% del tráfico iba al lugar equivocado.

Bug 2: Tokens corruptos en plena inferencia

Una mala configuración en los servidores TPU provocó que Claude generara tokens con probabilidades erráticas. Aparecían caracteres tailandeses en prompts en inglés, o código con errores obvios de sintaxis.

No era aleatorio: una optimización de performance hizo que algunos tokens improbables se colaran con puntuaciones altas. Eso rompía la coherencia.

El bug afectó a Opus y Sonnet durante una semana. No se desplegó en Bedrock ni Vertex AI.

Bug 3: Sampling roto por compilación

Claude usaba “approximate top-k” para generar tokens rápido en TPU. Pero al refactorizar ese módulo, apareció un bug en el compilador XLA:TPU que rompía la precisión.

En lugar de devolver los tokens más probables, a veces omitía el mejor. Y no siempre era reproducible. El error dependía del batch size o del orden interno de las operaciones.

El fix fue claro: abandonar el approximate top-k y volver al exacto. Menos rápido, pero mucho más confiable.

Claude usa una arquitectura monolítica con multihardware

Claude funciona como una capa unificada que orquesta múltiples clusters y plataformas de hardware. Piensa en ello como un McDonalds, tiene restaurantes en muchos países distintos, pero todos deben preparar el mismo plato con el mismo sabor.

Cada petición se enruta según la disponibilidad y el tipo de contexto, pero el objetivo es que el usuario nunca sepa si se usó GPU, TPU o Trainium. Esa equivalencia es clave, pero también introduce mucha complejidad.

Desglose de componentes clave

1. Enrutador de contexto

• ¿Para qué sirve? Decide a qué servidor enviar cada solicitud, según el tipo de modelo y el tamaño del contexto.

• Cómo funciona

  1. Detecta si la petición requiere soporte para 1M tokens.

  2. Selecciona el pool de servidores correspondiente

  3. Aplica afinidad de sesión para mantener coherencia.

• Tecnologías clave: load balancer interno, sticky routing, headers HTTP para flags de contexto.

2. Clusters de inferencia

• ¿Para qué sirve? Ejecutan el modelo Claude sobre el hardware disponible.

• Cómo funciona

  1. El modelo se divide entre múltiples chips (TPU o GPU).

  2. Cada chip procesa una parte del cálculo.

  3. Los resultados se agrupan para formar la respuesta final.

• Tecnologías clave: TPUs de Google, GPUs NVIDIA, AWS Trainium, XLA compiler, distribución tensorial.

3. Algoritmo de sampling

• ¿Para qué sirve? Determina qué token generar en cada paso.

• Cómo funciona

  1. Calcula probabilidades para miles de tokens.

  2. Usa top-k o top-p sampling para filtrar candidatos.

  3. Selecciona aleatoriamente uno dentro de los mejores.

• Tecnologías clave: approximate top-k (ahora reemplazado), precisión bf16/fp32, xla_allow_excess_precision.

4. Evaluador de calidad

• ¿Para qué sirve? Detecta degradaciones en las respuestas del modelo.

• Cómo funciona

  1. Corre pruebas automatizadas con prompts conocidos.

  2. Compara salidas actuales con versiones anteriores.

  3. Genera alertas si hay cambios estadísticamente significativos.

• Tecnologías clave: eval harness interno, benchmarks sintéticos, métricas de coherencia y diversidad.

5. Plataforma de terceros

• ¿Para qué sirve? Expone Claude como servicio a través de AWS Bedrock y Google Vertex AI.

• Cómo funciona

  1. Traduce llamadas de terceros al API de Anthropic.

  2. Usa pools de hardware diferenciados.

  3. Puede operar con versiones específicas o rezagadas del modelo.

• Tecnologías clave: integración multi-cloud, API gateway, sincronización de versiones.

En resumen: lo que pasó

• Tres bugs independientes degradaron Claude al mismo tiempo.

• Uno era de ruteo de contexto, otro de configuración en TPUs, y otro en el compilador XLA.

• La combinación hacía que algunos usuarios vieran degradaciones graves, mientras otros no.

• Los errores persistieron semanas porque las evaluaciones internas no los detectaban.

• Claude opera sobre infraestructura heterogénea con alto riesgo de inconsistencia si no se valida cada cambio.

• Se abandonaron optimizaciones arriesgadas (como approximate top-k) para garantizar calidad.

• Ahora hacen evaluaciones continuas en producción, no solo antes del deploy.

• Se reforzó la colaboración con usuarios para detectar errores más rápido.

¿Y cómo pueden mejorar esta arquitectura para introducir cambios más rápido y con más confianza?

Una arquitectura robusta no basta si los errores pasan desapercibidos. Anthropic aprendió por las malas que no basta con hacer canary deployments o medir throughput.

Para detectar degradaciones reales, necesitas:

• Métricas centradas en la experiencia del usuario. No solo latencia o éxito HTTP, sino indicadores de calidad de respuesta por tipo de prompt y modelo.

• Alarms sensibles y específicas. Que detecten cambios sutiles en output quality, character entropy o fallas sintácticas, no solo caídas completas. Sobre todo, cuando introduzcas un nuevo A/B test, quieres segmentar la métrica para ver si la nueva experiencia la degrada

• Feedback reproducible. Claude tenía limitaciones por privacidad, pero sin trazabilidad, es casi imposible aislar el bug. Deben permitir que usuarios hagan opt-in a compartir información de diagnóstico, que los usuarios puedan elegir compartir un chat no-anonimizado para bug report.

• Capacidad de inspeccionar degradaciones por cohortes. Qué porcentaje de usuarios están viendo respuestas rotas, y si vienen del mismo pool o hardware. No tenían trazabilidad en una arquitectura muy heterogénea y con muchos componentes

• Test de regresión en tiempo real. Prompts fijos y prompts nuevos comparados contra versiones previas del modelo, con validación automática. Que corran contra cada nuevo cambio y que sean canary tests que corran en producción todo el rato para detectar degradaciones.

Detectar errores como estos no depende solo del código. Depende de cómo midas lo que entrega tu sistema en producción. Calidad percibida, no solo uptime.

📬 ¿Te gustaría diseñar infra como esta?

👋 PS – ¿Quieres dominar el system design?

Suscríbete para recibir cada semana un caso real de arquitectura explicado con diagramas, decisiones técnicas y checklists listos para aplicar. Ya somos más de 20,000 ingenieros aprendiendo juntos.

📚 Referencias

1. A postmortem of three recent issues – Anthropic

2. InfoQ – Anthropic Reveals Three Infrastructure Bugs

3. GitHub Claude Code – Output Corruption Issue #7793

4. Documentation – 1M Token Context Window

📝 Otros artículos de interés

Las imágenes más fancy son generadas con IA, las que se vean feas son las que he generado yo :)

Lo escriben como si fueran las notas de investigación. Eso sirve para actualizar un ticket, pero es una oportunidad perdida para un documento de alta visibilidad.

Un postmortem no es solo un informe técnico. Es tu oportunidad para demostrar profundidad técnica, pensamiento en sistemas, comunicación de liderazgo, priorización y visión a futuro para tus sistemas.

Por eso las mejores empresas incluso publican sus postmortems externamente. Porque tiene valor y les da visibilidad positiva.

En este post vas a aprender

• Cómo convertir incidentes en prueba de liderazgo.

• Cómo escribir postmortems que hacen que otros te noten.

• Una checklist para tu próximo postmortem para suscriptores premium.

Convierte una crisis en capital profesional

Los incidentes fuerzan visibilidad. Todos observan quién aparece y cómo actúa. Ese es el momento de liderar.

Cuando me ofrecí voluntariamente a escribir un postmortem de un incidente sin dueño claro, tomé control de una situación que podía dañar mi reputación. Entendí la root cause y sabía que podía cerrarlo. Esa acción me convirtió en la cara de la resolución. La percepción importa. Ser voluntario cambió la historia de “quién causó esto” a “quién lo arregló”.

Ya lo había hecho antes. Usé el postmortem como herramienta para moldear cómo liderazgo interpretaba el evento. En mi one-on-one con mi manager no hubo culpa. Tomé acción pronto, di actualizaciones constantes y gestioné la narrativa. Si me hubiera quedado en silencio, el ambiente habría sido de culpa y falta de ownership. Cuando la reputación se daña, demostrar inocencia más tarde ya no importa.

Incluso cuando algunos incidentes solo afectaban a usuarios internos, los traté como problemas de producción. Actualizaciones cada 15 minutos, pasos claros, mentalidad de mitigación primero y un postmortem pequeño para cerrarlos. Esa debería ser la base. Así señalas estándares de senior.

El documento como artefacto de promoción

Muchos ingenieros piensan que el postmortem es papeleo. Yo lo trato como uno de mis artefactos más fuertes. Es visible, duradero y toca todas las señales que liderazgo senior busca.

Estas son las secciones que debe incluir.

Resumen

Va arriba, pero lo escribo al final.

Es un brief de alto nivel para directores y VPs. Lo uso para demostrar entendimiento del contexto de negocio, impacto al cliente y remediación a largo plazo. Lo trato como si fuera un email para mi director.

Gráficos y métricas

Los gráficos deben contar una historia, no solo mostrar números. El primero siempre muestra impacto al cliente, no métricas internas del servicio. Eso marca el tono. Luego anoto deployments, rollbacks y anomalías. También incluyo los gráficos que me habría gustado tener. Eso ayuda a justificar trabajo futuro de observabilidad.

Hice esto en un incidente de alta severidad. Como había debuggeado el mismo servicio días antes, fui rápido leyendo métricas y presentando la señal limpia. Esa habilidad vino de práctica y de tener un proceso repetible.

Impacto al cliente

Muchos ingenieros escriben “2% error rate, 300ms latency increase” y creen que eso es impacto al cliente. Son datos internos. No dicen qué experimentó el usuario.

Siempre pregunto: ¿Vieron flujos rotos? ¿Timeouts? ¿Pagos fallidos? ¿Subieron los tickets de atención al cliente? ¿Bajó el revenue? Si no respondes eso, tu postmortem está incompleto.

Diagnóstico

Aquí demuestras que no estás adivinando. Muestras tu razonamiento. Empiezas con la hipótesis inicial, la evidencia que la confirmó o rechazó y cómo pivotaste.

Una vez seguí un problema de permisos supuestamente parcheado una semana antes, pero nunca entendido, y volvió a ocurrir. Otros pararon en “fix deployed”. Yo fui más profundo. Esta parte demuestra que no solo cierras tickets, sino que resuelves problemas.

Timeline del incidente

El timeline no es una lista de timestamps. Es la historia de cómo reaccionamos bajo presión. Empiezo con qué cambió que llevó al incidente. Incluyo cada retraso y cada fallo. Si esperamos 20 minutos antes de involucrar a alguien, lo dejo claro y explico por qué (“el runbook no era claro, triage retrasado”). No es un fallo. Es una oportunidad de mejora.

Debemos mostrar cuidado por el proceso, no culpa. Señala pensamiento en sistemas, no en individuos.

5-Why

El 5-Why lo creó Toyota para problemas en la fabricación de coches y se popularizó. Empiezas desde el impacto al cliente y sigues preguntando “por qué” hasta llegar a una root cause sistémica. No estás limitado a 5 veces.

- ¿Por qué 1234 clientes perdieron sus pedidos?

Porque el backend devolvió “200 OK” sin persistir en base de datos.

- ¿Por qué devolvió “200 OK sin persistir”?

Porque…

Si paras en error humano, pareces inexperto. Ve más lejos y muestra dónde falló el sistema al protegerse.

Cuando reviso un postmortem, busco esto. ¿Por qué ningún test lo detectó? ¿Por qué la alarma era confusa? ¿Por qué no se siguió el runbook?

Otro anti-patrón es meter todo el incidente en un único árbol de 5-Why. Prefiero múltiples cadenas:

• Root cause técnica

• Prevención

• Detección

• Diagnóstico

• Mitigación

No las necesitas siempre, pero si un incidente dura días, debes analizar los mecanismos de detección.

Follow-ups

Aquí fallan la mayoría. No escribo cosas tipo “mejorar el monitoreo”. Escribo: “Añadir alarma cuando checkout P99 supere 200ms durante 5 minutos. Owner: <persona>. Due: <fecha>”. Claro y con responsables

En un postmortem que presenté a toda la organización, aseguré que los action items fueran precisos y concisos. Sin relleno. Así otros vieron que no nos faltaba nada en esos siguientes pasos.

Los action items no son solo técnicos. Si alguien me ayudó durante el incidente, le doy crédito y etiqueto a su manager. Uso el reconocimiento como herramienta de influencia. Funciona mejor que culpabilizar. También elogio a quienes defienden el valor de escribir postmortems, incluso si otros se resisten.

El proceso del postmortem no es un informe técnico. Es un mecanismo de liderazgo.

Conclusión

Los suscriptores premium tienen la plantilla en los recursos premium. Aquí un adelanto:

Tu manager no ve la mayoría de tu trabajo diario. Pero sí leerá tu postmortem. También el manager de tu manager. También arquitectos y tech leads que influyen en promociones.

La mayoría escribe postmortems para pasar página. Tú deberías escribirlos para subir de nivel.

Un buen postmortem muestra habilidad técnica, pensamiento en sistemas, comunicación, ownership e influencia. No necesitas un proyecto nuevo para demostrar que estás listo para más responsabilidad. Solo necesitas escribir como si ya la tuvieras.

Aquí tienes el enlace a la plantilla, como prometí.

📝 Otros artículos de interés

El verdadero cuello de botella en el rendimiento de las empresas no es la inteligencia del modelo, sino la calidad del contexto que le das. El avance viene de la ingeniería de contexto: diseñar todo el ecosistema de información para tu IA e integrarlo en tus flujos de trabajo. Deja de esperar una IA más inteligente y comienza a construir los sistemas que te den un salto profesional de 10x hoy.

Las empresas recompensan multiplicadores de fuerza, no codificadores individuales. La ingeniería de contexto te permite automatizar trabajo cognitivo repetitivo, reducir fricciones en las revisiones y asumir resultados que muevan el negocio hacia adelante.

⭐ En este post aprenderás

• Por qué la ingeniería de contexto es una habilidad de alto impacto

• Las técnicas que hacen que la IA produzca resultados más rápidos y precisos

• Cómo aplicar la ingeniería de contexto en flujos de trabajo reales de ingeniería

• Cómo convertir los resultados de la ingeniería de contexto en evidencia para promociones

Por qué la ingeniería de contexto es la habilidad en la que enfocarte en tu empresa

Incluso el mejor LLM no tiene conocimiento de la arquitectura de tu empresa, reglas de negocio o cultura de equipo. No conoce tus microservicios, tus estándares de codificación ni el contexto histórico de un hilo de Slack de hace seis meses. Sin esto, su output será genérico y erróneo de formas sutiles.

Imagina esto: llevas tres años en tu empresa y ahora llega un nuevo empleado con mayor IQ. Superarás a este nuevo empleado en su primer día. Entregas más rápido porque conoces los flujos de aprobación y las dependencias ocultas. Previenes regresiones porque recuerdas incidentes pasados y casos límite. Reduces tiempos de ciclo porque sabes exactamente dónde obtener respuestas sin esperar. Navegas dependencias entre equipos porque sabes a quién involucrar y cuándo.

No creas impacto en tu equipo porque eres el ingeniero más inteligente. Creas impacto porque entiendes el dominio del negocio.

Lo mismo aplica para la IA. Un modelo sin contexto es como un nuevo empleado sin onboarding. Dale el mismo entorno en el que operas y se convierte en una extensión de alta velocidad de tu cerebro. Esa es la esencia de la ingeniería de contexto: darle a la IA la misma ventaja interna que tú tienes.

Técnicas de ingeniería de contexto

La ingeniería de contexto no es “solo mejorar los prompts”. Es usar un conjunto de técnicas repetibles para darle a la IA la información correcta, en la estructura correcta, en el momento correcto.

1. Instrucciones del sistema: roles y personas

   Define un rol o persona claro para el modelo antes de que responda. Por ejemplo: “Eres un arquitecto de software principal explicando sistemas orientados a eventos a un ingeniero de nivel medio”. Esto moldea el tono, detalle y perspectiva de la respuesta.

2. Retrieval Augmented Generation (RAG)

   Combina el modelo con fuentes de conocimiento externas que pongas en una base de datos vectorial. Recupera documentos relevantes y dáselos al prompt para que las respuestas sean precisas y actuales.

3. Patrones de memoria a corto y largo plazo

   Usa diferentes alcances de memoria intencionalmente. La memoria a corto plazo es el contexto de la conversación actual. La memoria a largo plazo retiene hechos y preferencias con el tiempo para personalización.

4. Web Search Grounding

   Mejora respuestas con resultados de búsqueda en tiempo real. Pide al modelo buscar información reciente y fundamentar su razonamiento en esos datos.

5. Prompting

   Explora múltiples técnicas de prompting para controlar el output del modelo:

   • Basado en restricciones y prompts negativos

   • Capas de prompts y prompts perezosos

   • Pipelines de prompts y encadenamiento

   • Zero-shot y few-shot prompting

6. Herramientas MCP

   Extiende capacidades del modelo con herramientas externas, APIs o plugins.

7. Razonamiento: chain of thought, tree of thought, decomposition

   Guía al modelo a razonar paso a paso.

8. Orquestación de flujos de trabajo

   Coordina múltiples agentes o herramientas de IA en secuencia.

9. Contexto de input/output

   Define claramente cómo se estructura el input y cómo debe formatearse el output.

Ejemplo práctico

Manera antigua:

Abrir todos los archivos de un PR, cruzar con backlog y documentos de diseño, confiar en la memoria para estándares de codificación, luego pasar 45 minutos escribiendo comentarios. Cada paso depende de tu habilidad de manejar contexto mentalmente.

Manera nueva (MVP):

Agrego todo el contexto en minutos. Uso un script de Greasemonkey para copiar todos los archivos del PR, descripciones de tickets y documentos relevantes. Esto es un paso de “RAG manual” que tarda menos de dos minutos.

Luego cargo mi prompt: incluye rol (“Staff Engineer”), estándares de codificación, formato de output esperado e instrucciones de razonamiento. Incluyo ejemplos de comentarios de calidad y estándares de codificación inline. También verifico bibliotecas externas contra datos de vulnerabilidad. Este prompt vive en mi biblioteca de prompts, que es mi memoria a largo plazo para revisiones de código.

La IA entrega la revisión en una tabla Markdown. Yo filtro los comentarios de bajo valor, mantengo los de alto valor y agrego los míos. La revisión es más rápida, consistente y deja un historial reutilizable.

Convertir victorias de ingeniería de contexto en evidencia para promociones

Los managers no se preocupan por “usé IA”. Les importa el impacto medible: mayor velocidad, menor riesgo y menos bloqueos entre equipos. Convierte la ingeniería de contexto en prueba.

• Recopila métricas antes y después

• Guarda enlaces a tu biblioteca de prompts

• Videos demo de scripts

• Entradas de logs mostrando minutos ahorrados

Construye tu documento de promoción como un caso de estudio: problema, enfoque, resultado medible, artefactos y validaciones de stakeholders.

Escala tu influencia: publica tu vault de contexto internamente, realiza workshops, crea plantillas reutilizables. Añade estos logros a tu evidencia de promoción.

🎯 Conclusión

Elige una tarea aburrida, repetitiva o ambigua esta semana. Diseña un pipeline de contexto, entrega una automatización mínima viable, mide los minutos ahorrados, agrega al log de decisiones y lleva los resultados a tu próximo 1:1.

Si no sabes cómo hacerlo, revisa las secciones 2 y 3 del artículo. Solo necesitas un MVP, como el ejemplo de revisiones de código.

Entrega la automatización, muestra la diferencia y pide más responsabilidad en tu próxima evaluación de desempeño.

📝 Otros artículos de interés

Ya estás usando IA para escribir código más rápido, pero ¿te está convirtiendo en un mejor ingeniero? La diferencia entre un desarrollador de nivel medio y uno senior estará más en cómo usan la IA para construir software robusto y mantenible.

Confiar solo en el “vibe coding” básico (Prompt Engineering) es rápido para tareas pequeñas, pero se encuentra con un límite en proyectos complejos. Nuevos IDEs como Kiro de Amazon están adoptando lo que se llama Desarrollo Guiado por Especificaciones (Spec-Driven Development).

Los ingenieros más exitosos se están volviendo “bilingües”, usando ambos enfoques. Saber cuándo usar cada uno es el nuevo superpoder para crecer en tu carrera.

En este post aprenderás:

• La diferencia entre Prompt Engineering y Desarrollo Guiado por Especificaciones

• Cuándo usar cada enfoque

• Cómo estructurar tus prompts para obtener mejores resultados

• Herramientas que soportan cada flujo de trabajo y cómo elegirlas

Prompt Engineering

Algunas personas llaman a esto vibe coding. No estoy de acuerdo. Vibe coding es cuando confías ciegamente en la IA y haces git push --force sin revisar. Eso no es lo que hacemos aquí. Al menos no todo el tiempo 😛

Prompt Engineering es conversacional. No estás planeando una solución perfecta. Haces una solicitud acotada y iteras según el resultado. Usas comandos inline como “refactoriza esto” o “agrega verificación de valores nulos”, y la IA edita directamente en tu código.

He visto que este enfoque funciona mejor cuando mantienes un prompt bien definido. Algunas personas simplemente escriben “agrega tests” y esperan magia. He comprobado que invertir tiempo extra en crear el prompt correcto da frutos, especialmente para flujos repetitivos como revisiones o generación de tests unitarios.

Es como encontrar un bug en una revisión de código versus encontrarlo en producción. Cuanto más tarde tienes que cambiar el enfoque, más costoso es.

PDD es rápido, pero frágil. Para tareas acotadas, es excelente. Creo que veremos cada vez más cómo los pequeños comentarios en revisiones de código son atendidos por la IA antes de hacer push, sacando al humano del ciclo. Avanzas rápido, pero la lógica detrás de tus decisiones queda en la ventana de chat del IDE, en lugar de compartirse con tu equipo.

Desarrollo Guiado por Especificaciones (Spec-Driven Development)

Spec-driven development invierte el proceso. En lugar de pedir código, pides un plan.

Le pides a la IA que escriba una especificación: historias de usuario, criterios de aceptación, diseño de alto nivel y lista de tareas. Luego la revisas. Solo cuando estás satisfecho con el plan le pides generar la implementación real.

Básicamente, es lo que hacen los equipos de software: no escribes código antes de alinearte con tu equipo y las dependencias de la arquitectura de tu sistema y las interfaces expuestas.

Este modelo me convenció después de leer sobre usar Cursor en modo “Ask” para generar un plan y modo “Agent” para ejecutarlo. Él estaba simulando flujos de trabajo guiados por especificación dentro de un editor prompt-first. Ese truco funcionó. Ahora herramientas como Kiro de Amazon tienen soporte integrado para modo especificación con documentación y artefactos versionados. Ya no es solo una “buena práctica”, es una función del IDE.

El futuro de este enfoque trata las especificaciones como código, versionadas junto al código fuente para completa auditabilidad. También permite enlaces de trazabilidad entre tareas, commits y tests.

Dicho esto, el desarrollo guiado por especificaciones no es gratuito. Escribir una especificación para cambiar el color de un botón es un overhead. Solo lo uso cuando sé que el costo de que la IA genere mucho código incorrecto es alto. Para un nuevo servicio o algo que permanecerá años, SDD vale la inversión inicial.

¿Cómo elegir?

No necesitamos elegir un solo lado. Usaremos ambos según la situación.

Si estoy corrigiendo un bug o ajustando una función, uso prompt-first. Es rápido y suficiente. Si estoy diseñando una nueva funcionalidad o escribiendo algo de lo que otros dependerán, uso spec-first. Así evito retrabajo y confusión.

Actualmente, los LLMs empiezan a seleccionar el enfoque automáticamente. GPT-5 recién lanzado elige entre una sugerencia directa o iniciar su proceso de razonamiento. La capa de decisión se mueve del usuario a la herramienta, y espero que los IDEs implementen esto pronto.

Por ahora, debemos elegir, así lo pienso:

• Usa Prompt Engineering cuando la tarea es pequeña, individual o incierta. Estás explorando, no comprometiéndote.

• Usa Desarrollo Guiado por Especificaciones cuando la tarea es grande, colaborativa o crítica. Necesitas alineamiento, no velocidad.

Nada ha cambiado respecto a los viejos días de ingeniería sin IA. No escribirías un documento para cambiar el color de un botón, pero sí para alinear con tu equipo y las dependencias cómo y qué formato debería tener la información en un payload de evento o API.

IDEs para cada paradigma

El ecosistema se divide en dos: herramientas prompt-first para iteración rápida y spec-first para desarrollo estructurado. Cada una tiene su lugar. Yo uso ambas a diario.

Prompt Engineering IDEs

• Cursor: En modo Agent, emito comandos como “refactoriza a async” o “agrega retry logic” y gestiona ediciones aisladas rápido.

• Amazon Kiro (Vibe Mode): Te permite saltar la fase de planificación y prompt libre. Lo uso cuando quiero velocidad sin estructura.

• GitHub Copilot Chat: Ideal para preguntas rápidas y stubs de código.

• Replit Ghostwriter: Útil para prototipos rápidos en navegador.

• Claude Code: Buena ventana de contexto.

• Windsurf: Buena memoria.

Spec-driven IDEs

• Amazon Kiro (Spec Mode): Es la opción completa. Escribe requirements.md, design.md y tasks.json, y los commitea al repo. Cuando la estructura importa, voy aquí.

• Cursor (Ask + Agent): Puedes simular SDD generando un plan en Ask y ejecutando en Agent. Pero no obtienes artefactos versionados a menos que los guardes manualmente.

  

• Otros: Con disciplina, puedes simular SDD con prompts manuales, pero es todo manual.

🎯 Conclusión

Tenemos un tradeoff: agilidad vs estructura.

• Prompt Engineering es rápido, flexible y genial para tareas individuales o exploratorias.

• Desarrollo guiado por especificaciones es estructurado, claro y excelente para escalar trabajo en equipos.

Los ingenieros que crecen más rápido son los que saben alternar entre ambos.

Prueba ambos en tu próxima funcionalidad. Escribe una mini-especificación. Luego prueba algunos bucles de prompts. Observa cuál se siente más rápido, limpio y mantenible. Tu próximo ascenso podría depender de tu adaptación a este cambio.

¡Hasta la próxima!

📝 Otros artículos de interés

El mundo del software no para de moverse. Lo que ayer era innovador, hoy es el estándar, y lo que hoy es experimental, mañana podría ser la clave de nuestro próximo proyecto.

Estar al día no es solo postureo; es fundamental para tomar buenas decisiones técnicas, construir sistemas robustos y, por qué no, ¡mantener la llama encendida por aprender!

Este mundillo puede ser abrumador, lo sé. Por eso, he destilado las tendencias del 2024, con la vista puesta ya en 2025, y te lo presento de una forma clara y directa.

⭐ ¿Cómo leer este resumen?

He organizado las tendencias siguiendo su ciclo de vida, como si fueran Pokémon evolucionando:

1. Emergentes: Las ideas más frescas, las que están en fase "Early Adopter" inicial según el informe InfoQ. ¡Presta atención para el futuro!

2. Sólidas: Tecnologías probadas ("Early Adopter" avanzado o "Early Majority" inicial según InfoQ). Recomendadas para la mayoría de nuevos proyectos. Son apuestas seguras con recorrido.

3. Ampliamente Adoptadas: Los estándares de facto ("Early/Late Majority" según InfoQ). Lo que ya deberías estar usando o, al menos, conocer bien.

🧪 Tecnologías Emergentes (El Futuro ya está Aquí: 2025 y más allá)

Estas son las tendencias que están empezando a hacer ruido. Aún no son mainstream, pero tienen potencial para cambiar las reglas del juego. Presta atención:

1. Arquitecturas Basadas en Celdas (Cell-based Architectures):

   

   • Qué es: Piensa en compartimentos estancos en un barco, como el patrón "Bulkhead", pero aplicado al sistema entero. Se trata de diseñar sistemas distribuidos donde los servicios se agrupan en "celdas" auto-contenidas (a menudo coincidiendo con zonas de disponibilidad (availability) o AZs). Cada celda opera de forma independiente con sus propios recursos. La comunicación dentro de la celda es preferente y la comunicación entre celdas se limita y controla mediante routers o gateways.

   • Por qué importa: Mejora drásticamente la disponibilidad y resiliencia al aislar fallos (un fallo en una celda no tumba todo el sistema, reduciendo el "blast radius"). Facilita la escalabilidad (se escala añadiendo más celdas) y puede optimizar costes. Empresas como Roblox, Slack, y DoorDash ya lo usan con éxito reportado.

2. Ingeniería de Privacidad (Privacy Engineering):

   • Qué es: Es la disciplina de integrar la privacidad en el diseño y operación de sistemas y productos desde el inicio ("Privacy by Design"). Va más allá de cumplir reactivamente con GDPR o CCPA; es un cambio de mentalidad proactivo.

   • Por qué importa: La confianza del usuario es clave. Técnicas como la minimización de datos (recoger solo lo necesario), la anonimización, o la ofuscación activa de datos (como DoorDash eliminando direcciones tras la entrega, según el informe InfoQ) son fundamentales. No es solo seguridad, es respeto y protección proactiva de los derechos del usuario.

3. Software Verde (Green Software):

   • Qué es: Considerar la huella de carbono y el impacto ambiental como un atributo de calidad más del software, desde la fase de diseño. No se trata solo de ahorrar en la factura de la nube, sino de ser conscientes del consumo energético y buscar la eficiencia.

   • Por qué importa: La sostenibilidad es una responsabilidad creciente en la industria tecnológica. Optimizar algoritmos, elegir infraestructuras eficientes o basadas en energías renovables, y diseñar para reducir el consumo son prácticas clave. InfoQ lo sitúa como "Innovador", indicando que, aunque se habla de ello, la adopción generalizada de prácticas concretas desde el diseño inicial aún está emergiendo.

4. Modelos de Lenguaje Grandes y Pequeños (LLMs y SLMs):

   

   • Qué es: Los LLMs (como GPT-4, LLaMA) son modelos de IA entrenados con enormes cantidades de datos. Los SLMs (Small Language Models) como Phi-3 son versiones más compactas, entrenadas con menos datos pero a menudo de alta calidad, diseñadas para ser más eficientes en recursos.

   • Por qué importa: Los LLMs/SLMs son herramientas potentes para desarrolladores (generación de código, análisis) y para integrar en aplicaciones. Los SLMs son más rápidos, económicos y adecuados para tareas específicas o para ejecutarse en dispositivos con recursos limitados (Edge AI), mejorando también la privacidad al procesar datos localmente. La Generación Aumentada por Recuperación (RAG) es una técnica clave para mejorar ambos, permitiéndoles usar información externa y actualizada.

5. Hardware con IA Integrada y Edge AI:

   • Qué es: Desde GPUs optimizadas para IA (NVIDIA) hasta PCs y móviles con chips específicos para IA (como Apple M4, mencionado en InfoQ), el hardware se está adaptando. Esto impulsa el Edge AI, llevando la inteligencia artificial directamente a los dispositivos finales.

   • Por qué importa: Permite ejecutar modelos (especialmente SLMs) localmente, reduciendo latencia, mejorando la privacidad y habilitando nuevas aplicaciones en tiempo real en móviles, coches, IoT, etc..

🧱 Tecnologías Sólidas (Probadas y Recomendadas para Nuevos Proyectos)

Estas tecnologías ya han demostrado su valor. Si empiezas un proyecto nuevo, deberían estar en tu radar.

1. Arquitectura Socio-Técnica:

   • Qué es: Reconocer que el diseño de sistemas debe considerar tanto los aspectos técnicos como los humanos y organizacionales. Se basa en la Ley de Conway (la arquitectura refleja la estructura de comunicación) y conceptos del libro de Team Topologies.

   • Por qué importa: Alinear la arquitectura con la organización reduce fricciones, mejora el flujo de entrega y la mantenibilidad. Ignorar estos factores es una receta común para el fracaso de proyectos complejos.

2. Ingeniería de Plataforma (Platform Engineering):

   • Qué es: Construir y gestionar plataformas internas (IDPs - Internal Developer Platforms) que proporcionan capacidades de autoservicio a los desarrolladores, abstraen la complejidad de la infraestructura y ofrecen un camino para construir y desplegar aplicaciones. Tratar la plataforma como un producto interno es clave.

   • Por qué importa: Mejora drásticamente la experiencia del desarrollador (DevEx), reduce la carga cognitiva, acelera la entrega de valor y estandariza buenas prácticas.

3. Computación en el Borde (Edge Computing)

   

   • Qué es: Procesar datos más cerca de donde se generan o consumen, en lugar de enviarlos siempre a un datacenter centralizado.

   • Por qué importa: Reduce la latencia, ahorra ancho de banda (y costes), mejora la seguridad (al procesar datos sensibles localmente) y aumenta la resiliencia. Se integra naturalmente con IoT y Edge AI.

4. Arquitectura Orientada a Datos (Data-Driven Architecture):

   • Qué es: Integrar plataformas analíticas y modelos de Machine Learning (ML) como componentes centrales y de primera clase en sistemas transaccionales, influyendo en su comportamiento en tiempo (casi) real.

   • Por qué importa: Permite sistemas más inteligentes y adaptativos. Exige que estos componentes analíticos cumplan los mismos requisitos de resiliencia, rendimiento y observabilidad que el resto del sistema. MLOps es la disciplina que aplica principios DevOps al ciclo de vida de los modelos ML.

5. RAG - Retrieval Augmented Generation (Generación Aumentada por Recuperación):

   

   • Qué es: Una técnica para mejorar los LLMs proporcionándoles información relevante de una base de conocimiento externa (documentos, bases de datos) antes de generar una respuesta.

   • Por qué importa: Permite a los LLMs usar datos actualizados, específicos del dominio o privados sin necesidad de reentrenamiento costoso. Reduce las "alucinaciones" y permite citar fuentes, aumentando la confianza.

6. Arranque Rápido de JVM (CRaC / GraalVM Native Image):

   • Qué es: Tecnologías para acelerar el inicio de aplicaciones Java. CRaC (Coordinated Restore at Checkpoint) permite guardar el estado de la JVM en un punto y restaurarlo rápidamente. GraalVM Native Image compila el código Java a un ejecutable nativo.

   • Por qué importa: Hacen a Java mucho más competitivo en escenarios serverless y de microservicios donde los tiempos de arranque cortos son cruciales. Frameworks como Spring, Quarkus y Micronaut ya soportan estas tecnologías.

📔 Ampliamente Adoptadas (Estándares por Defecto)

La base de la mayoría de sistemas modernos.

1. Microservicios: Siguen siendo dominantes para sistemas complejos, aunque evolucionan hacia patrones como las celdas para gestionar mejor la distribución.

2. Cloud Computing (IaaS, PaaS, SaaS): El estándar de facto para infraestructura y servicios (AWS, Azure, GCP, etc.).

3. DevOps y CI/CD: Cultura y prácticas indispensables para la entrega de software moderna.

4. Contenedores y Orquestación (Docker, Kubernetes): Estándar para empaquetar, desplegar y gestionar aplicaciones.

5. Diseño API-First: Diseñar APIs como contratos primarios antes de la implementación.

6. Low-Code / No-Code: Plataformas establecidas para acelerar el desarrollo en ciertos casos de uso.

🎯 Conclusión y Recomendaciones: ¿Cuándo Subirse al Tren de las Novedades?

¿Cómo decidir qué adoptar y cuándo?

• No todo lo nuevo es para ti (aún): Adopta tecnologías emergentes si resuelven un problema crítico que las maduras no pueden, o para obtener una ventaja estratégica (y puedes asumir el riesgo).

• Refuerza tus cimientos: Domina las tecnologías sólidas y ampliamente adoptadas. Son tu base.

• Evalúa Madurez vs. Valor vs. Equipo:

  • Madurez: ¿Está probada? ¿Hay soporte? [Consulta informes como el de InfoQ]

  • Valor: ¿Qué problema real resuelve? ¿Beneficio > Coste/Riesgo?

  • Ajuste al Equipo: ¿Tenemos habilidades? ¿Encaja en nuestra cultura/procesos?

Un cuadro de decisión, como el que tienen disponible los suscriptores premium aquí, puede ayudar a visualizar si la adopción tiene sentido ahora

👋 PS – ¿Quieres dominar el diseño de sistemas y la arquitectura de software?

¡Espero que este análisis te haya útil! Si tienes alguna pregunta o quieres comentar alguna tendencia, responde a este correo o deja un comentario en la versión web.

¡Hasta la próxima!

🗞️ Referencias

Aquí tienes algunos artículos si quieres profundizar:

• The InfoQ Trends Reports 2024 (eMag #116, January 2025): Fuente principal de este análisis.

• InfoQ Topics: Explora temas como Cell-Based Architecture, Platform Engineering, Green Software.

• Libros Clave: "Team Topologies" de Matthew Skelton y Manuel Pais; "Building Evolutionary Architectures" de Neal Ford, Rebecca Parsons y Patrick Kua.

• https://dzone.com/articles/grokking-cell-based-architecture

• https://maddevs.io/glossary/cell-based-architecture/

• https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html

• https://ethyca.com/privacy-engineering-all-you-need-to-know

• https://es.innovatiana.com/post/intro-to-small-language-models

• https://aws.amazon.com/what-is/retrieval-augmented-generation/

📝 Otros artículos de interés

• La arquitectura de software de Roblox pasó de un único centro de datos a un diseño con redundancia geográfica y células aisladas que contienen fallos.

• La arquitectura celular reduce el radio de impacto y permite descartar y reconstruir una célula de forma automatizada.

• Un service mesh con políticas de tráfico y límites de concurrencia evita que una petición problemática se propague entre células.

• El tooling interno, IaC y prácticas de chaos engineering sostienen la resiliencia operativa día a día.

• La migración se planificó por fases desde 2021 con objetivo de operación activo-activo y mejoras continuas.

Contexto: la caída de 73 horas en octubre de 2021

Octubre de 2021. El universo de Roblox se apaga.

Durante 73 largas horas, la plataforma global que conecta a decenas de millones de personas en tiempo real queda en silencio. Un fallo aparentemente menor en un componente de un único centro de datos se propaga como un virus y provoca un colapso en cascada. El sistema, abrumado por reintentos automáticos, se rinde.

Para los ingenieros de Roblox no fue solo una caída. Fue el comienzo de una transformación de infraestructura con el objetivo de que un evento así no volviera a repetirse y que el metaverso de Roblox fuese más resistente a nivel estructural.

Este artículo resume la evolución de la arquitectura de Roblox desde su punto más frágil hasta su diseño actual y aporta ideas prácticas para tus propios sistemas.

El problema: vulnerabilidad por centralización y efecto dominó de reintentos

La arquitectura inicial funcionaba principalmente desde un único centro de datos activo. Esta centralización simplificaba la operación al principio y permitió crecer de forma controlada. Con la escala alcanzada apareció su talón de Aquiles.

Ventaja inicial

• Operar un único clúster gigante es más sencillo y reduce variabilidad al inicio.

Problema de escala

• Un fallo puntual tiene un impacto desproporcionado al no existir un plan B geográficamente independiente con conmutación rápida.

Efecto dominó

• Servicios y clientes reintentaban de forma agresiva. Los reintentos sin control sobrecargaban componentes sanos y convertían una incidencia local en un apagón global.

El dolor de la caída de 73 horas justificó rediseñar con un objetivo claro. Reducir el radio de impacto y hacer que el sistema fuera capaz de absorber fallos sin colapsar.

Patrones de resiliencia a escala

Federado

Sistemas independientes que se comunican entre sí. Como los DNS en la resolución de los dominios.

Peer to Peer

Todos los nodos son iguales y comparten carga y datos. Útil para distribución masiva y tolerancia parcial a fallos. Requiere control fino del enrutado y del estado.

Arquitectura celular

El sistema se divide en réplicas idénticas y aisladas llamadas células. El tráfico se distribuye entre ellas y si una falla las demás siguen operando. Este patrón limita el alcance de un incidente y facilita la recuperación controlada.

Decisión: por qué Roblox adopta arquitectura celular

Roblox eligió arquitectura celular para contener fallos. La idea se inspira en el bulkhead pattern. Igual que un submarino se compartimenta para que una vía de agua no hunda toda la nave, una célula defectuosa se aísla sin afectar al resto.

Pilares de la arquitectura de software de Roblox

Data centers: de activo-pasivo a activo-activo

¿Para qué sirve? Garantizar continuidad ante desastres de un sitio completo y reducir el tiempo de conmutación.

Cómo funciona

• Tras 2021 se construyó un segundo centro de datos en otra región y se operó inicialmente en activo-pasivo. El principal manejaba el tráfico y el secundario quedaba en espera con conmutación manual que podía tardar horas.

• El objetivo final es activo-activo con distribución de peticiones basada en latencia, capacidad y salud. El balanceador global permite mover tráfico casi al instante ante degradaciones.

Tecnologías clave

• Redundancia geográfica, red privada global, balanceadores globales con chequeos de salud y control de capacidad.

Diagrama de células y centros de datos

Arquitectura celular: tamaño, aislamiento y desechabilidad

¿Para qué sirve? Aislar fallos y limitar su alcance para que no afecten al resto del sistema.

Cómo funciona

• Cada centro de datos se divide en células de unas 1.400 máquinas.

• Los servicios se despliegan de forma replicada en múltiples células.

• Una célula degradada se considera desechable. El tráfico se drena y se redirige a otras células sanas.

• La célula afectada se destruye y se reconstruye desde cero con automatización completa.

Tecnologías clave

• Infraestructura como Código, contenedores, orquestación con HashiCorp Nomad y service discovery con Consul.

Service mesh y comunicación inteligente

¿Para qué sirve? Gestionar el tráfico entre servicios y entre células con políticas centralizadas para evitar propagación de fallos.

Cómo funciona

• Un proxy sidecar como Envoy se despliega junto a cada instancia y controla todo el tráfico de entrada y salida.

• El mesh aplica enrutado, reintentos con límites, circuit breakers y control de concurrencia.

• El objetivo es mantener afinidad dentro de la misma célula y bloquear patrones de tráfico problemáticos en el borde antes de que crucen células.

Tecnologías clave

• Envoy como proxy, eBPF para observabilidad a nivel de kernel y mecanismos de service discovery.

Automatización y tooling

¿Para qué sirve? Gestionar una infraestructura a gran escala de forma segura y validar resiliencia de manera proactiva.

Cómo funciona

• Orquestación con la HashiStack. Nomad para planificar cargas de trabajo, Consul para descubrir servicios y Vault para gestionar secretos.

• Plataformas internas para el ciclo de vida de microservicios. Desde creación y despliegue hasta observabilidad.

• Chaos Engineering con TACO Tuesdays donde se restringe capacidad en producción para descubrir debilidades antes de picos de fin de semana.

• Defragmentación a nivel de hardware. Alinear ubicación física de máquinas con células lógicas para que el aislamiento sea también físico.

Tecnologías clave

• HashiStack, plataformas de CI y CD personalizadas, herramientas de chaos engineering y automatización de provisionamiento.

Métricas y buenas prácticas de resiliencia

• Radio de impacto por célula y por centro de datos.

• Reintentos con backoff exponencial y presupuestos de error para evitar tormentas de tráfico.

• Timeouts coherentes entre cliente y servidor con límites de concurrencia en puntos críticos.

• Circuit breakers en llamadas de mayor fan out y en límites inter célula.

• MTTR y MTTD monitorizados con alertas por latencia p95 y p99 y error budget por región.

Lecciones aplicables y checklist

• Diseña para contener el fallo. Elige un tamaño de célula que puedas drenar y reconstruir con rapidez.

• Asegura afinidad de tráfico. Minimiza saltos entre células y corta patrones de consultas con alto fan out.

• Automatiza la recuperación. Todo lo que dependa de intervención manual añade minutos al MTTR.

• Practica la resiliencia. Programa game days y limita capacidad de forma controlada para validar supuestos.

• Mide lo que importa. Latencias, errores por célula y tasa de reintentos cuentan más que el promedio global.

Preguntas frequentes que me surgieron mientras investigaba

Cómo reduce la arquitectura celular el radio de impacto en producción

Divide el sistema en compartimentos equivalentes y aislados. Si uno falla, los demás siguen sirviendo tráfico. El enrutado evita que peticiones nuevas impacten la célula degradada y permite reconstruirla sin detener todo el sistema.

Qué diferencia práctica hay entre activo-pasivo y activo-activo

En activo-pasivo un sitio sirve tráfico y otro espera conmutación. La conmutación puede requerir pasos manuales. En activo-activo ambos sirven tráfico y el balanceador global mueve carga según salud y latencia. La recuperación es más rápida y la capacidad se aprovecha mejor.

Cuándo usar reintentos con backoff y cuándo cortar con circuit breaker

Reintentos con backoff funcionan ante fallos transitorios y colas breves. Si el servicio está saturado o la latencia se dispara, el circuito debe abrirse para proteger al resto. Conviene poner límites por cliente y por ruta para no amplificar el problema.

Por qué un service mesh ayuda a aislar fallos entre células

El mesh aplica políticas de tráfico coherentes en todo el plano de datos. Puede forzar afinidad intra célula, limitar fan out y bloquear patrones peligrosos antes de cruzar células. Así evita contagio y preserva capacidad útil.

Qué métricas seguir para validar resiliencia por célula

Errores y latencia p95 p99 por célula, tasa de reintentos por cliente, saturación de colas, uso de CPU y memoria en puntos críticos y tiempo de drenado y reconstrucción de una célula completa.

👋 ¿Quieres dominar el System Design?

📚 Referencias:

1. How We're Making Roblox's Infrastructure More Efficient and Resilient (Roblox Tech Blog)

2. The Infrastructure Supporting Record-Breaking Experiences (Roblox Tech Blog)

3. Roblox Builds New Cellular Infrastructure to Improve Gaming Experience (InfoQ)

4. Roblox Return to Service 10/28-10/31 2021 (Informe oficial de la caída)

📝 Otros artículos de interés

🙏 Una última cosa antes de que te vayas:

Siempre estoy trabajando para hacer esta newsletter aún mejor.

¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?

👉 Responde la encuesta aquí

Nos vemos en el próximo correo,

Fran.

He estado un poco desaparecido durante el verano, pero igual que los niños vuelven al cole, ¡yo vuelvo a esta newsletter!

Este artículo es sobre una noticia de este verano donde CloudFlare tomó una postura muy clara en contra del scraping sin límites para bots de IA.

¡Espero que te resulte interesante!

La web funcionó durante años con un pacto simple: los buscadores rastrean, indexan y envían tráfico a los sitios. En 2025 ese equilibrio está roto. Los bots de IA consumen contenido para entrenar y responder sin devolver visitas. Cloudflare ha movido el control al borde de la red y ha introducido identidad criptográfica y un nuevo modelo económico. En este artículo explico la arquitectura que hay detrás, cómo se decide quién entra, quién no y quién paga, y qué implicaciones tiene para SEO y para la operación diaria de un sitio a nivel técnico.

Como editor de dos newsletters que pasan los 20.000 lectores, he visto cómo una parte de consultas se resuelve dentro de un LLM, sin clic.

Por qué bloquear bots de IA hoy y qué cambia frente a robots.txt

El fichero robots.txt nació como código de conducta.

• Ventaja: era simple y universal.

• Problema: dependía de la buena fe del bot.

En 2025, con crawlers de entrenamiento, ese modelo honorífico no basta. Datos recientes de Cloudflare muestran que solo cerca del 37 % de los 10.000 dominios superiores disponen de robots.txt y, de esos, porcentajes de un dígito bloquean agentes de IA muy conocidos como GPTBot o Google-Extended. Además, los ratios de rastreo frente a referidos de plataformas de IA son órdenes de magnitud peores que los de buscadores tradicionales.

Cloudflare ha convertido ese “por favor, no me rastrees” en una política aplicada en el borde. La compañía ve más de 57 millones de peticiones por segundo y usa ese contexto global para puntuar y filtrar tráfico automatizado. Para nuevos dominios, ha virado a un enfoque por permiso, con bloqueo de crawlers de IA sin permiso o compensación como configuración por defecto. En paralelo, ha abierto una vía para cobrar el acceso con HTTP 402.

Para los que como yo trabajáis con microservicios o webs en producción, nunca confío en un robots.txt como única barrera. En sitios con picos de tráfico orgánico prefiero la imposición en red con reglas de borde y un robots.txt gestionado de apoyo. Así evito sorpresas si un bot decide ignorar directivas.

Guía rápida: activar el bloqueo de bots de IA sin hacer de “clickops”

Cloudflare mantiene una regla gestionada que bloquea scrapers y crawlers de IA conocidos, actualizada conforme aparecen nuevas huellas. Está disponible para todos los planes y nace de un hallazgo práctico: una regla WAF que reta o bloquea peticiones con puntuación de bot baja corta la inmensa mayoría del scraping, aunque el agente cambie su User-Agent. En sus propios análisis, un umbral en torno a 30 ha resultado efectivo para retar y reducir falsos positivos.

Como recomendación personal, si activáis esto, lo combinaría con una lista de permitidos para bots verificados. Por ejemplo, creo que todos queremos que nuestra página salga en ChatGPT, pero no que nuestro contenido se use para entrenamiento de GPT-6 sin que incluya un link a nuestra web.

Reglas WAF con bot score

La detección se apoya en un modelo multicapa: Heurísticas y huellas, detección por JavaScript, anomalías de comportamiento y un modelo global entrenado con el tráfico de la red.

De ese proceso sale un bot score de 1 a 99, donde valores bajos indican alta probabilidad de automatización. Cloudflare recomienda retar a partir de 30 y escalar según resultados.

Ejemplos de reglas expresivas que suelo aplicar por fases:

Cloudflare publica plantillas similares que combinan score con condiciones de agente y contexto. Ajusta los umbrales a tu patrón de tráfico y monitoriza respuestas 403 y tasas de resolución de retos.

Robots.txt gestionado: permitir SEO y desautorizar entrenamiento

El robots.txt gestionado por Cloudflare automatiza un mantenimiento que, de forma manual, se vuelve frágil y desactualizado. Inserta directivas de no entrenamiento para agentes como Google-Extended o Applebot-Extended y mantiene tu posicionamiento al no tocar Googlebot. Es un guardarraíl, no un control de acceso, y Cloudflare lo explica explícitamente. Para control real, usa reglas de borde.

Plantilla de ejemplo centrada en entrenamiento, no en indexación:

User-agent: Google-Extended
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: GPTBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Bytespider
Disallow: /

# SEO intacto
User-agent: Googlebot
Allow: /

Sitemap: <https://example.com/sitemap.xml>

Cloudflare ha observado que muchos dominios bloquean GPTBot y olvidan Google-Extended, lo que deja una brecha importante. El robots.txt gestionado corrige esa asimetría y se mantiene al día con el panorama de bots.

Cuando probé a desautorizar solo GPTBot, el efecto fue menor de lo esperado. Añadí Google-Extended y Anthropic y la exposición bajó mucho. Desde entonces prefiero delegar este archivo en la opción gestionada y concentrarme en la imposición a nivel edge.

Bloqueo solo en páginas con anuncios: cuándo y cómo configurarlo

No todos quieren un bloqueo total. Si monetizas con publicidad, puedes bloquear bots de IA únicamente en páginas con anuncios. La detección no es mágica, es ingeniería: el borde parsea el HTML en streaming con un parser de muy baja latencia, busca patrones de unidades de anuncio y recursos de ad servers conocidos. Además, se alimenta de informes CSP de Page Shield para cubrir inserciones dinámicas. Con esas señales, marca hostnames con ads y aplica la política solo donde te da dinero.

Verified Bots y Firmas de mensajes HTTP: identidad criptográfica para crawlers

IP y User-Agent son débiles. La alternativa es que el bot se autentique con una firma criptográfica de la petición. La especificación es HTTP Message Signatures, estandarizada como RFC 9421. Cloudflare la ha integrado en su programa Verified Bots y valida en el borde las cabeceras Signature-Input, Signature y Signature-Agent. Con eso puede marcar una petición como verificada y tú puedes fiarte de que ese “Google-<algo>” realmente es quien dice ser.

Ejemplo formateado a partir de la documentación y ejemplos de Cloudflare:

GET /ruta HTTP/1.1
Host: www.ejemplo.com
User-Agent: Mozilla/5.0
Signature-Agent: "<https://bot-keys.example.org/.well-known/http-message-signature-directory>"
Signature-Input: sig=("@authority" "signature-agent");created=1700000000;expires=1700011111;keyid="ed25519:abcd";tag="web-bot-auth"
Signature: sig=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQ...==:

Cloudflare verifica el material de claves publicado en el directorio .well-known/http-message-signature-directory, reconstruye la base de firma con los componentes especificados y valida con Ed25519. Si todo cuadra, marca el tráfico como verificado y puedes crear reglas sobre cf.bot_management.verified_bot o incluso segmentar por categoría de bot verificado.

Pay per crawl: cómo funciona el 402 Payment Required y para qué te sirve

Bloquear o permitir ya no son las únicas opciones. Cloudflare ha presentado un modelo de cobro por rastreo que usa el histórico código 402 Payment Required y cabeceras declarativas.

El bot pide un recurso, el borde responde 402 con crawler-price y si el agente acepta, reintenta con crawler-exact-price.

Un flujo proactivo sería que el bot adelanta un crawler-max-price y, si cubre el precio configurado, el borde sirve el 200 con crawler-charged.

Cloudflare actúa como merchant of record, agrega eventos y liquida al editor. Está en beta privada y se integra con la verificación criptográfica para evitar suplantaciones.

Ejemplos de intercambio mínimos:

HTTP/2 402 Payment Required
crawler-price: USD 0.01

# Reintento aceptando el precio exacto
GET /articulo.html
Signature-Agent: "<https://bot-keys.example.org/.well-known/http-message-signature-directory>"
Signature-Input: ...
Signature: ...
crawler-exact-price: USD 0.01

HTTP/2 200 OK
crawler-charged: USD 0.01

Esto abriría un mecanismo para que tu web monetice por salir en los principales resultados de ChatGPT, pero de primeras podría hacer que tuviera menos tráfico porque estos bots de IA decidan no pagar nunca y referenciar webs que sean gratis.

Métricas, pruebas y rollback seguro: cómo validar que todo sigue indexando

Medir es la única forma de operar sin miedo. KPIs recomendados y dónde obtenerlos:

• Crawl-to-refer por operador. Cloudflare Radar publica tendencias por bot y sector y la propia plataforma expone AI Insights. Úsalo para decidir a quién bloqueas, a quién cobras y a quién dejas pasar.

• Tasa de desafíos resueltos y 403 por ruta. Ajusta umbrales y excepciones con base en ello.

• Monitorea errores de indexación en Search Console cuando apliques cambios. Aunque uses robots.txt gestionado, recuerda que robots.txt no bloquea a quien no lo respeta.

• Porcentaje de tráfico autenticado como Verified Bot frente a no autenticado. Con firmas, este dato debería subir con el tiempo.

Matriz de decisiones y trade-offs

Caso práctico breve, expresado como política

Política reproducible que he aplicado en un sitio editorial:

1. robots.txt gestionado activado, con SEO intacto para Googlebot y bloqueo a Google-Extended, Anthropic y GPTBot.

2. Regla WAF de desafío para score < 30 y bloqueo para score < 2.

3. Bloqueo en hostnames con anuncios activado, manteniendo docs abiertos.

4. Bots verificados con firma en allow, basados en RFC 9421 y Web Bot Auth.

5. Piloto de 402 en piezas evergreen con alta demanda de LLM.

En resumen

La emergencia de los motores de respuestas de IA ha roto el modelo económico fundamental de la web abierta. En respuesta, ha surgido una nueva arquitectura de control y monetización:

• El antiguo pacto de valor, basado en el tráfico referido por los motores de búsqueda, ya no es funcional.

• El mecanismo tradicional de robots.txt, basado en un sistema de honor, es insuficiente para gestionar a los scrapers de IA.

• La solución arquitectónica pasa por mover la imposición de políticas al borde de la red (edge), donde se puede actuar a escala global.

• La identificación de bots se basa en un sistema multicapa que combina heurísticas, machine learning y criptografía para una precisión máxima.

• Las Firmas de Mensajes HTTP (RFC 9421) crean una identidad digital verificable para los bots, un pilar para las interacciones de confianza.

• La iniciativa "Pay per crawl", utilizando el código de estado HTTP 402, establece las bases para una economía programática donde el contenido se paga directamente.

• El objetivo final es reestablecer un intercambio de valor justo que incentive la creación de contenido original y de alta calidad, asegurando la sostenibilidad de la web abierta

👋 PD – ¿Quieres dominar el system design?

Preguntas que yo mismo me he hecho escribiendo este artículo

Cómo bloqueo GPTBot sin romper SEO

Usa robots.txt gestionado para expresar tu política de no entrenamiento y una regla WAF por score para imponerla a quienes ignoren robots.txt. Mantén permitidos bots verificados de búsqueda.

Qué diferencia hay entre Googlebot y Google-Extended

Googlebot indexa y trae tráfico. Google-Extended se usa para entrenamiento de modelos. Puedes permitir el primero y desautorizar el segundo en robots.txt.

Cuándo usar bloqueo por anuncios en lugar de bloqueo total

Cuando la prioridad es proteger ingresos publicitarios sin cerrar docs o páginas de soporte. El borde detecta anuncios inspeccionando HTML y señales CSP y aplica la política solo en esos hostnames.

Por qué cf.bot_management.score 30 es un buen umbral inicial

Porque reduce falsos positivos y captura crawlers que intentan camuflarse con User-Agents cambiantes. Cloudflare lo recomienda en sus análisis y documentación. Ajusta con datos de tu tráfico.

Qué garantías tengo de que un bot verificado es auténtico

Firmas de mensajes HTTP según RFC 9421. El bot firma con su clave privada, publica sus claves públicas en un directorio bien conocido y Cloudflare valida la firma en el borde.

👋 PD – ¿Quieres dominar el system design?

📚 Referencias

1. Visión general y cambio de política: Content Independence Day: no AI crawl without compensation!

2. Detalles de la iniciativa de monetización: Introducing pay per crawl

3. Identidad criptográfica para bots: Verified Bots with Cryptography (HTTP Message Signatures)

📝 Otros artículos de interés

👏 Aplauso semanal

Aquí algunos artículos que me han gustado esta última semana:

• 12 herramientas top para arrancar potente en Septiembre de . Una lista de herramientas que van desde asistentes de programación hasta soluciones de backend y automatización

• Noticias de la semana 15.09.25 de . Lista de noticias cada semana sobre AWS y serverless. Lo más interesante para mí el lanzamiento de Amazon Bedrock AgentCore para desplegar agentes de IA.

• Cuando alguien rompe a llorar... ¿Manager o psicólogo? de . Los managers no son terapeutas, pero sí deben dominar los “primeros auxilios emocionales”.

🙏 Una última cosa antes de que te vayas:

Siempre estoy trabajando para hacer esta newsletter aún mejor.

¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?

👉 Responde la encuesta aquí

Nos vemos en el próximo correo,

Fran.

Han pasado varias semanas sin artículo, demasiadas cosas entre vida personal y trabajo… Pero no te olvides de tu newsletter favorita, hoy vuelvo con una serie de técnicas para escalar tu base de datos relacional.

¡Espero que te guste!

Fran

Las bases de datos relacionales nos dan poder, estructura y consistencia.

Pero cuando empiezan a flaquear bajo una gran escala, es fácil tomar la decisión equivocada, como crear índices sin medir, o hacer sharding demasiado pronto.

En los últimos años, he trabajado en infraestructura de migración de bases de datos, pruebas de failover y depuración de rendimiento en varios equipos.

Lo que he aprendido es esto: escalar no se trata tanto de trucos ingeniosos, sino de conocer tu carga de trabajo, elegir el compromiso adecuado y entender el eslabón más débil de tu sistema.

⭐ En este artículo, aprenderás

• Cuándo usar el escalado vertical antes de sumergirse en la complejidad distribuida

• Qué mejoras de bajo esfuerzo generan un alto impacto (como la indexación y el caching)

• Cómo escalar lecturas y escrituras de forma independiente con replicación y sharding

• Técnicas para gestionar grandes conjuntos de datos con particionamiento y archivado

• Cómo elegir la estrategia correcta usando un marco de decisión práctico

🏗️ #1 Introducción: por qué es difícil escalar bases de datos relacionales

Las bases de datos relacionales son geniales hasta que dejan de serlo. Funcionan bien desde el principio para la mayoría de las startups, pero a medida que aumenta la carga, alcanzas los límites rápidamente. Especialmente con RDBMS tradicionales como PostgreSQL o MySQL, que nunca fueron diseñados para una escala masiva o escrituras multirregión.

Puedes solucionar el problema añadiendo más hardware (escalado vertical) o dividiendo los datos entre máquinas (escalado horizontal). Ambas opciones conllevan costes y complejidad. Las decisiones de escalado también afectan a la fiabilidad, el rendimiento y la capacidad de mantenimiento de tu equipo a largo plazo.

Imagina que tu instancia de PostgreSQL empieza a dar timeouts en horas punta. ¿Replicación? ¿Indexación? ¿Sharding? Este artículo te ayudará a elegir el siguiente paso correcto.

📈 #2 Escalado vertical: la opción obvia pero limitada

El escalado vertical es simple. Añade más CPU, memoria o SSD a tu servidor de base de datos. Normalmente funciona, hasta que deja de hacerlo.

Si la CPU está al máximo, aumenta el tamaño de la instancia. Si el problema son las IOPS, cambia a volúmenes provisionados. La ventaja: no hay cambios en la aplicación. La desventaja: siempre hay un límite. Y la factura es cada vez más cara.

He visto equipos posponer soluciones adecuadas durante demasiado tiempo por confiar en el escalado vertical. Una vez, tuve un PostgreSQL con consultas que tardaban demasiado. Se podría haber pensado que tener una instancia más potente ayudaría, pero la instancia existente ya estaba infrautilizada. El problema de raíz eran planes de consulta ineficientes y la falta de índices para consultas costosas.

Usa el escalado vertical al principio. Pero a medida que el tráfico crece o tu conjunto de datos se hace más grande, se convierte en una tirita temporal en lugar de una solución a largo plazo.

🧮 #3 Indexación: la victoria fácil del rendimiento

Los índices suelen ser la forma más rápida de solucionar problemas de rendimiento sin tocar el código. Funcionan creando atajos para que la base de datos encuentre los datos.

Tienes opciones: B-tree (por defecto), hash, GIN para búsqueda de texto completo, BRIN para datos de series temporales, índices parciales para cubrir casos específicos. He tenido casos en los que añadir un simple índice en user_id redujo la latencia de los joins en 10 veces. Algunas bases de datos como PostgreSQL incluso permiten crear índices funcionales, como por ejemplo indexar una columna en lower_case cuando la columna original no está en minúsculas, pero algún patrón de consulta utiliza la función LOWER().

Pero nada es gratis. Los índices ralentizan las escrituras y aumentan el almacenamiento. También necesitan mantenimiento. En mi equipo el año pasado, notamos que un par de índices nunca se usaban. Pudimos eliminarlos tras revisar nuestros patrones de consulta.

Usa índices cuando tu problema sea la latencia de lectura y el patrón de acceso sea predecible. Evita indexar ciegamente cada columna: monitoriza primero los planes de consulta.

📚 #4 Replicación: escalar lecturas y garantizar alta disponibilidad

La replicación te permite descargar las lecturas y mejorar la disponibilidad. Copias los datos de un primario a una o más réplicas. Hay diferentes modos: asíncrono, síncrono, semisíncrono, y cada uno intercambia consistencia por rendimiento.

Piensa en tu primario como un chef principal. Las réplicas son asistentes que duplican su trabajo. Te ayuda a servir a más clientes, pero puede que reciban los pedidos con unos segundos de retraso.

No se trata solo de escalar, sino también de fiabilidad. El año pasado, probando el failover de las instancias, encontré formas de reducir el tiempo de failover de 45 a 3 minutos teniendo una réplica de lectura lista para convertirse en el líder en el momento en que el líder fallara. Nunca quieres que tu instancia de escritura falle... hasta que lo hace y prefieres tener 3 minutos de inactividad en lugar de 45.

La replicación ayuda en cargas de trabajo intensivas en lectura y en configuraciones de alta disponibilidad (HA). Solo recuerda: las escrituras siguen yendo al primario, y el lag de replicación puede provocar lecturas de datos obsoletos. Diseña en consecuencia.

🧠 #5 Caching: reducir la presión en la BD con intermediarios más rápidos

Si la replicación se encarga de la escala de lectura, el caching se encarga de la frecuencia de lectura. Se trata de almacenar los datos de acceso frecuente (hot data) más cerca del usuario, a menudo en memoria con Redis, Memcached o AWS DAX.

Aquí es donde quieres saber si tienes más lecturas o escrituras. Si tu carga es intensiva en lecturas, puedes cachear estos datos porque apenas cambian.

Pero el caching es una trampa si no piensas bien en la invalidación. Podrías acabar con bugs de cara al usuario porque los TTL no estaban bien ajustados o las actualizaciones no invalidaban correctamente.

Usa caching cuando los datos cambien lentamente y el throughput de lectura sea importante. Sé explícito sobre cómo se refresca y qué sucede en los fallos de caché (cache misses).

🧾 #6 Desnormalización: intercambiar pureza por rendimiento

La desnormalización consiste en duplicar datos entre tablas para evitar joins en el momento de la lectura. Es un compromiso: velocidad a cambio de duplicación de datos.

Esto funciona bien para analítica, dashboards o cualquier cosa donde el rendimiento importe más que la consistencia. Pero tienes que pensar detenidamente en las rutas de actualización.

Solo desnormaliza cuando esté respaldado por una propiedad clara y rutas de escritura sólidas. No lo hagas solo para “facilitar las consultas”.

📊 #7 Vistas materializadas: precomputar consultas costosas

Cuando te enfrentas repetidamente a agregaciones costosas, las vistas materializadas son una victoria. Calculas una consulta compleja una vez y reutilizas el resultado.

Es rápido y predecible. Pero puede quedar obsoleto si no se refresca correctamente. Necesitas una estrategia clara sobre cuándo y cómo refrescar, especialmente si los datos provienen de muchas fuentes.

Genial para dashboards, herramientas de BI o trabajos por lotes (batch jobs). Solo no olvides que es una instantánea (snapshot), no el estado en vivo.

🪵 #8 Particionamiento: dividir tablas grandes en trozos más pequeños y manejables

El particionamiento divide tablas grandes en piezas lógicas basándose en una columna como la fecha o la región. Es imprescindible para datos de series temporales, logs o cualquier cosa que crezca linealmente.

Imagina tener una tabla de logs con más de mil millones de filas. Una vez que la particionas por mes, las consultas pasan de minutos a segundos. Archivar datos antiguos también se volvió trivial. Puedes moverlos fuera de tu base de datos a una infraestructura de almacenamiento en frío (cold storage), como AWS S3 Glacier.

Pero añade complejidad al esquema. Tienes que gestionar la creación de particiones y evitar una distribución desigual de los datos.

Usa el particionamiento cuando el tamaño de la tabla perjudica el rendimiento de las consultas o la limpieza. Especialmente cuando las consultas se centran en datos recientes y guardas los datos antiguos por cumplimiento normativo y no para una funcionalidad del cliente.

🧩 #9 Sharding: escalado horizontal de escritura con datos distribuidos

El sharding es el jefe final del escalado de bases de datos. Divides los datos entre instancias, a menudo por un hash de una clave como user_id. Cada shard es como una base de datos independiente más pequeña.

Esto escala las escrituras y aísla la carga. Pero conlleva enormes costes. No hay transacciones globales. No hay joins entre shards. Migraciones complejas. Necesitas un enrutamiento de consultas inteligente y automatización.

Usa sharding solo cuando un único nodo de escritura es el cuello de botella y tus datos se segmentan de forma natural.

👉 Existen muchos algoritmos de sharding. Hazme saber en los comentarios si te interesa este tipo de contenido para seguir escribiéndolo.

🧊 #10 Archivado: mantén la ruta crítica ligera

No necesitas todos los datos en línea. El archivado mueve los datos de acceso poco frecuente (cold data) a un almacenamiento más lento y barato. Mantiene tu base de datos principal rápida y ligera.

Por ejemplo, archiva los pedidos de más de dos años en S3 o en una base de datos separada. La base de datos activa se mantiene rápida. Los datos archivados siguen disponibles si es necesario, solo que su acceso es más lento.

En Amazon, esto surge a menudo. Los equipos suelen ignorar la limpieza y las bases de datos se sobrecargan. Sin embargo, cuando un equipo configura un almacenamiento en frío (cold storage) y algunas reglas de ciclo de vida para mover datos automáticamente, su factura se reduce considerablemente.

Archiva cuando tengas reglas de retención claras y un acceso poco frecuente. Construye rutas de rehidratación desde el principio para evitar sorpresas.

🛠️ #11 Técnicas avanzadas (bonus)

El pool de conexiones es higiene básica. Sin él, tu aplicación se colapsará a sí misma abriendo nuevas conexiones en cada petición. Usa siempre un pool.

La optimización de consultas significa usar EXPLAIN a menudo para identificar los patrones de acceso a datos, corregir joins ineficientes y reescribir consultas lentas.

Los patrones de lectura tras escritura (read-after-write) son importantes si usas caching o réplicas. Si tu aplicación lee datos obsoletos después de escribir, prueba con write-through caching o espera a que las réplicas se pongan al día. No puedes pensar en una base de datos sin pensar en la aplicación que la utiliza.

La replicación multirregión puede reducir la latencia, pero la coordinación global es difícil. Solo vale la pena cuando los usuarios abarcan continentes y la latencia es un factor clave.

🧭 #12 Marco de decisión: eligiendo la estrategia de escalado correcta

Checklist:

• ¿El cuello de botella es la CPU, la memoria o las IOPS?

• ¿Estás escalando lecturas, escrituras o ambas?

• ¿Necesitas consistencia fuerte o la consistencia eventual es suficiente?

• ¿Las consultas son lentas por el tamaño de los datos, una mala indexación o joins complejos?

• ¿Puedes hacer sharding por usuario, organización o alguna otra clave natural?

🎯 Conclusión

Escala por etapas. La mayoría de los sistemas no necesitan sharding ni vistas materializadas el primer día. Empieza con victorias sencillas como la indexación o el caching. Mide, y luego optimiza.

Invierte en observabilidad para saber dónde está sufriendo tu base de datos. Añade presión gradualmente e itera con un propósito.

El escalado no es una funcionalidad que “añades”. Es una negociación constante entre rendimiento, complejidad y mantenibilidad. Construye lo que tu sistema realmente necesita, no lo que parece impresionante.

📝 Otros artículos de interés

👏 Aplauso semanal

Aquí algunos artículos que me han gustado esta última semana:

• DynamoDB global tables con consistencia fuerte: ¿cómo lo hicieron? por . Este artículo explica cómo Amazon DynamoDB logró una consistencia fuerte para las tablas globales multirregión, detallando las complejidades de ingeniería y la introducción de un journal multirregión.

• El reto de parecer estúpido y estar bien con ello por . Este artículo aborda la frustración y el sentimiento de "estupidez" que a menudo acompañan a los desarrolladores al enfrentarse a errores, proponiendo la aceptación de la ignorancia como motor de curiosidad y la importancia de equivocarse para progresar

🙏 Una última cosa antes de que te vayas:

Siempre estoy trabajando para hacer esta newsletter aún mejor.

¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?

👉 Responde la encuesta aquí

Nos vemos en el próximo correo,

Fran.

Un nuevo modo de juego dentro de League of Legends explota en popularidad. Se llama Teamfight Tactics (TFT) y en pocos meses alcanza los 33 millones de jugadores mensuales. Lo que empezó como un proyecto pequeño se convierte en un pilar para Riot Games.

Cada dos semanas, el equipo lanza un parche con nuevos campeones, objetos y mecánicas para mantener el juego fresco. Pero un viernes por la tarde, la comunidad descubre un bug crítico: un objeto llamado "Morellonomicón" está aplicando un daño decimal incorrecto, rompiendo el equilibrio del juego por completo.

Esperar al siguiente ciclo de parches de dos semanas es impensable. El juego necesita una solución, o los jugadores acabarán en Reddit criticándolo y dejando de jugar por estar roto. El equipo no dispone de días, sino de horas. Este tipo de crisis no se resuelve con parches convencionales; se necesita una arquitectura diseñada para la velocidad, la precisión y una escala masiva.

Este post resume la arquitectura de parcheo de Riot Games, un sistema diseñado para mantener mundos online masivos en constante evolución. Al final, encontrarás las referencias para profundizar.

Si quieres dominar el diseño de sistemas y recibir análisis como este cada semana, suscríbete. Te enviaré guías y plantillas para que diseñes sistemas robustos y escalables.

📖 Una historia de dos archivos

Los diseñadores de Teamfight Tactics (TFT) necesitaban moverse muy rápido. Para crear nuevas mecánicas de juego, como el carrusel de campeones o las sinergias de equipo, escribían la lógica en grandes archivos de script en Lua. Estos archivos eran como manuscritos gigantes donde todas las ideas estaban conectadas, permitiendo una iteración y experimentación veloces.

Cuando un bug aparecía, la solución parecía sencilla: corregir el script, codificar el archivo entero en Base64 y enviarlo al servidor como un "micropatch". El servidor, al iniciar una nueva partida, leería este archivo modificado en lugar del original. Rápido y efectivo, ¿verdad?

El problema llegó cuando dos bugs diferentes necesitaban ser corregidos en el mismo archivo monolítico y al mismo tiempo. El equipo A arreglaba el bug del objeto X y desplegaba el archivo. Minutos después, el equipo B arreglaba el bug del campeón Y y desplegaba su versión del archivo. Sin darse cuenta, el parche del equipo B sobrescribía la solución del equipo A, reintroduciendo el bug original. El caos estaba servido.

📦 El Desafío del Micropatch Monolítico

Este enfoque inicial, aunque ágil para el prototipado, generó problemas sistémicos a medida que el juego crecía en complejidad.

• Ventaja inicial: Permitía a los diseñadores implementar y probar sistemas de juego complejos de forma muy rápida, ya que toda la lógica interconectada residía en un único lugar.

• Problema de concurrencia: Desplegar un micropatch para un archivo "bloqueaba" cualquier otro cambio en ese mismo archivo. Para introducir dos correcciones, un ingeniero debía fusionar manualmente ambos cambios en un nuevo archivo, codificarlo y desplegarlo, un proceso lento y propenso a errores.

• Alto riesgo de regresión: Como en la historia anterior, era extremadamente fácil reintroducir bugs antiguos al sobrescribir archivos, creando un ciclo frustrante de "un paso adelante, dos pasos atrás".

💡 Hacia una Arquitectura Desacoplada

Por eso crearon una nueva filosofía, una forma de aplicar principios de ingeniería de software robustos al mundo del scripting de videojuegos para lograr agilidad sin sacrificar la estabilidad.

🗺️ Modelos Comunes de Actualización para Servicios Live

Para mantener un juego online, existen varias estrategias generales.

1. Parches Completos Programados: El modelo tradicional. Todas las actualizaciones (código, arte, lógica) se empaquetan y se lanzan en fechas fijas, requiriendo que el jugador descargue una gran cantidad de datos.

2. Hotfixes del Lado del Servidor: Cambios rápidos que solo afectan a la lógica del servidor, sin necesidad de que el jugador descargue nada. Son ideales para ajustes de balance o correcciones de bugs urgentes

3. Configuración Remota Dinámica: Un sistema donde el cliente del juego obtiene valores de configuración (como el daño de un arma o el precio de un objeto) de un servidor central. Permite cambios instantáneos sin desplegar código nuevo.

Riot Games usa una estrategia híbrida que combina lo mejor de todos los mundos, separando fundamentalmente los datos que viven en el cliente del jugador de los que viven en el servidor.

⚙️ Deep Dive por Componentes

1. Parches Completos (Full Patches)

• ¿Para qué sirve? Para entregar cambios sustanciales que afectan al cliente del juego, como nuevos campeones, skins, mapas o características que requieren nuevo código o assets visuales.

  

• Cómo funciona:

  1. El equipo de desarrollo integra todos los nuevos assets y código en una nueva versión del juego.

  2. Esta versión pasa por un riguroso proceso de QA interno y, a menudo, por un entorno público de pruebas (PBE).

  3. Una vez aprobada, la nueva versión se distribuye globalmente a través de una CDN.

  4. El launcher del jugador detecta la nueva versión, descarga los archivos necesarios y los instala.

• Tecnologías clave: CI/CD pipelines (Jenkins, etc.), sistemas de control de versiones (Perforce, Git), Content Delivery Networks o CDN (como Akamai o Cloudflare) para la distribución global.

Este componente es la base estructural del juego. Las renovaciones periódicas que mantienen la experiencia fresca y expansiva. Van acompañadas de unas "notas del parche" o "notas de la versión"

2. Micropatches

• ¿Para qué sirve? Para desplegar cambios de lógica o datos del lado del servidor de forma casi instantánea, sin requerir una descarga del jugador. Es la herramienta para ajustes de balance y corrección de bugs críticos.

  

• Cómo funciona:

  1. Un ingeniero o diseñador modifica un archivo de datos (un script Lua o valores en el GDS (Game Data Server)).

  2. Este archivo se codifica en Base64, convirtiéndolo en una larga cadena de texto.

  3. Esta cadena se introduce en un archivo de configuración en los servidores de juego con una "micropatch key" específica.

  4. Cuando un servidor de juego necesita cargar ese recurso, primero comprueba si existe una "micropatch key" para él.

  5. Si la clave existe, el servidor decodifica la cadena de Base64 y utiliza estos datos en lugar de los que venían en la instalación original.

• Tecnologías clave: Lua (para la lógica de juego), Base64 (para la codificación), un sistema de gestión de configuración para distribuir los overrides.

3. El GDS - Game Data Server

• ¿Para qué sirve? Para centralizar y servir todos los datos numéricos del juego: daño de habilidades, vida de los campeones, costes de maná, estadísticas de objetos, etc.

  

• Cómo funciona:

  1. Los servidores de juego, al iniciar una partida, consultan al GDS para obtener los parámetros de juego actualizados.

  2. El GDS actúa como una fuente única de verdad para todos los valores numéricos.

  3. Los micropatches pueden sobrescribir valores específicos en el GDS, permitiendo a Riot cambiar el daño de una habilidad de 100 a 95 en todos los servidores del mundo con un solo despliegue.

• Tecnologías clave: Probablemente un sistema de base de datos distribuida o un servicio de key-value optimizado para lecturas rápidas y alta disponibilidad.

4. El Refactor de Scripts en Lua

• ¿Para qué sirve? Para resolver el problema de los micropatches monolíticos en TFT y hacer que el sistema fuera mantenible a largo plazo.

  

• Cómo funciona:

  1. El equipo de ingeniería impulsó un cambio cultural y técnico para reestructurar los scripts de Lua.

  2. Aplicaron principios clave de la ingeniería de software como SOC - Separation of Concerns, DRY (Don't Repeat Yourself) y Abstracción.

  3. Los enormes archivos monolíticos se dividieron en módulos más pequeños, enfocados y poco acoplados. Un módulo para el carrusel, otro para el combate, otro para las sinergias de rasgos.

  4. Ahora, para corregir un bug en el carrusel, solo se necesita modificar y desplegar el pequeño archivo del módulo del carrusel, sin riesgo de afectar al sistema de combate.

• Tecnologías clave: Lua, pero sobre todo, principios de diseño de software y una fuerte colaboración entre ingenieros y diseñadores.

Personalmente pienso que este videojuego fue un muy buen ejemplo de cómo juntar ingeniería y empresa. Fue un MVP en un proceso de Riot Games de crear más juegos aparte de League of Legends. Empezaron con estos scripts monolíticos y el éxito fue lo que les dio la validación de que aquí había un producto en el que invertir recurdsos.

5. Gestión de Parches Móviles

• ¿Para qué sirve? Para gestionar el despliegue de parches en plataformas móviles (iOS y Android), que tienen sus propias reglas y complejidades.

• Cómo funciona:

  1. Cualquier parche de cliente para móvil debe ser enviado a la App Store de Apple y a la Google Play Store para su revisión.

  2. Este proceso de revisión puede introducir retrasos impredecibles.

  3. Lo más crítico es garantizar la compatibilidad de cross-play. Un jugador de móvil con la versión 1.1b (que corrige un bug visual solo en móvil) debe poder jugar sin problemas contra un jugador de PC con la versión 1.1a.

  4. Para ello, se realizan pruebas exhaustivas en entornos de QA que simulan estas condiciones de versiones mixtas, asegurando que los clientes pueden comunicarse con el mismo servidor común.

• Tecnologías clave: App Store Connect, Google Play Console, entornos de testeo dedicados para cross-play.

Al final, cada plataforma tiene un equipo de ingenieros dedicados. Corregir un bug en todas las plataformas de un videojuego online con cross-play no puede tener un ETA distinto para cada uno.

✅ En resumen:

Para actualizar un mundo online con millones de jugadores, la arquitectura de Riot se basa en:

• Separación fundamental: Los datos del cliente (assets pesados) están separados de los datos del servidor (lógica crítica).

• Modelo híbrido: Combina grandes parches completos programados con pequeños y ágiles micropatches del lado del servidor.

• Overrides inteligentes: Los micropatches funcionan como un sistema de anulación (override) que utiliza Base64 para empaquetar y desplegar cambios de lógica sin tocar el cliente.

• Datos centralizados: El Game Data Server (GDS) actúa como una fuente única de verdad para todos los parámetros numéricos, facilitando los ajustes de balance.

• Diseño de software en scripting: La evolución de TFT demuestra que aplicar principios como la Separación de Intereses a los scripts es vital para la mantenibilidad.

• Complejidad multiplataforma: La gestión de parches móviles añade una capa de desafíos por las revisiones de las tiendas y la necesidad de garantizar la compatibilidad cross-play.

• Infraestructura a escala: Todo esto se apoya en una robusta red global de servidores (Riot Direct), CDNs para la distribución de contenido y pipelines de CI/CD altamente automatizados.

👋 PS – ¿Quieres dominar el system design?

📚 Referencias:

1. Bug Blog: TFT Bugs and Patches (Riot Games Technology Blog)

2. Riot Games Engineering Blog: technology.riotgames.com

3. Charlas de Riot Games en la GDC (Game Developers Conference) sobre infraestructura y operaciones live.

📝 Otros artículos de interés

👏 Aplauso semanal

Aquí algunos artículos que me han gustado esta última semana:

• Aplica la IA para mejorar tu productividad por . La productividad con IA es un proceso gradual que va desde aprender a usar prompts hasta automatizar tareas complejas, supervisando siempre los resultados. La base de todo sigue siendo el prompt.

• La Inteligencia Artificial ha cambiado mi mundo por . La IA tendrá un papel fundamental en la automatización en los próximos años, y se pueden crear agentes de IA, como un asistente de marketing, para optimizar tareas.

• La seguridad se refuerza: lo nuevo en AWS WAF y más antes del re:Inforce 🔒 por . AWS introduce una nueva capa de defensa contra ataques DDoS a nivel de aplicación con AWS WAF, además de mejoras en Powertools para Lambda, cifrado en AppSync y mayor precisión en Amazon Lex.

• 👨‍💻👩‍💻🎙️Ya no pago IRPF por . Un experto en fiscalidad internacional explica las opciones legales que tienen los freelancers para reducir su carga impositiva, discutiendo temas como la residencia fiscal, la optimización de impuestos y los errores comunes.

• 🔍 Qodex.ai: API testing inteligente con generación automática de pruebas y plan gratuito 🚀 por . Qodex.ai es una herramienta que utiliza IA para generar y ejecutar pruebas de API automáticamente a partir de su documentación, reduciendo el esfuerzo manual y ayudando a detectar errores rápidamente.

🙏 Una última cosa antes de que te vayas:

Siempre estoy trabajando para hacer esta newsletter aún mejor.

¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?

👉 Responde la encuesta aquí

Nos vemos en el próximo correo,

Fran.

A las 13:00 CET del 8 de mayo, se abren las preventas en Ticketmaster.es y LiveNation.es.

En cuestión de minutos, la euforia se transforma en frustración. Errores "500 Internal Server Error" o "503 Service Unavailable" inundan las pantallas.

Las colas virtuales se vuelven infinitas, con reportes de más de un millón de usuarios concurrentes intentando acceder.

El sistema, simplemente, colapsó.

No era la primera vez; la historia se repetía, recordando fiascos anteriores con artistas como Taylor Swift.

Pero, ¿qué sucede exactamente bajo el capó para que gigantes como Ticketmaster y Live Nation se arrodillen ante la demanda?

⚡ Contexto rápido

Este post resume la arquitectura detrás de estos gigantes de la venta de entradas y los puntos críticos que fallaron estrepitosamente ante la avalancha de tráfico. Al final, encontrarás referencias para profundizar aún más.

🏰 El Problema de la Demanda Masiva

Había una vez un mundo donde conseguir entradas para un concierto implicaba hacer cola física durante horas, a veces días.

Con la llegada de internet, la promesa era la comodidad y la eficiencia. Ticketmaster, fundado en 1976, y Live Nation, surgido mucho después y fusionado con Ticketmaster en 2010, digitalizaron este proceso.

Durante años, sus sistemas evolucionaron desde infraestructuras on-premise, con servidores físicos que tenían una capacidad finita y conocida, hacia arquitecturas más modernas.

Se pensaba que la nube y sus promesas de escalabilidad infinita serían la solución definitiva. Sin embargo, eventos de altísima demanda, como los conciertos de Bad Bunny o Taylor Swift, demostraron que incluso las arquitecturas cloud más robustas tienen un límite si no se diseñan y gestionan para picos verdaderamente extremos

⚙️ La tormenta de usuarios

La migración a la nube (principalmente AWS) y el uso de microservicios ofrecieron mayor agilidad y capacidad de escalado horizontal en comparación con sistemas monolíticos antiguos.

• Problema 1: Picos impredecibles y subestimados. Aunque se esperara alta demanda, la magnitud real, con millones de usuarios y miles de millones de peticiones en pocas horas (como los 3.5 mil millones para Taylor Swift), superó las previsiones y la capacidad de autoescalado instantáneo.

• Problema 2: Cuellos de botella transaccionales. La selección y bloqueo de asientos es inherentemente una operación crítica que requiere consistencia y bloqueos en la base de datos, difícil de escalar horizontalmente bajo una avalancha de escrituras.

• Problema 3: El efecto "retry storm". Usuarios y bots frustrados recargando la página sin cesar, multiplicando la carga sobre sistemas ya estresados, creando un círculo vicioso. Lo que para el usuario es 1 petición, para un sistema múltiples niveles en profundidad pueden ser muchas por los retries:

  

🗺️ Modelos Comunes para Gestionar Avalanchas de Tráfico

Cuando se enfrenta a una demanda masiva y repentina, existen varios patrones arquitectónicos y estrategias generales que los sistemas pueden emplear:

1. Escalado Elástico Agresivo: Diseñar para que la infraestructura (servidores, bases de datos, balanceadores) pueda multiplicarse rápidamente ante picos, y reducirse después.

2. Sistemas de Cola Avanzados: No solo una "sala de espera", sino colas de mensajes desacopladas (como Kafka o SQS) que procesan peticiones a un ritmo que el backend pueda soportar.

3. Rate Limiting y Throttling en el Edge: Bloquear o ralentizar peticiones excesivas directamente en el CDN o API Gateway antes de que lleguen a los servicios principales.

4. Sistemas federados, cada región opera su propio cluster con réplica de datos parcial. No sirve de mucho en los conciertos porque la mayoría de usuarios son de la misma región.

5. Enfoques de cola descentralizada, colas de mensajes por subsistema que regulan el flujo hacia servicios críticos. Actúan de buffer para proteger los servicios por el alto número de peticiones.

🎯 El Enfoque de Ticketmaster/Live Nation: Microservicios en la Nube y Capas de Caché

Ticketmaster y Live Nation utilizan una arquitectura de microservicios distribuida, predominantemente en AWS, orquestando sus servicios con Kubernetes (EKS). Complementan esto con múltiples capas de caché.

Piensa en ello como una gran ciudad preparada para un festival. Tienes diferentes distritos especializados (microservicios para autenticación, inventario, pagos). Las autopistas de entrada (API Gateways, Load Balancers) intentan distribuir el tráfico. Hay puestos de información rápida en las afueras (CDN como Fastly para contenido estático) y dentro de la ciudad (Varnish, ElastiCache para datos dinámicos de acceso frecuente).

El problema surge cuando todas los API Gateways y Load Balancers se colapsan simultáneamente y los microservicios clave, como el de venta de entradas en la base de datos, no dan abasto.

Tu backend es tan escalable como el microservicio que menor escala maneja.

🧩 Componentes Clave (y sus Puntos Débiles)

1. ☁️ Infraestructura Cloud y Orquestación (AWS EKS)

• ¿Para qué sirve? Proporcionar la base escalable para todos los servicios. Permite desplegar, gestionar y escalar aplicaciones en contenedores.

• Cómo funciona:

  1. Las aplicaciones se empaquetan en contenedores (Docker).

  2. Kubernetes (a través de Amazon EKS) orquesta estos contenedores, manejando el despliegue, el autoescalado (añadiendo o quitando réplicas de servicios según la carga) y la salud de los servicios.

  3. Servicios de AWS como EC2 (para los nodos de Kubernetes), API Gateway (para exponer APIs), Lambda (para funciones serverless), RDS (bases de datos relacionales), MSK (Kafka gestionado), SNS/SQS (para mensajería) son utilizados extensivamente.

• Tecnologías clave: AWS (EKS, EC2, S3, API Gateway, Lambda, RDS, MSK, SNS/SQS), Kubernetes, Docker.

A pesar del autoescalado, la velocidad y la magnitud del pico de Bad Bunny (o Taylor Swift) pueden superar la capacidad de reacción del sistema si no está pre-provisionado masivamente o si los límites de escalado no son suficientemente altos, especialmente para componentes con estado como las bases de datos.

Es por ello que hacer warmup de estos sisteams y escalarlos antes de que llegue la demanda es importnate.

2. 🌍 Gestión de Tráfico y Caché (Fastly CDN, Varnish)

• ¿Para qué sirve? Reducir la latencia entregando contenido desde ubicaciones cercanas al usuario y disminuir la carga en los servidores de origen.

• Cómo funciona:

  1. Fastly (CDN): Almacena contenido estático (imágenes, CSS, JavaScript) en servidores distribuidos globalmente (edge). Cuando un usuario pide este contenido, se sirve desde el nodo más cercano.

  2. Varnish Cache: Se sitúa delante de los servidores de origen. Cachea respuestas de peticiones dinámicas que son comunes o no cambian tan frecuentemente. El error "No healthy backends" indica que Varnish no encontraba servidores de origen funcionales a los que pasar la petición.

• Tecnologías clave: Fastly, Varnish.

Estas capas de caché son vitales, pero para operaciones de venta de entradas (ver disponibilidad, seleccionar asiento, comprar), muchas peticiones son inherentemente dinámicas y deben llegar al origen. Si el origen colapsa, el caché no puede hacer milagros para estas operaciones.

3. 🎟️ Sistema de Cola Virtual y "Verified Fan"

• ¿Para qué sirve? Intentar gestionar el flujo masivo de usuarios hacia el sistema de compra y filtrar bots.

• Cómo funciona:

  1. Verified Fan: Los usuarios se registran con antelación. Ticketmaster selecciona un subconjunto y les envía códigos de acceso únicos para la preventa. La idea es reducir la competencia con bots.

  2. Sala de Espera Virtual: Unos minutos antes de la venta, los usuarios entran a una sala.

  3. Cola Virtual: Al comenzar la venta, se asigna un puesto en la cola. Una vez dentro, pueden seleccionar entradas.

• Tecnologías clave: Lógica de aplicación customizada, posiblemente usando servicios de colas de AWS (SQS) o Kafka internamente para gestionar el flujo de usuarios admitidos.

En la práctica, durante el evento de Bad Bunny y Taylor Swift, el sistema de Verified Fan fue insuficiente; millones de usuarios (con y sin código) y bots intentaron acceder.

Las colas virtuales se saturaron, y el propio sistema de colas se convirtió en un cuello de botella o falló, expulsando usuarios o mostrando tiempos de espera irreales.

4. 🗄️ Bases de Datos y Gestión de Inventario (RDS, ElastiCache, MongoDB)

• ¿Para qué sirve? Almacenar de forma persistente la información de usuarios, el inventario de entradas (qué asientos están disponibles, reservados, vendidos) y procesar las transacciones de compra.

• Cómo funciona:

  1. Bases de Datos Relacionales (MySQL/Oracle, vía Amazon RDS): Se usan para datos transaccionales críticos, como la venta de entradas, debido a sus propiedades ACID que garantizan la consistencia. Aquí es donde ocurren los bloqueos para asegurar que una entrada no se venda dos veces.

  2. MongoDB: Utilizado para datos no transaccionales o menos críticos que requieren más flexibilidad.

  3. Amazon ElastiCache (Redis/Memcached): Se usa como una capa de caché en memoria para acelerar el acceso a datos frecuentemente leídos (ej: disponibilidad general de secciones, no el asiento específico).

• Tecnologías clave: Amazon RDS (MySQL, Oracle), MongoDB, Amazon ElastiCache.

El mayor cuello de botella aquí es la escritura concurrente en la base de datos relacional para el inventario. Cada intento de seleccionar o comprar un asiento implica una transacción. Con cientos de miles de personas intentándolo a la vez, la base de datos se satura de peticiones de escritura y bloqueos, ralentizando todo el proceso. Este es un desafío clásico en sistemas de alta concurrencia.

Pero claro, todo es un tradeoff. De cara al usuario, es mejor que hayan tiempos de espera altos a que varios usuarios compren entrada para el mismo asiento.

5. 💸 Integración con Pasarelas de Pago y Dependencias Externas

• ¿Para qué sirve? Procesar los pagos de las entradas.

• Cómo funciona:

  1. Una vez que el usuario selecciona las entradas y va a pagar, el sistema de Ticketmaster se comunica con servicios de terceros (pasarelas de pago como PayPal, Stripe, o sistemas bancarios locales).

  2. Estos servicios externos procesan la transacción y devuelven una confirmación o un error.

• Tecnologías clave: APIs de pasarelas de pago (PayPal, Stripe, RedSys en España, etc.).

Si estas pasarelas de pago externas se ven también sobrecargadas por el volumen de peticiones provenientes de Ticketmaster (y posiblemente de otros comercios sufriendo picos), pueden empezar a fallar o a responder lentamente. Esto provoca errores en el checkout, y los usuarios vuelven a intentarlo, añadiendo más carga.

✨ Lecciones Aprendidas del colapso de TicketMaster

En resumen:

• La demanda desbordó la capacidad: Más de un millón de usuarios concurrentes para Bad Bunny en España fue simplemente demasiado.

• Efecto dominó: Fallos en un componente (ej: base de datos de inventario) pueden tumbar otros servicios dependientes.

• Los bots no ayudaron: A pesar de Verified Fan, el tráfico de bots infló artificialmente la carga, comportándose como un ataque DDoS.

• El "retry storm": La incapacidad de rechazar peticiones excedentes o fallar rápido llevó a que los usuarios (y bots) bombardearan los servidores hasta el colapso.

• Escrituras en BBDD, el gran cuello de botella: La naturaleza transaccional de la venta de entradas es difícil de escalar para escrituras masivas.

• Caché con límites: Varnish y Fastly ayudaron, pero no pudieron evitar que las peticiones dinámicas esenciales saturaran los backends ("No healthy backends").

• Throttling insuficiente: Faltaron mecanismos más agresivos para limitar la cantidad de peticiones que llegaban al núcleo del sistema.

• Dependencias de terceros: Las pasarelas de pago pueden ser otro punto de fallo bajo carga extrema.

• Comunicación crucial: La falta de información clara durante el caos aumenta la frustración.

Como conclusión, hay desafíos que son inherentes del problema a resolver. Si 1 millón de personas quieren el mismo asiento, da igual que la venta de entradas sea en físico o de manera online: Es un caos.

Diseñar sistemas escalables no trata solo sobre la tecnología a utilizar, sino las features de la aplicación. Quizás el problema no es solo la sobrecarga de algunos servicios, sino la manera de vender entradas online en un día y hora concretos que genere esos picos de tráfico

👋 PS – ¿Quieres dominar el system design y entender cómo se construyen (y a veces se rompen) los sistemas a gran escala?

📚 Referencias:

1. Ticketmaster System Architecture and Design insights:

   • AWS Case Studies (genérico sobre migraciones a la nube): aws.amazon.com (Buscar casos de Ticketmaster o Live Nation si existen públicos)

   • Fastly Customer Story (sobre migración a su CDN): fastly.com

   • SlideShare presentations on Ticketmaster's architecture (buscar por "Ticketmaster architecture"): slideshare.net

2. Informes de las caídas (Bad Bunny en España):

   • El Confidencial: "El aviso de Varnish que detecta por qué se cayó Ticketmaster..." elconfidencial.com (Buscar el artículo específico)

   • 20 Minutos: "Caos en la preventa de Bad Bunny..." 20minutos.es (Buscar el artículo específico)

3. Análisis Post-Mortem (Taylor Swift y otros):

   • Ticketmaster Blog/Business Page (para declaraciones oficiales sobre el caso Swift): business.ticketmaster.com, blog.ticketmaster.com

   • LearningDaily.dev (análisis técnicos de la caída de Swift): learningdaily.dev (Buscar "Ticketmaster Swift")

   • RunSignup Blog (comparativas de carga en eventos): info.runsignup.com

📝 Otros artículos de interés

👏 Aplauso semanal

Aquí algunos artículos que me han gustado esta última semana:

• DeepWiki: ¿La nueva aliada para entender repositorios complejos? por . Una herramienta de IA que genera documentación interactiva a partir de repositorios de GitHub para facilitar su comprensión.

• Una nueva era de automatización por . La evolución de la automatización a través de una pirámide de 4 niveles, desde las reglas fijas tradicionales hasta los agentes de IA autónomos.

• Cómo envían emails los CEOs por . Analiza el estilo de comunicación por email de CEOs tecnológicos como Jeff Bezos o Steve Jobs, extrayendo lecciones sobre inmediatez, humildad y transparencia.

• El tróspido futuro de Web Reactiva por . Reflexiona sobre el futuro de su proyecto, compartiendo sus cifras, motivaciones y planes de cambio, como enfocarse más en el análisis de contenido y la creación de proyectos prácticos.

• Las 5 cosas que separan al freelance que vive bien del que sobrevive por Jorge . Resume los 5 principios clave que generan el 80% de los resultados para tener éxito como freelance, empezando por resolver un problema específico para un público concreto.

🙏 Una última cosa antes de que te vayas:

Siempre estoy trabajando para hacer esta newsletter aún mejor.

¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?

👉 Responde la encuesta aquí

Nos vemos en el próximo correo,

Fran.

Aquí tu dosis semanal de system design y arquitectura de software.

Imagina esto: es viernes por la noche. Millones de personas en todo el planeta se relajan, eligen su próxima serie o película en Netflix y presionan "Play". Esperan una experiencia perfecta, una transmisión fluida sin interrupciones.

Lo que no saben es la cantidad de sistemas que actúan detrás de esa interfaz familiar.

Con más de 260 millones de suscriptores globales y miles de millones de horas transmitidas mensualmente, la escala de Netflix es, sencillamente, colosal. Pero el verdadero desafío no es solo el volumen diario constante.

Es lo inesperado.

Un despliegue de software que sale mal. Un evento externo como el final de un partido de fútbol o el estreno mundial de una serie como "El Juego del Calamar".

De repente, en cuestión de minutos, ¡a veces segundos!, el tráfico dirigido a ciertas partes de la infraestructura de Netflix puede multiplicarse por dos (en un failover) o incluso por cien (al restaurar una región). Una auténtica avalancha digital.

Para los ingenieros de Netflix, esto no es una hipótesis, es una realidad operativa.

El reto no es solo cuestión de números, sino de experiencia de usuario: ¿Cómo absorbes picos de carga tan masivos y repentinos sin que ni uno de esos millones de usuarios note la más mínima degradación en su maratón de fin de semana?

Mantener la promesa de una experiencia impecable frente a esta volatilidad extrema requirió que Netflix fuera más allá de las prácticas estándar. Tuvieron que innovar y construir un sistema de resiliencia de clase mundial para domar estas tormentas de tráfico.

🌋 El Desafío: Picos Repentinos en un Mundo Distribuido

Netflix ya operaba sobre una base sólida: una vasta infraestructura activa-activa en AWS (principalmente en us-east-1, us-east-2, us-west-2, eu-west-1) y una compleja arquitectura de miles de microservicios desacoplados, a menudo gestionados por su plataforma de contenedores Titus. Esto les daba flexibilidad y escalabilidad, pero también presentaba problemas ante picos súbitos:

• Efecto cascada: Aunque los microservicios están desacoplados (muchos usan colas SQS/Kinesis), un pico de tráfico en una región o servicio podía amplificarse rápidamente al propagarse por la red de microservicios dependientes. Por eso es una buena práctica evitar retries fijos en tus llamadas entre servicios. En lugar de ello, utiliza algoritmos como token bucket

• Autoscaling tradicional lento: Escalar basado solo en métricas estándar como el uso de CPU (con métricas de CloudWatch de 1 minuto) era demasiado lento. La detección tardaba (~4 min) y el arranque de instancias (~6 min) llevaba a un Time-to-Recovery (TTR) de unos 20 minutos, inaceptable para picos rápidos. En un sistema como Netflix, esto es una eternidad

• Visibilidad limitada: Entender la capacidad real y los umbrales de fallo de cada microservicio bajo estrés extremo era complejo al no tneer métricas adecuadas y pruebas constantes.

Necesitaban una forma más rápida, inteligente y resistente de capear estas tormentas de tráfico

.

💡 La Transición: Hacia la Resiliencia Reactiva

Por eso, el equipo de ingeniería de Netflix se centró en mejorar drásticamente cómo anticipaban y reaccionaban a estos picos.

El objetivo: reducir el tiempo de recuperación y proteger la experiencia del usuario a toda costa.

Como detallaron en AWS re:Invent, desarrollaron un conjunto de estrategias específicas combinando planificación inteligente con reacciones ultrarrápidas.

Vamos a ello.

🗺️ Estrategias Generales para Gestionar la Carga

Antes de ver la solución específica de Netflix, recordemos algunos enfoques generales para manejar la carga en sistemas distribuidos:

• Escalado Proactivo (Predictive Scaling): Aumentar la capacidad antes de que llegue el pico esperado (ej. lanzamiento de una serie).

• Escalado Reactivo (Reactive Scaling): Aumentar la capacidad en respuesta a un aumento detectado en la carga.

• Limitación / Degradación Controlada (Load Shedding): Rechazar selectivamente peticiones menos críticas para proteger los servicios esenciales cuando el sistema está sobrecargado.

• Distribución de Carga (Traffic Shaping / Steering): Dirigir el tráfico geográficamente para balancear la carga entre diferentes centros de datos o regiones.

▶️ El Enfoque Concreto de Netflix: Una Combinación Inteligente

Netflix no se decanta por una única solución, sino que utiliza una combinación de todas estas estrategias, orquestadas sobre su infraestructura cloud activa-activa en AWS.

Piensa en ello como un sistema de gestión de emergencias urbanas: tienen predicciones de tráfico (prescaling), desvíos planificados (traffic shaping), pero también equipos de respuesta ultrarápida (autoscaling por RPS - Requests Per Second) y protocolos para priorizar vehículos de emergencia (load shedding) cuando ocurre un accidente imprevisto.

🔩 Deep Dive por Componentes Clave

Cuando el pico es inesperado, estas piezas entran en juego:

#1 ☁️ Infraestructura Multi-Región en AWS

• ¿Para qué sirve? Proporciona la base de escalabilidad global, redundancia y distribución geográfica de la carga.

• Cómo funciona:

  1. Netflix despliega sus servicios en múltiples regiones de AWS (como us-east-1, us-west-2, eu-west-1).

  2. El tráfico de los usuarios se dirige a la región más cercana o más saludable a través de servidores DNS inteligentes.

  3. Si una región falla o se sobrecarga, el tráfico puede ser desviado a otras regiones "salvadoras" (failover). Ten en cuenta que esto puede ser un pico de carga hasta 2x para la nueva región.

• Tecnologías clave: AWS (EC2, VPC, ELB/ALB, ASG, S3), Titus (gestión de contenedores), DNS inteligente.

Piensa en esto como una cadena de supermercados que tiene varios en la misma ciudad. Las personas van al supermercado más cercano a su casa. Si uno de los supermercados tiene que cerrar de imprevisto o tiene largas colas, los clientes van a otro en la misma ciudad. En este caso, son las peticiones las que van a los centros de datos distribuidos geográficamente

#2 🌍 Open Connect (CDN Propia)

• ¿Para qué sirve? Acerca el contenido de vídeo (¡el 100%!) a los usuarios finales, reduciendo drásticamente la latencia y, absorbiendo gran parte de la carga de streaming antes de que llegue a los microservicios centrales.

• Cómo funciona:

  1. Netflix despliega miles de servidores llamados Open Connect Appliances (OCAs) dentro de las redes de los proveedores de internet (ISPs) y en puntos de intercambio de internet (IXPs).

  2. Predicen qué contenido será popular en cada zona y lo copian (cachean) en los OCAs locales durante las horas de baja demanda.

  3. Cuando un usuario reproduce un vídeo, se sirve desde el OCA más cercano, no desde los servidores centrales de Netflix.

• Tecnologías clave: Hardware/Software OCA custom, BGP, Zuul (Netflix Edge Gateway).

Imagínalo como tener quioscos en cada barrio con las revistas más vendidas ya impresas. La mayoría compra allí, evitando que la imprenta central se sature.

#3 🚀 Autoscaling Rápido Basado en RPS

• ¿Para qué sirve? Escalar la capacidad de los microservicios de forma casi instantánea cuando detecta un pico súbito de peticiones, superando la lentitud del escalado tradicional basado en CPU.

• Cómo funciona:

  1. Monitorizan las Requests Per Second (RPS) con alta resolución (métrica de 5 segundos de Atlas, su sistema interno, en lugar de 1 minuto que tenían anteriormente en AWS CloudWatch). En lugar de esperar a que la CPU se sature (lo cual ocurre tarde, durante el load shedding), escalan antes. Piensa que durante el load shedding, los servicios siguen reciviendo las peticiones y las descartan, por lo que no tienen un coste cero como si la petición nunca hubiera existido.

  2. Al detectar un pico rápido de RPS que supera un umbral, activan una política de escalado "Hammer". Esta política intenta añadir toda la capacidad necesaria de golpe ("one shot to success"), en lugar de añadir instancias poco a poco.

  3. Arranque Optimizado: Han optimizado el tiempo de arranque de instancias y aplicaciones (ej. arranque en paralelo), reduciendo el tiempo de boot de ~6 min a ~2 min. Resultado: El TTR para un pico >2x se reduce de ~20 min a ~3 minutos (~1 min detección + ~2 min boot).

• Tecnologías clave: Lógica de autoscaling personalizada, sistema de métricas interno (Atlas), AWS EC2 y Auto-Scaling Groups.

Seguro que has jugado alguna vez a videjuegos como Need For Speed. Imagínate que en lugar de acelerar gradualmente un coche e ir aumentando de marcha una a una, pisas a fondo un botón de "nitro" para alcanzar la velocidad necesaria instantáneamente, aunque consumas más combustible en ese momento.

#4 🚦 Microservice Buffers y Load Shedding Priorizado

• ¿Para qué sirve? Permitir que cada microservicio absorba picos moderados sin errores y, en casos extremos, degradar el servicio de forma controlada (load shedding) para proteger las funciones críticas y evitar el colapso total.

• Cómo funciona:

  1. Buffers de Capacidad: Cada servicio se ejecuta con margen. Tiene un "Success Buffer" (puede absorber picos razonables, ~2x, sin errores) y un "Failure Buffer" (puede absorber picos catastróficos antes de empezar a fallar o descartar peticiones).

  2. Clasificación de Criticidad: Peticiones y servicios se etiquetan por Tier/importancia.

  3. Shedding Priorizado: Si la carga supera el Success Buffer y amenaza el Failure Buffer, se empiezan a descartar peticiones de baja prioridad (tareas de fondo, API no esenciales). Si la presión continúa, se descartan peticiones más importantes, siempre intentando preservar el core (ej. reproducción).

  4. Retries Inteligentes: Usan backoff exponencial con full jitter específicamente en escenarios de shedding para evitar tormentas de reintentos.

• Tecnologías clave: Lógica de priorización en servicios, API Gateway (Zuul), configuración de umbrales, algoritmos de backoff/jitter.

Como los controladores aéreos en una tormenta: primero retrasan vuelos menos críticos, luego desvían algunos, pero hacen todo lo posible por mantener los aterrizajes y despegues esenciales seguros

#5 🏋️ Pruebas de Resiliencia Continuas (Chaos Engineering)

• ¿Para qué sirve? Validar proactivamente que todas estas estrategias funcionan juntas como se espera en producción o entornos idénticos, inyectando fallos y picos de carga controlados.* Cómo funciona:

  1. Usan su "Chaos Automation Platform" y una pirámide de pruebas:

     • Pruebas sintéticas a nivel de servicio: Hacen stress tests a servicios individuales aisladamente.

     • Pruebas de carga en producción: Inyectar carga controlada en el entorno real (load test).

     • Pruebas de escalado regional: Simular el escalado masivo de una región entera.

     • Pruebas de carga regional: Simular un pico de tráfico masivo dirigido a una sola región.

  2. Incluyen la simulación de failovers regionales como parte de las pruebas, ya que son una fuente real de picos.

• Tecnologías clave: Plataformas de Chaos Engineering, herramientas de inyección de carga, Chaos Monkey.

Son los simulacros de incendio, pruebas de estrés de puentes y crash tests de coches del mundo del software: pruebas destructivas para garantizar la seguridad y resistencia.

📝 Recapitulación de la Arquitectura de Resiliencia

En resumen, la estrategia de Netflix para domar los picos de tráfico se basa en:

• Base sólida: Infraestructura multi-región activa-activa en AWS y miles de microservicios desacoplados con buffers.

• Reducción de carga base: Open Connect CDN y caching multinivel absorben gran parte de la demanda.

• Anticipación Proactiva: Prescaling y Traffic Shaping para eventos conocidos o geográficamente localizados.

• Desubrieron que escalar por CPU no les servía: Aunque hagan load-shedding, la CPU no baja porque siguen llegando el mismo número de peticiones.

• Monitorización Clave: Métricas de RPS de alta resolución (Atlas, 5s) para detección temprana.

• Reacción Ultrar-rápida: Autoscaling "Hammer" basado en RPS para escalar masivamente en ~3 minutos.

• Protección bajo presión: Load shedding priorizado para descartar tráfico no esencial y proteger el core.

• Validación Constante: Pruebas de resiliencia rigurosas y Chaos Engineering.

👋 ¿Quieres Dominar el System Design?

Entender cómo empresas como Netflix construyen sistemas robustos a escala es vital para una entrevista de system design.

¡Hasta la próxima semana!

🗞️ Referencias:

1. Charla AWS re:Invent 2024: NFX301: How Netflix handles sudden load spikes in the cloud (Slides: https://reinvent.awsevents.com/content/dam/reinvent/2024/slides/nfx/NFX301_How-Netflix-handles-sudden-load-spikes-in-the-cloud.pdf, Vídeo)

2. Netflix en AWS: Casos de estudio e historias (https://aws.amazon.com/solutions/case-studies/innovators/netflix/)

3. Netflix Open Connect: Visión general (https://openconnect.netflix.com)

4. Estadísticas de Netflix: Search Logistics (https://www.searchlogistics.com/learn/statistics/netflix-statistics/)

5. Blog Post Análisis: How Netflix Handles Sudden Load Spikes in the Cloud? (What I Learned) - Ujjawal Poudel, Medium (https://medium.com/@ujjawalpoudel/how-netflix-handles-sudden-load-spikes-in-the-cloud-what-i-learned-f058a4d80af3)

📝 Otros artículos de interés

👏 Aplauso semanal

Aquí algunos artículos que me han gustado esta última semana:

• Carta para el síndrome del impostor de . Aprender a no arreglarlo todo y a 'soltar' es una habilidad crucial para los desarrolladores, más allá de la pura técnica.

• Skill Stacking para managers de . Ser 'moderadamente bueno' en varias habilidades complementarias y combinarlas crea un perfil profesional más único y valioso que la especialización extrema. Puedes crear una combinación única.

• De 25 minutos a 16 segundos: nueva capacidad de Docker Server en AWS CodeBuild de La nueva función Docker Server de AWS CodeBuild puede reducir drásticamente los tiempos de construcción de imágenes Docker, usando una caché de capas persistente y centralizada.

🙏 Una última cosa antes de que te vayas:

Siempre estoy trabajando para hacer esta newsletter aún mejor.

¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?

👉 Responde la encuesta aquí

Nos vemos en el próximo correo,

Fran.

En el mundo de la tecnología, quedarse quieto es retroceder.

Especialmente en arquitectura de software, donde las decisiones de hoy definen la agilidad, escalabilidad y resiliencia de nuestros sistemas mañana.

Estar al tanto de las tendencias no es solo postureo; es una necesidad estratégica para construir software robusto y preparado para el futuro.

Este artículo se basa en el reciente Radar Tecnológico de Thoughtworks (Vol. 32, Abril 2025) para darte una visión curada de lo que está en el horizonte.

⭐ Organizaremos las tendencias así:

• ✅ Adoptar: Tecnologías y técnicas maduras que deberías estar usando.

• 🧪 Probar: Innovaciones prometedoras que vale la pena experimentar en proyectos controlados.

• 🤔 Evaluar: Tendencias emergentes que hay que vigilar y entender.

• 🚫 Resistir: Prácticas o tecnologías con riesgos significativos o anti-patrones conocidos.

Aunque el radar original tiene muchos elementos, en este artículo nos centraremos en los más relevantes para la arquitectura y el diseño de nuestros sistemas.

✅ Qué Adoptar: Los Pilares Actuales

Estas son las prácticas y plataformas que ya han demostrado su valor y deberían ser parte de tu arsenal estándar.

1. Pensamiento de Producto de Datos (Data Product Thinking): Trata tus activos de datos como productos de primera clase, con un ciclo de vida definido, foco en el consumidor y metadatos claros (negocio y técnicos). Es clave para escalar iniciativas de IA y asegurar que los datos sean realmente útiles y gobernables, independientemente de si usas data mesh o lakehouse. Piénsalo como aplicar principios de product management a tus datos analíticos.

2. Software Bill of Materials (SBOM): Ya no es una novedad, sino una necesidad. Generar un SBOM (inventario detallado de componentes de software y sus dependencias) es fundamental para la seguridad de la cadena de suministro. Herramientas como Syft o Trivy lo facilitan, y es esencial tanto para software tradicional como para sistemas de IA. Integrarlo en tu CI/CD es ya una práctica por defecto.

3. Modelado de Amenazas (Threat Modeling): Con la IA generando más código y sistemas más complejos, identificar proactivamente las amenazas de seguridad desde el diseño es más crucial que nunca. No es una actividad puntual, sino un proceso continuo durante todo el ciclo de vida, integrado con otros escaneos y requisitos de seguridad. Ayuda a evitar el "security sandwich" (seguridad añadida al final, tarde y mal).

4. OpenTelemetry: Se consolida como el estándar de facto para la observabilidad (logs, métricas, trazas). Su protocolo OTLP permite crear sistemas de monitorización agnósticos del proveedor, facilitando la integración y evitando el vendor lock-in. Es la base para entender sistemas distribuidos complejos.

5. Trino: Un motor de consultas SQL distribuido y open source ideal para análisis interactivos sobre big data. Permite consultar datos donde residen (federación de consultas) sobre múltiples fuentes (bases de datos relacionales, data lakes con Iceberg/Parquet) como si fueran una sola. Es una pieza clave en arquitecturas analíticas modernas.

🧪 Qué Probar: Innovaciones con Potencial

Estas tendencias están madurando y ofrecen beneficios tangibles. Vale la pena probarlas en proyectos donde puedas gestionar el riesgo.

1. Architecture Advice Process: Una alternativa ágil a los comités de arquitectura tradicionales. Permite que cualquiera tome decisiones arquitectónicas, siempre que busque consejo de los afectados y expertos relevantes. Fomenta la autonomía y el flujo, apoyándose en prácticas como los Architecture Decision Records (ADRs). Funciona incluso en entornos regulados. Los suscriptores premium de la newsletter tienen acceso a una plantilla de ADRs aquí

2. GraphRAG: Una evolución del patrón RAG (Retrieval-Augmented Generation) para IA. Utiliza grafos de conocimiento (construidos a partir de documentos o código) para mejorar la recuperación de información relevante antes de generar una respuesta con un LLM. Mejora la precisión y el contexto, especialmente útil para entender sistemas complejos o bases de código legacy.

3. Dapr (Distributed Application Runtime): Un runtime portable y agnóstico del lenguaje que simplifica la construcción de microservicios resilientes y stateless/stateful. Ofrece bloques de construcción para capacidades comunes (pub/sub, gestión de estado, service discovery, etc.), permitiendo a los equipos centrarse en la lógica de negocio. Sigue evolucionando con foco en la seguridad y la observabilidad.

4. Module Federation: Clave para arquitecturas de micro frontends. Permite compartir módulos y dependencias entre diferentes aplicaciones frontend desplegadas de forma independiente. La versión 2.0 ya no depende exclusivamente de Webpack y soporta más frameworks y bundlers, facilitando la escalabilidad y el desarrollo independiente de equipos.

5. Gestión de Acceso Privilegiado Justo a Tiempo (JIT PAM): Un enfoque de seguridad que concede permisos elevados solo cuando son estrictamente necesarios y por un tiempo limitado, revocándolos automáticamente después. Mitiga drásticamente el riesgo asociado a credenciales privilegiadas permanentes (un vector de ataque común) y aplica el principio de mínimo privilegio de forma dinámica.

🤔 Qué Evaluar: El Futuro Emergente

Estas son las ideas y tecnologías más nuevas. Aún no están listas para adopción generalizada, pero es vital entenderlas porque podrían cambiar las reglas del juego.

1. Competence Envelope: Un concepto de la Teoría de la Extensibilidad Grácil para entender la resiliencia de los sistemas socio-técnicos. Define el límite dentro del cual un sistema puede operar robustamente ante perturbaciones. Ir más allá de este "sobre de competencia" lo vuelve frágil. Útil para analizar fallos sistémicos complejos y diseñar sistemas más antifrágiles (referencia al libro Antifrágil de Nassim Taleb).

2. Modelos de Razonamiento (Reasoning Models): Una nueva categoría de LLMs (e.g., OpenAI o1, DeepSeek R1) optimizados para tareas que requieren lógica compleja, matemáticas o planificación paso a paso. Superan a los LLMs generales en estos ámbitos, pero son más lentos y costosos ("Slower AI"). Evalúa dónde aportan valor real frente a modelos más convencionales. En mi opinión, esto no es el futuro sino el presente ahora mismo, con modelos como Gemini 2.5 o o3/o4 de openAI.

3. Restate: Una plataforma de ejecución duradera (similar a Temporal) para construir flujos de trabajo complejos, sagas, máquinas de estado y procesamiento de eventos con estado en sistemas distribuidos. Escrito en Rust, promete durabilidad y consistencia. Una opción a evaluar si las transacciones distribuidas son inevitables en tu contexto.

4. Plataformas/Extensiones de Búsqueda Vectorial: Con el auge de RAG y la IA, la capacidad de buscar eficientemente datos no estructurados mediante embeddings vectoriales es crucial. Están surgiendo plataformas serverless como turbopuffer o extensiones para bases de datos existentes como VectorChord/pgvector (PostgreSQL) que optimizan estas búsquedas. Son bloques fundamentales para muchas aplicaciones de IA.

   

5. Criptografía Postcuántica: La computación cuántica amenaza la criptografía asimétrica actual. Están surgiendo algoritmos resistentes (como los basados en retículos) y ya hay implementaciones disponibles (e.g., en Java JDK 24). Aunque los computadores cuánticos relevantes y de uso general están a años vista, es momento de evaluar esta tecnología para sistemas que necesiten seguridad a largo plazo o donde los datos cifrados hoy puedan ser robados para descifrarlos en el futuro.

🚫 Qué Evitar (Resistir): Red Flags

Ciertas prácticas o tecnologías conllevan riesgos inherentes o son consideradas anti-patrones. Procede con extrema precaución.

1. TI en la Sombra Acelerado por IA (AI-accelerated Shadow IT): La facilidad con la que herramientas no-code/low-code y asistentes de IA permiten crear soluciones fuera del control de TI está creando una nueva ola de shadow IT. Seguro que has vistos muchos posts de gente no técnica haciendo vibe-coding sin utilizar ni siquiera git... pues a eso se refiere shadow IT. Esto genera riesgos de seguridad, gobernanza de datos y mantenibilidad a largo plazo. Es crucial establecer políticas claras y evaluar los trade-offs.

2. Complacencia con Código Generado por IA: Los asistentes de IA son útiles, pero confiar ciegamente en el código que generan sin una revisión crítica y rigurosa es peligroso. Estudios muestran aumentos en código duplicado y disminución de refactorización. La calidad, el diseño y la mantenibilidad siguen siendo responsabilidad humana.

3. Reverse ETL: Mover datos desde un sistema analítico centralizado (como un data warehouse) de vuelta a sistemas transaccionales puede tener sentido en casos muy específicos (ej. Migraciones). Sin embargo, se está usando como excusa para centralizar cada vez más lógica de negocio en plataformas de datos, aumentando los problemas de las arquitecturas centralizadas. Mucho cuidado con estos flujos inversos.

4. SAFe™ (Scaled Agile Framework®): A pesar de su adopción, se sigue observando que sus procesos prescriptivos, jerárquicos y basados en fases generan fricción, silos y limitan la agilidad real, la autonomía de los equipos y la entrega de valor continua. Suele ser un intento de atajo que no resuelve la complejidad de transformar una organización.

5. Sobrecarga de Node (Node Overload): Aunque Node.js es eficiente para ciertas cargas de trabajo I/O intensivas, sigue siendo inadecuado para tareas CPU-bound o de uso intensivo de datos. Usarlo para todo ("porque usamos JavaScript en el frontend") a menudo ignora alternativas más robustas y performantes en otros lenguajes/plataformas para el backend. Defendemos la programación políglota cuando tiene sentido.

🧭 Conclusión y Recomendaciones

Navegar por este mar de tendencias requiere equilibrio. No se trata de adoptar cada nueva tecnología brillante, sino de tomar decisiones informadas que aporten valor real.

• ¿Cuándo adoptar algo nuevo vs. consolidar lo existente? Prioriza la estabilidad para el core de tu negocio. Introduce novedades de forma controlada, empezando por el anillo de Evaluar y Probar en proyectos no críticos o pilotos. Mide el impacto real antes de escalar.

• ¿Está tu equipo preparado? La adopción tecnológica no es solo técnica; es cultural y de habilidades. Evalúa la curva de aprendizaje, la madurez de la comunidad, el soporte y si la nueva tendencia encaja con las capacidades y la mentalidad de tu equipo.

• Una Matriz de Decisión Simple: Para guiarte, piensa en factores respecto al riesgo técnico, impacto y coste de adopción.
  Los suscriptores premium, tienen una plantilla aquí

Elige tecnologías que ofrezcan un alto valor, con un nivel de madurez/riesgo que puedas gestionar y que tu equipo pueda razonablemente asimilar.

👋 PD – ¿Quieres dominar el System Design y estar siempre al día?

Espero que este resumen te sea útil. ¡Hasta la próxima!

🗞️ Referencias

1. Fuente Principal: Thoughtworks Technology Radar, Vol. 32, Abril 2025.

   1. Inside the technology radar

2. Documentación Oficial de tecnologías: OpenTelemetry, Trino, Dapr, Module Federation (Concepto Webpack), pgvector, Scaled Agile Framework (SAFe™)

3. Architecture Advice Process

4. GraphRAG

5. Just-in-Time Privileged Access Management

6. Competence Envelope / Graceful Extensibility

7. Criptografía Postcuántica en Java

8. Cuándo NO usar Node.js (Node Overload)

📝 Otros artículos de interés

Soy Fran, un ingeniero de software en Amazon con más de 17.000 lectores en mi newsletter en inglés (strategizeyourcareer.com). He decidido empezar esta newsletter en español y me encantaría contar con tu apoyo.

Este post resume la arquitectura detrás de los sistemas de recomendación de Instagram, explicando cómo deciden qué mostrarte en el Feed, Explorar o Sugerencias. Al final encontrarás referencias para profundizar si te pica la curiosidad.

🤔 El Problema de Instagram

Había una vez una app de fotos llamada Instagram.

Al principio, todo era más sencillo.

Seguías a gente, veías sus fotos en orden cronológico y listo.

Pero la cosa creció. Y mucho.

Hoy, Instagram tiene más de 2 mil millones de usuarios activos al mes y cada día se suben millones y millones de fotos y vídeos nuevos.

Imagina intentar ver todo eso en orden.

Imposible, ¿verdad? Te perderías lo de tus amigos entre un mar de contenido y la experiencia sería caótica.

El reto era claro: ¿cómo mostrar a cada persona, entre ese océano de información, justo lo que le podría interesar para que siga enganchada?

🧗 Lo difícil: Un océano de contenido y la necesidad de relevancia

El simple orden cronológico dejó de funcionar muy pronto. Los problemas eran evidentes:

• Volumen Inabarcable: Demasiado contenido nuevo cada segundo. Era imposible para un usuario verlo todo, ni siquiera una pequeña fracción relevante.

• Relevancia Perdida: El contenido más interesante para ti (quizás de tus amigos cercanos o creadores favoritos) se perdía entre publicaciones menos importantes.

• Experiencia Pobre: Los usuarios se frustraban al no encontrar fácilmente lo que les gustaba, disminuyendo el tiempo en la app y la satisfacción general.

Necesitaban una forma inteligente de filtrar y ordenar ese caos.

💡 Transición a la Nueva Propuesta

Por eso, Instagram invirtió masivamente en crear sofisticados sistemas de recomendación.

El objetivo no era solo ordenar, sino conectar a cada usuario con contenido nuevo y relevante de forma personalizada.

Estos sistemas son el motor que impulsa la experiencia en el Feed, la pestaña Explorar, los Reels y las Sugerencias.

🏗️ El Patrón: La Arquitectura de Dos Etapas

Antes de meternos en cada sección de Instagram, hay un principio arquitectónico común que usan muchos sistemas de recomendación a gran escala, incluido Instagram: la arquitectura de dos etapas. Es una forma inteligente de manejar millones de opciones sin morir en el intento.

• 1ª Etapa: Generación de Candidatos (Recall): Como lanzar una red de pesca muy amplia. El sistema busca rápidamente en todo el contenido de Instagram y selecciona un grupo grande (cientos o miles) de publicaciones o cuentas que podrían ser interesantes para ti. La prioridad aquí es no dejarse nada relevante fuera.

• 2ª Etapa: Selección/Ranking de Candidatos (Precision): Ahora, con una lista más manejable, entra en juego un análisis más fino. El sistema usa modelos más complejos para evaluar y ordenar esos candidatos, eligiendo los "mejores" (unas pocas docenas) para mostrártelos en el orden más adecuado. Aquí la prioridad es acertar al máximo.

🏮 La Elección del Enfoque Concreto

Instagram usa esta arquitectura de dos etapas porque es extremadamente eficiente para manejar su escala masiva. Hacer ranking de todo el contenido para cada usuario en tiempo real sería computacionalmente inviable.

Piensa en ello como un bibliotecario experto: primero va a las secciones generales donde podría estar lo que buscas (Generación de Candidatos) y luego revisa cuidadosamente los libros de esas estanterías para darte los más adecuados (Ranking)

🔎 Deep Dive por Componentes

Instagram tiene varias features de recomendación, cada una con sus matices.

Veamos las principales:

🏠 Publicaciones Sugeridas (Suggested Posts)

• ¿Para qué sirve? Para ofrecerte contenido nuevo al final de tu Feed principal, cuando ya has visto lo de la gente que sigues. El objetivo es que se sienta como una extensión natural de tu feed ("Feels Like Home"), ayudándote a descubrir gradualmente nuevos creadores alineados con tus intereses.

• Cómo funciona (paso a paso):

  

  1. Generación de Candidatos:

     • Identifica "semillas": cuentas o posts con los que has interactuado (likes, follows).

     • Usa Embeddings de Cuentas: Representaciones vectoriales que agrupan cuentas similares. Si te gusta una cuenta de cocina vegana, busca otras cuentas cercanas en ese "espacio vectorial" de intereses.

     • Usa Similitud por Co-ocurrencia: Si muchos usuarios que interactúan con el post A también lo hacen con el post B, ambos posts se consideran relacionados.

     • Utiliza Grafos de Interés y Exploración de Grafos (Fallback): Para usuarios con poca actividad, explora las interacciones de segundo grado (ej: cuentas seguidas por las cuentas que te gustan) o muestra contenido popular general.

     • Utiliza IGQL (Instagram Query Language): Un lenguaje interno para prototipar rápidamente estas consultas de búsqueda de candidatos.

  2. Ranking de Candidatos:

     • Calcula un "Valor de Usuario" para cada post candidato usando un modelo que pondera la probabilidad de acciones positivas (like, comentario, guardado) y negativas ("no me interesa").

     • Emplea modelos de Machine Learning, como MTML (Multi Task Multi Label Sparse Neural Nets) y GBDT (Gradient Boosted Decision Trees), LambdaRank, que consideran cientos de características: engagement previo, relación autor-espectador, popularidad del contenido, calidad visual, temas (detectados por IA), embeddings, etc.

     • Aplica heurísticas para que "se sienta como en casa": prioriza fuentes similares a tu feed, mantiene una mezcla de tipos de contenido (foto/vídeo) parecida y considera la frescura.

• Diagrama Mental: Imagina a un amigo muy atento que te recomienda nuevas cantantes y grupos basándose exactamente en las que ya escuchas y le has dicho que te gustan.

🧭 Explore (Pestaña Explorar)

• ¿Para qué sirve? Es la principal ventana de Instagram al descubrimiento. Su objetivo es sorprenderte con contenido variado y relevante de cuentas que no sigues, fomentando la exploración y el hallazgo casual (serendipia).

• Cómo funciona (paso a paso) - Un embudo de múltiples etapas:

  

  1. Retrieval (Recuperación): Se generan miles de candidatos iniciales desde múltiples fuentes: contenido popular/tendencia (heurísticas), recomendaciones basadas en ML (ej: Two-Tower NN), interacciones recientes (tiempo real) y contenido popular local precalculado.

  2. 1er Ranking (Ligero): Un modelo más rápido (a menudo Two-Tower Neural Network) reduce los miles de candidatos a los ~100 más prometedores. Este modelo separa el procesamiento del usuario y del ítem, permitiendo cachear embeddings y buscar eficientemente con ANN (Approximate Nearest Neighbors).

  3. 2º Ranking (Pesado): Un modelo más complejo y preciso (como MTML - Multi-Task Multi-Label) evalúa esos ~100 candidatos. Predice la probabilidad de múltiples interacciones (clic, like, guardar) usando características más ricas de interacción usuario-ítem. Luego, un "modelo de valor" combina estas probabilidades para obtener un score final.

  4. Re-Ranking Final: Se aplican reglas de negocio: filtrar contenido potencialmente dañino, asegurar diversidad (ej: no mostrar varios posts seguidos del mismo autor), etc.

• Costes / Rendimiento / Escalabilidad: La escala es una brutalidad. El sistema de IA de Explorar extrae 65 mil millones de features y realiza 90 millones de predicciones de modelo por segundo.

• Diagrama Mental: Piensa en un curador de museo muy inteligente. Conoce tus gustos generales (por visitas previas) y te lleva por salas nuevas (Explorar), mostrándote piezas (posts) que cree que te fascinarán, aunque nunca hayas oído hablar del artista (cuenta).

➕ Otros Sistemas (Feed Principal y Reels)

• Feed Principal "para ti": Aunque principalmente muestra contenido de cuentas que sigues, no es estrictamente cronológico. Un algoritmo de ranking similar (considerando engagement, relevancia, frescura) ordena las publicaciones para mostrarte primero lo que cree que más te importa.

• Reels: Tiene su propio sistema de recomendación optimizado para vídeo corto. Analiza qué vídeos ves completos, con qué interactúas (likes, comentarios), el audio usado, efectos visuales, etc., para ofrecer un flujo continuo de vídeos entretenidos.

  

🎯 Conclusión

En resumen, los sistemas de recomendación de Instagram son:

• Imprescindibles por la Escala: Necesarios para manejar miles de millones de usuarios y contenido.

• Basados en Dos Etapas (Generalmente): Un primer filtro amplio (Generación de Candidatos) seguido de uno preciso (Ranking).

• Adaptados al Contexto: Sistemas distintos (Feed, Explorar, Sugerencias, Reels) con objetivos diferentes (mantenerte conectado vs. descubrir).

• Impulsados por IA/ML: Usan embeddings, redes neuronales (Two-Tower, MTML) y muchísimas features para entender usuarios y contenido.

• Optimizados Constantemente: Se ajustan parámetros y modelos continuamente mediante A/B testing y optimización (ej: Bayesiana).

👋 PD – ¿Quieres dominar el System Design y la Arquitectura de Software como los cracks de Instagram?

🗞️ Referencias

Aquí tienes algunos artículos si quieres profundizar en cómo funcionan los sistemas de recomendación de Instagram:

1. Designing a Constrained Exploration System (Blog oficial de Instagram): Explica en detalle el sistema de "Suggested Posts" y el principio "Feels Like Home". https://about.instagram.com/blog/engineering/designing-a-constrained-exploration-system

2. Scaling the Instagram Explore recommendations system (Blog oficial de Meta Engineering): Describe la arquitectura multi-etapa y las técnicas de escalado usadas en la pestaña Explorar. https://engineering.fb.com/2023/08/09/ml-applications/scaling-instagram-explore-recommendations-system/

3. Powered by AI: Instagram's Explore recommender system (Blog oficial de Meta AI): Se centra en los modelos de IA (como Two-Tower y MTML) que potencian Explorar. https://ai.meta.com/blog/powered-by-ai-instagrams-explore-recommender-system/

4. How Instagram suggests new content (Blog oficial de Meta Engineering): Ofrece una visión general de cómo Instagram aborda la sugerencia de contenido nuevo. https://engineering.fb.com/2020/12/10/web/how-instagram-suggests-new-content/

📝 Otros artículos de interés

Siempre estoy buscando formas de hacer que esta newsletter sea más útil para ti.

¿Te tomas 1 minuto para responder esta encuesta rápida y anónima?

👉 Responde aquí

Nos vemos en el siguiente artículo,

Fran.