Breakscale es un simulador de diseño de sistemas de código abierto, con licencia MIT, que permite armar arquitecturas con 33 componentes, subir el tráfico hasta que algo falle y observar la caída con datos medidos por una simulación de eventos discretos. Funciona en el navegador, dentro de VS Code y como servidor MCP para asistentes de IA, sin cuentas y sin instalar nada.

La mayoría del material sobre diseño de sistemas se queda en diagramas estáticos y reglas generales: agrega una caché, usa una cola, pon un balanceador. Lo que casi nunca se enseña es por qué la latencia p99 se desploma cuando la utilización pasa del 80 por ciento, o cómo un tiempo de espera corto con un par de reintentos convierte una base de datos lenta en una caída total. Breakscale, publicado en GitHub por el equipo de Workers, existe precisamente para ejecutar ese experimento en lugar de describirlo.

¿Qué es Breakscale y qué lo distingue de un diagrama animado?

Breakscale es un lienzo donde se colocan balanceadores de carga, cachés, bases de datos, colas y otros 29 componentes más, se cablean entre sí y se arrastra el tráfico hacia arriba hasta que algo se rompe. Lo que ocurre en pantalla no es una animación decorativa: es un motor de simulación de eventos discretos donde las solicitudes son objetos reales que atraviesan la topología. Los percentiles de latencia suben, las colas se llenan, los circuit breakers se activan y el sistema entero puede colapsar en una tormenta de reintentos, todo medido a partir de solicitudes simuladas individuales y no dibujado para verse creíble.

El proyecto es explícito sobre su filosofía de veracidad: la versión corta de su barra de contribución es que los números tienen que ser verdaderos, porque la gente aprende con esta herramienta y un número de apariencia plausible es peor que ningún número. Esa postura se nota en detalles técnicos que otros simuladores evitan, como veremos más adelante.

¿Cómo funciona el motor de simulación por dentro?

El motor, ubicado en el directorio src/sim, se apoya en cuatro detalles que hacen que sus resultados merezcan confianza. Primero, los slots de servidor finitos: la capacidad de un componente define cuántas solicitudes puede atender a la vez, y todo lo que exceda esa capacidad espera en una cola FIFO real, mientras que lo que exceda el límite de la cola se descarta. Segundo, la varianza del tiempo de servicio se muestrea de una distribución gamma, porque la varianza es justo lo que aleja la latencia de cola del promedio.

Tercero, el trabajo abandonado sigue consumiendo capacidad: cuando un cliente se rinde por tiempo de espera, el servicio de aguas abajo termina procesando una solicitud que ya nadie espera, y ese es el mecanismo que hace que las tormentas de reintentos se puedan observar y no solo leer. Cuarto, los percentiles p50, p95 y p99 se miden desde un buffer circular de latencias completadas, nunca multiplicando un promedio por una constante. Las corridas son deterministas: la misma semilla y la misma topología se reproducen de forma idéntica, y la suite de pruebas verifica que las solicitudes se conserven, que la utilización se mantenga en rango y que ningún campo del snapshot sea un valor inválido.

¿Cuánto cuesta de verdad una tormenta de reintentos?

El ejemplo estrella del proyecto pone cifras concretas a un fenómeno que suele contarse de oídas. En el escenario Retry Storm con 100 solicitudes por segundo ofrecidas, la base de datos llega al 99.9 por ciento de ocupación y el rendimiento útil cae a cero, porque los reintentos convirtieron esas 100 solicitudes en 348 que golpean una base de datos que ya estaba saturada. Cada respuesta que la base termina ya fue abandonada por un cliente que dejó de esperar: el sistema trabaja a máxima potencia para producir resultados que nadie recibe.

Vale la pena señalar que este tipo de lección solo se aprende bien viéndola colapsar en vivo. La tabla de ejemplos incluidos cubre modos de falla aislados, cada uno con su enseñanza específica:

Además de esos nueve escenarios de enseñanza, el proyecto incluye reconstrucciones de arquitecturas reales de Netflix, Spotify, Discord, Uber, Twitter/X, Stripe y WhatsApp, elaboradas a partir de material de ingeniería publicado. Cada una declara qué modela y qué deja fuera: son diagramas didácticos, no conocimiento interno de esas empresas.

¿De qué formas se puede usar sin instalar nada?

La vía más directa es el navegador: se abre el sitio oficial en breakscale.tech, se elige un ejemplo del panel izquierdo y se sube el control de tráfico hasta que algo se pinta de rojo. No hay cuenta que crear, y un diseño permanece en el navegador a menos que se comparta. Cuando se comparte, el diseño se cifra antes de salir, con la llave guardada en la parte del enlace que los navegadores nunca envían a un servidor, de modo que ni el servicio puede leerlo.

La segunda vía es VS Code: la extensión se instala desde el Marketplace y abre el simulador completo en un panel junto al código, con el mismo motor y los mismos ejemplos del sitio, funcionando sin conexión. Los diseños guardados ahí viven en el almacenamiento propio del editor, y un enlace compartido o un archivo .breakscale permiten mover un diseño entre el editor y la web.

¿Cómo trabaja Breakscale junto a un agente de IA?

La tercera vía es la más interesante para el momento técnico actual: Breakscale también es un servidor MCP, de modo que asistentes como Claude, Copilot, Cursor o Codex pueden usarlo en nombre del usuario. Se apunta el asistente a un repositorio y se le pide convertir la arquitectura en un diseño, o simplemente se describe un sistema, y el agente construye el diseño, lo ejecuta con el mismo motor y regresa con números medidos y un enlace que lo abre en el sitio. El servidor está alojado en la URL pública del proyecto y no requiere instalación; quien prefiera ejecutarlo localmente puede arrancarlo con npx breakscale-mcp –stdio usando Node 20.

Este enfoque conecta con una tendencia que ya veníamos siguiendo en la cobertura de herramientas para agentes de desarrollo, como Pullboard y su fábrica de software con agentes IA que verifica cada cambio, donde el valor no está en que el agente escriba más rápido sino en que las decisiones técnicas queden respaldadas por verificación automática. En clientes que soportan MCP Apps, como claude.ai, VS Code y Cursor, el diseño además se abre como un lienzo vivo dentro del chat, y cualquier cambio hecho ahí regresa al asistente para que su siguiente edición parta de lo que el usuario está viendo.

¿Qué tan completo es el catálogo de componentes y controles?

El proyecto declara 33 componentes, entre ellos CDN, limitadores de tasa, circuit breakers, réplicas de lectura, shards, autoscalers, brokers de flujos, gateways WebSocket, funciones serverless y bulkheads, además de los clásicos balanceadores, cachés, bases de datos, colas y workers. Los controles de caos permiten tirar un nodo, ralentizarlo, forzar una tasa de error o cortar un enlace específico, y observar cómo la falla se propaga por el sistema. Cada métrica y cada unidad traen una definición en lenguaje sencillo a un hover de distancia, lo que baja la barrera para quien apenas empieza con estos conceptos.

Para quien quiera profundizar en el lado de los agentes que consumen este tipo de servidores, la cobertura de Mercury Agent, el agente de IA open source que vive en tu computadora muestra el otro extremo del ecosistema: un asistente permanente con permisos configurables, mientras que aquí el agente es una herramienta puntual de análisis de arquitectura. Ambos casos ilustran el mismo patrón de fondo, que es delegar trabajo técnico medible a procesos auditables.

¿Cómo ejecutarlo en tu propia máquina?

El desarrollo local requiere Bun, el runtime con el que está construido el proyecto. Los pasos son directos: clonar el repositorio, instalar dependencias y levantar el servidor de desarrollo, que sirve la interfaz en el puerto 5173. La estructura interna es limpia y está pensada para ser legible:

• src/sim: el motor de simulación, sin React, sin DOM y sin I/O
• src/components: lienzo, inspector, métricas y paleta
• src/content: texto del glosario
• extension: la extensión de VS Code
• mcp: el servidor MCP
• worker: el Worker de Cloudflare detrás de los enlaces compartidos

Como el motor no depende de la interfaz, también se puede manejar desde un script: se instancia el motor con una topología y una semilla, se avanza en pasos de tiempo y se lee el snapshot del sistema. El proyecto está escrito con React, TypeScript y Vite, el lienzo es SVG hecho a mano y las gráficas se dibujan directamente en lugar de usar una biblioteca de charts, lo que mantiene el bundle pequeño y el renderizado predecible.

¿Qué limitaciones conviene tener en cuenta?

Es importante reconocer el alcance del modelo: las reconstrucciones de Netflix, Spotify o WhatsApp son material de enseñanza construido con información pública, no conocimiento de adentro de esas compañías, y el proyecto lo declara sin rodeos. La simulación modela servicios con tiempos gamma y colas finitas, no latencias de red reales ni costos de infraestructura, así que sirve para construir intuición sobre saturación, reintentos y backpressure, no para dimensionar una factura de nube. Para un desarrollador que apenas arma su primer sistema con cola y caché, esa limitación es menor frente al beneficio de ver el colapso con números reales en lugar de memorizar reglas.

El proyecto se suma a una ola de herramientas gratuitas publicadas en GitHub que compiten cabeza a cabeza con software de pago o llenan huecos que nadie había cubierto, un fenómeno que documentamos de forma amplia en la revisión de nueve alternativas open source que reemplazan software de pago. En ese panorama, Breakscale no sustituye a nadie: crea una categoría propia, la de los simuladores de diseño de sistemas con números medidos, y la ocupa con una propuesta seria sobre la honestidad de sus cifras.

El veredicto es sencillo de formular. Para estudiantes de arquitectura, para entrevistas de diseño de sistemas y para equipos que quieren discutir capacidad con datos en la mesa, Breakscale ofrece algo que ni los diagramas estáticos ni las diapositivas pueden dar: la experiencia de arrastrar el tráfico y ver, con percentiles medidos, exactamente dónde y por qué se rompe el sistema. Que funcione en el navegador sin cuenta, en VS Code sin conexión y desde cualquier asistente de IA mediante MCP lo vuelve accesible desde casi cualquier flujo de trabajo, y su licencia MIT permite estudiar el motor hasta la última línea.