svallejo-dev/arquitectura
Diseño de sistemas a gran escala en español, partiendo de lo que ya existe o, sin métricas, del arquetipo del negocio: sparring de system design como delta (AS-IS → TO-BE → migración) o plan de PoC, red team en paralelo, capacidad calculada en código con escenarios y umbrales, diseño estratégico DDD, arquetipos de negocio y un catálogo curado de bloques.
Catálogo de referencia de bloques de construcción de sistemas distribuidos (API, almacenamiento, caching, consistencia, mensajería, scheduling, resiliencia, escalado, observabilidad, logging, balanceo, DNS, CDN, IDs, contadores, blobs, búsqueda, descomposición de servicios, requisitos) con opciones, trade-offs y comportamiento bajo estrés. Lo cargan system-design y design-stress-test; úsalo también para una pregunta puntual sobre uno de esos componentes.
Arquetipos de negocio para diseñar sin métricas previas (diseño exploratorio, PoC, producto nuevo). Cada arquetipo (streaming y media, fintech y pagos, ticketing y eventos en vivo, e-commerce y marketplace, social y mensajería, SaaS B2B, IoT y telemetría, movilidad y logística, healthtech, plataforma de IA, plataforma de eventos interna) da fuerzas dominantes, forma de la carga, invariantes, subdominios típicos, arquitectura de referencia, modos de fallo e hipótesis de PoC. Lo cargan system-design, capacity-estimation, design-stress-test y strategic-design; úsalo también cuando el usuario diga "es tipo Netflix/Stripe/Uber" o describa un producto sin números.
Estimación de capacidad con números calculados en código, no en prosa. Parte de métricas medidas cuando el sistema existe, o de escenarios por orden de magnitud y umbrales de decisión cuando no hay métricas (diseño exploratorio, PoC), apoyándose en el arquetipo de negocio. Cubre QPS, almacenamiento, ancho de banda, ley de Little, utilización y colas, fan-out y latencia de cola, disponibilidad compuesta, shards, backlog y burn rate. Úsala cuando una decisión dependa de la escala ("¿aguanta?", "¿cuántas instancias?", "¿hace falta shardear?", "capacity planning", "back-of-the-envelope").
Red team de un diseño o de un sistema existente. Lanza sub-agentes en paralelo, cada uno con una familia de ataques (carga, dependencias, datos, cambios, infraestructura, operación, abuso), sembrados con los incidentes reales del sistema y verificados contra su código y configuración; devuelve una matriz de riesgos con modo de fallo, detección y mitigación. Úsala cuando el usuario pida "stress-test", "red team", "¿qué puede fallar?", "pre-mortem", "¿esto aguanta?" o una revisión de resiliencia.
Diseño estratégico (DDD) para decidir fronteras de servicios y contextos: clasificación de subdominios (core, supporting, generic), mapa de contextos con patrones nombrados (Anticorruption Layer, Open Host Service, Published Language, Customer-Supplier, Conformist, Shared Kernel, Partnership, Separate Ways), dueño de los datos y alineación con equipos. Parte del mapa actual (AS-IS) antes del objetivo. Úsala cuando se discutan fronteras de servicios, integraciones entre sistemas, una migración de legacy, "context map", "bounded contexts", "subdominios" o "¿dónde va esta responsabilidad?".
Sparring de diseño de sistemas a nivel de producción a gran escala, también para diseños exploratorios y PoCs sin métricas. Parte de lo que ya existe (el sistema actual, un sistema similar documentado o el arquetipo del negocio) y diseña como delta, estado actual → objetivo → camino de migración, con números calculados, alternativas con trade-offs explícitos, red team y decisiones registradas. Úsala cuando el usuario quiera diseñar, rediseñar o evaluar una arquitectura ("diseña", "¿cómo escalamos X?", "system design", "arquitectura para…", "revisa este RFC/diseño", "¿cómo migramos…?").