# Software Architecture

> Cuaderno de ingeniería sobre arquitectura de software: artículos a fondo, diagramas vivos y ejemplos claros para diseñar sistemas que escalan.

- [Documentación](https://sazardev.github.io/software-architecture/es/docs): Explora por tema todos los artículos del cuaderno: arquitectura de software explicada con diagramas, ejemplos y práctica.
- [RSS (es)](https://sazardev.github.io/software-architecture/es/feed.xml)

## Fundamentos — Bases conceptuales y principios que sostienen cualquier arquitectura sólida.

- [Primeros pasos](https://sazardev.github.io/software-architecture/es/docs/getting-started): Guía de orientación: qué es este sitio, qué leer y en qué orden según tu perfil, un plan de cuatro semanas, cómo usar la búsqueda y cómo contribuir contenido.
- [Principios SOLID](https://sazardev.github.io/software-architecture/es/docs/solid): Los cinco principios SOLID explicados con ejemplos concretos y enlaces para profundizar en cada uno.
- [ADR: documenta decisiones de arquitectura](https://sazardev.github.io/software-architecture/es/docs/adr): Guía práctica de ADR: qué son, cuándo escribirlos, plantillas (Nygard, MADR, Y-statements), ciclo de vida, revisión en PR y uso con agentes de IA.
- [Acoplamiento y cohesión: la base del diseño](https://sazardev.github.io/software-architecture/es/docs/acoplamiento-cohesion): Guía para arquitectos: tipos de cohesión y acoplamiento, ocultación de información, módulos profundos, Deméter, inestabilidad y connascence, con herramientas.
- [Atributos de calidad y trade-offs](https://sazardev.github.io/software-architecture/es/docs/atributos-de-calidad): Cómo elegir los atributos de calidad que mandan, escribirlos como escenarios medibles, analizar trade-offs con un ATAM ligero y vigilarlos con SLOs.
- [DevOps y su cultura: la base de la entrega](https://sazardev.github.io/software-architecture/es/docs/devops-cultura): Guía fundacional: qué es DevOps y qué no, su cultura (CALMS, Tres Vías, Westrum), las métricas DORA y cómo adoptarlo sin empezar por las herramientas.
- [Patrones de diseño GoF con enfoque moderno](https://sazardev.github.io/software-architecture/es/docs/patrones-de-diseno): Qué patrones del GoF siguen vigentes, cuáles absorbió el lenguaje y cuáles reemplazó la inyección de dependencias, con una guía para decidir.
- [Trade-offs y toma de decisiones en arquitectura](https://sazardev.github.io/software-architecture/es/docs/trade-offs-y-decisiones): Cómo razonar una decisión de arquitectura: criterios explícitos, reversibilidad, último momento responsable, sesgos y un método reutilizable.
- [Principios de diseño básicos](https://sazardev.github.io/software-architecture/es/docs/principios-de-diseno-basicos): DRY, KISS, YAGNI, Ley de Deméter y ocultación de información: de dónde salen, qué protege cada uno, cuándo ayudan y cuándo hacen daño.
- [Complejidad esencial y accidental](https://sazardev.github.io/software-architecture/es/docs/complejidad-esencial-y-accidental): La distinción de Brooks entre la complejidad del problema y la que añaden tus herramientas: cómo diagnosticarla, evitar sus trampas y reducirla.
- [Ley de Conway y Team Topologies](https://sazardev.github.io/software-architecture/es/docs/ley-de-conway-team-topologies): Por qué la comunicación de una organización acaba en su arquitectura, la maniobra inversa de Conway y cómo diseñar equipos con Team Topologies.
- [Datos, ACID y niveles de aislamiento](https://sazardev.github.io/software-architecture/es/docs/datos-acid-y-aislamiento): Modelar datos, transacciones ACID, anomalías de concurrencia y niveles de aislamiento: qué protege cada nivel y cómo elegir en tu base de datos.
- [Números y leyes de rendimiento](https://sazardev.github.io/software-architecture/es/docs/numeros-y-leyes-de-rendimiento): Ley de Little, Amdahl, la ley de escalabilidad universal y colas: cómo estimar latencia, concurrencia y capacidad antes de construir.
- [Estilos arquitectónicos](https://sazardev.github.io/software-architecture/es/docs/estilos-arquitectonicos): Qué es un estilo arquitectónico, en qué se distingue de un patrón y de una tecnología, y cómo elegir entre nueve estilos según tus atributos de calidad.
- [La complejidad que añaden tus herramientas](https://sazardev.github.io/software-architecture/es/docs/complejidad-accidental-de-herramientas): Distinguir la complejidad del problema de la que añaden tus frameworks y herramientas, con preguntas de diagnóstico y cuatro formas de reducirla.
- [El arquitecto como facilitador](https://sazardev.github.io/software-architecture/es/docs/arquitecto-como-facilitador): Cómo influir sin autoridad formal: cuándo decidir tú, cuándo consultar y cuándo delegar, y cómo mantener al equipo dueño de sus decisiones.

## Diseño de sistemas — Modelado, diagramas y decisiones para comunicar arquitectura compleja.

- [Modelo C4: documenta tu arquitectura por niveles](https://sazardev.github.io/software-architecture/es/docs/c4-model): Aprende los cuatro niveles del modelo C4 con un ejemplo completo: contexto, contenedores, componentes y código, más reglas de notación y errores típicos.
- [Domain-Driven Design: diseña desde el dominio](https://sazardev.github.io/software-architecture/es/docs/domain-driven-design): Guía de DDD para arquitectos: subdominios, lenguaje ubicuo, bounded contexts, agregados, Event Storming y las herramientas para sostener el diseño.
- [Arquitectura hexagonal: puertos y adaptadores](https://sazardev.github.io/software-architecture/es/docs/arquitectura-hexagonal): Guía para arquitectos: puertos y adaptadores, regla de dependencia, cómo organizar y nombrar las piezas, cómo probarla y protegerla con reglas ejecutables.
- [Diagramas como código: documenta con versiones](https://sazardev.github.io/software-architecture/es/docs/diagramas-como-codigo): Compara Mermaid, Structurizr, D2, PlantUML y Graphviz con un mismo sistema, y aprende a versionar, validar en CI y mantener vivos tus diagramas.
- [Monolito, monolito modular o microservicios](https://sazardev.github.io/software-architecture/es/docs/monolito-vs-microservicios): Cómo decidir entre monolito, monolito modular y microservicios: costes reales, fronteras ejecutables, ley de Conway y rutas de migración.
- [Capas, cebolla y Clean Architecture: hacia dónde apuntar](https://sazardev.github.io/software-architecture/es/docs/arquitectura-en-capas-clean-onion): Arquitectura en capas, cebolla y limpia comparadas: la regla de dependencia, qué cruza cada frontera, errores típicos y una guía para elegir.
- [Teorema CAP, PACELC y consistencia](https://sazardev.github.io/software-architecture/es/docs/cap-pacelc): Qué dicen de verdad CAP y PACELC, el espectro de modelos de consistencia y cómo elegir el trade-off por operación en un sistema distribuido.
- [Event-driven, CQRS y Event Sourcing](https://sazardev.github.io/software-architecture/es/docs/event-driven-cqrs-event-sourcing): Eventos frente a comandos, notificación frente a transferencia de estado, CQRS y Event Sourcing: cuándo compensan, proyecciones, versionado y borrado.
- [Sagas, outbox e idempotencia](https://sazardev.github.io/software-architecture/es/docs/sagas-outbox-idempotencia): Cómo coordinar cambios entre servicios sin transacción distribuida: sagas, compensaciones, outbox, deduplicación e idempotencia.
- [Diseño de APIs: contratos que duran](https://sazardev.github.io/software-architecture/es/docs/diseno-de-apis): Contrato primero, REST, GraphQL y gRPC, cambios que no rompen, paginación, errores con RFC 9457, idempotencia y límites de tasa para APIs que evolucionan.
- [Multiagente: cuándo un agente basta](https://sazardev.github.io/software-architecture/es/docs/multiagente-cuando-un-agente-basta): Cuándo un agente con buenas herramientas basta, qué cuesta cada enlace de un sistema multiagente y cómo diseñar contratos, trazas y límites entre agentes.
- [Arquitectura de archivos para repos grandes](https://sazardev.github.io/software-architecture/es/docs/arquitectura-de-archivos-repos-grandes): Cómo organizar el árbol de un repositorio grande para que los límites entre módulos sean reales: dominio, API pública, reglas de dependencia y propiedad.
- [Resiliencia en sistemas distribuidos](https://sazardev.github.io/software-architecture/es/docs/resiliencia-sistemas-distribuidos): Timeouts, plazos, reintentos con backoff y jitter, circuit breaker, bulkheads y deslastre de carga para contener fallos parciales y medirlos.
- [Caché, colas y streaming](https://sazardev.github.io/software-architecture/es/docs/caching-colas-streaming): Patrones de caché, invalidación y estampidas; colas frente a logs particionados, semánticas de entrega y cómo elegir entre cola, pub/sub y log.
- [Contratos de eventos versionados y compatibles](https://sazardev.github.io/software-architecture/es/docs/contratos-de-eventos-versionados): Cómo evolucionar eventos sin romper consumidores: el esquema como contrato, compatibilidad hacia atrás y hacia adelante, versionado y deprecación medida.
- [Escalabilidad y casos clásicos de diseño](https://sazardev.github.io/software-architecture/es/docs/escalabilidad-casos-clasicos): Método para escalar: requisitos, estimación de orden de magnitud, particiones y réplicas, aplicado a un acortador de URLs, un limitador de tasa y un feed.
- [Renderizado web: SSR, SSG, ISR e islands](https://sazardev.github.io/software-architecture/es/docs/renderizado-web-ssr-ssg-islands): Dónde se genera el HTML y cuándo: CSR, SSR, SSG, ISR, streaming e islands, con sus costes, criterios de elección y errores frecuentes.
- [Caso de estudio: un sistema de principio a fin](https://sazardev.github.io/software-architecture/es/docs/caso-estudio-sistema-completo): Caso ilustrativo de un sistema de reservas: requisitos, fronteras, datos, integración, seguridad y evolución, con cada decisión y su alternativa.
- [Multi-tenancy: varios clientes, un sistema](https://sazardev.github.io/software-architecture/es/docs/multi-tenancy): Cómo diseñar un SaaS multi-tenant: modelos de aislamiento, identificación del tenant, Row-Level Security, vecino ruidoso, migraciones y medición de uso.
- [Las capas no son la arquitectura](https://sazardev.github.io/software-architecture/es/docs/capas-no-son-arquitectura): Por qué las carpetas por capa no bastan: la regla de dependencia, qué debe cruzar cada frontera y cuándo las capas añaden ruido en lugar de protección.
- [Modelado de datos: normalizar o desnormalizar](https://sazardev.github.io/software-architecture/es/docs/modelado-de-datos-normalizacion): Cómo modelar datos según cómo se leen y escriben: normalización, copias con dueño, relacional frente a documental y diseño guiado por consultas.
- [Monolito modular antes que microservicios](https://sazardev.github.io/software-architecture/es/docs/monolito-modular-primero): Monolito o microservicios es la pregunta equivocada. Cómo diseñar fronteras dentro de un proceso y cuándo tiene sentido extraer un servicio.
- [Coordinar servicios sin transacción distribuida](https://sazardev.github.io/software-architecture/es/docs/coordinar-servicios-sin-2pc): Sagas con compensaciones, outbox e idempotencia para una operación que atraviesa varios servicios y puede fallar a mitad de camino.
- [CAP se decide por operación](https://sazardev.github.io/software-architecture/es/docs/cap-por-operacion): CAP y PACELC explicados como decisiones por operación: qué significa elegir consistencia o disponibilidad en un saldo, un carrito o un contador de likes.
- [Antes de escalar, haz la cuenta](https://sazardev.github.io/software-architecture/es/docs/antes-de-escalar-la-cuenta): Ley de Little, ley de Amdahl y colas para estimar concurrencia y capacidad antes de añadir servidores, con un cálculo completo de principio a fin.
- [Migrar la base de datos sin parar el servicio](https://sazardev.github.io/software-architecture/es/docs/migraciones-bd-sin-downtime): Expand y contract, cambios de esquema compatibles hacia atrás y backfills por lotes para evolucionar una base de datos sin ventanas de mantenimiento.
- [Legado: estrangulador y capa anticorrupción](https://sazardev.github.io/software-architecture/es/docs/legado-strangler-anticorrupcion): Cómo modernizar un sistema que no puedes reescribir: un estrangulador que desvía rutas y una capa anticorrupción que protege el modelo nuevo.
- [Micro-frontends y BFF: cuándo sí y cuándo no](https://sazardev.github.io/software-architecture/es/docs/micro-frontends-y-bff): Cuándo partir el frontend en micro-frontends y cuándo basta con un BFF por canal. Criterios de acoplamiento, equipos y costo de coordinar los despliegues.
- [Tiempo real: WebSockets, SSE y colas](https://sazardev.github.io/software-architecture/es/docs/tiempo-real-websockets-sse): Cómo elegir entre SSE, WebSocket y colas para empujar datos en tiempo real: dirección del flujo, número de clientes y qué pasa cuando se cae la conexión.
- [Pagos y libro mayor: partida doble sin errores](https://sazardev.github.io/software-architecture/es/docs/pagos-libro-mayor-ledger): Asientos de partida doble inmutables, correcciones por contraasiento, idempotencia de cobros y conciliación con el proveedor de pagos.
- [Elegir base de datos: patrones de acceso primero](https://sazardev.github.io/software-architecture/es/docs/persistencia-politica-elegir-bd): Antes de elegir una base de datos, define consultas y escrituras: qué tipo de almacén encaja, cuándo compensa la persistencia políglota y qué cuesta operarla.
- [Búsqueda en la aplicación: cuándo basta la base](https://sazardev.github.io/software-architecture/es/docs/busqueda-en-aplicacion): Cuándo basta un índice de la base de datos, cuándo conviene un índice invertido dedicado y cómo mantenerlo sincronizado con la fuente sin perder cambios.
- [Notificaciones: push, correo y SMS con fiabilidad](https://sazardev.github.io/software-architecture/es/docs/notificaciones-push-correo-sms): Servicio de notificaciones desacoplado, una cola por canal, preferencias del usuario, deduplicación y reintentos que evitan pérdidas y reducen duplicados.
- [Arquitectura extensible: plugins y puntos de extensión](https://sazardev.github.io/software-architecture/es/docs/arquitectura-extensible-plugins): Cuándo abrir un sistema a extensiones, puntos de extensión con contrato estable, sandbox con permisos y versionado y deprecación de la API de plugins.
- [Móvil offline-first: sincronizar sin perder datos](https://sazardev.github.io/software-architecture/es/docs/movil-offline-first-sincronizacion): Cómo diseñar una app que escribe primero en local, sincroniza una cola de operaciones en orden y resuelve conflictos sin perder cambios del usuario.

## Prácticas y calidad — Hábitos, refactoring continuo y estándares que mantienen el sistema sano.

- [Clean code para arquitectos](https://sazardev.github.io/software-architecture/es/docs/clean-code): Guía práctica de código limpio: nombres, funciones, errores, complejidad, tests, refactoring y deuda técnica, con ejemplos y checklist de revisión.
- [Harness engineering con Claude Code](https://sazardev.github.io/software-architecture/es/docs/harness-engineering-claude-code): Guía para arquitectos: cómo diseñar el harness de Claude Code con memoria, hooks, permisos, subagentes y workflows dinámicos, al día a octubre de 2026.
- [Fitness functions y arquitectura evolutiva](https://sazardev.github.io/software-architecture/es/docs/fitness-functions): Cómo convertir las características de tu arquitectura en comprobaciones automáticas: tipos, herramientas por lenguaje y cómo adoptarlas en sistemas legados.
- [Deuda técnica y evolución arquitectónica](https://sazardev.github.io/software-architecture/es/docs/deuda-tecnica-evolucion): Cómo nombrar, medir y pagar la deuda técnica, y cómo evolucionar la arquitectura con cambios incrementales y guiados en lugar de reescrituras.
- [Seguridad por diseño: amenazas, fronteras y confianza](https://sazardev.github.io/software-architecture/es/docs/seguridad-por-diseno): La seguridad como propiedad de la arquitectura: principios clásicos, STRIDE en una hora, límites de confianza, secretos, cadena de suministro y zero trust.
- [Tu arquitectura debería fallar en el CI](https://sazardev.github.io/software-architecture/es/docs/fitness-en-el-ci): Cómo convertir una regla de arquitectura en una comprobación que falla el pipeline, con un ejemplo real de ESLint en este repositorio y los pasos para empezar.
- [Reintentos con jitter, sin tormentas](https://sazardev.github.io/software-architecture/es/docs/reintentos-con-jitter): Por qué los reintentos sin jitter multiplican una caída y cómo combinar timeouts, backoff, presupuestos de reintento y circuit breaker.
- [Observabilidad: SLI, SLO y presupuesto de error](https://sazardev.github.io/software-architecture/es/docs/observabilidad-slo-presupuesto-error): Cómo medir lo que vive el usuario con SLI, fijar un SLO y usar el presupuesto de error para decidir cuándo acelerar y cuándo frenar.
- [Estrategia de pruebas: pirámide y contratos](https://sazardev.github.io/software-architecture/es/docs/estrategia-de-pruebas-contratos): Qué probar en cada nivel de la pirámide, cómo los contratos entre servicios evitan integraciones rotas y qué pruebas de arquitectura proteger.
- [Entrega progresiva: flags, canary y blue/green](https://sazardev.github.io/software-architecture/es/docs/entrega-progresiva-flags-canary): Desplegar sin exponer a todos los usuarios: feature flags, despliegues canary y blue/green, y cómo revertir sin tener que volver a desplegar.
- [Evaluar agentes: trayectorias, regresiones y jueces](https://sazardev.github.io/software-architecture/es/docs/evaluar-agentes-trayectorias): Cómo evaluar un agente que actúa: trayectorias frente a resultado final, tareas con criterios verificables, jueces basados en modelos, varianza y evals en CI.
- [Identidad y permisos de agentes: privilegio y auditoría](https://sazardev.github.io/software-architecture/es/docs/identidad-y-permisos-de-agentes): Qué identidad usa un agente, cómo delegar credenciales con alcance acotado, mínimo privilegio por acción, secretos fuera de su contexto y revocación.
- [Modelado de amenazas con STRIDE en un diagrama](https://sazardev.github.io/software-architecture/es/docs/modelado-de-amenazas-stride): Cómo aplicar STRIDE a un diagrama de flujo de datos real: límites de confianza, las seis categorías de amenaza y un ejemplo completo de revisión.
- [Código generado por IA: revisión, propiedad y deuda](https://sazardev.github.io/software-architecture/es/docs/codigo-generado-por-ia): Cuando un modelo escribe el código, cambian la revisión, la propiedad y la deuda: qué medir, quién responde por un cambio y cómo dejar criterio.
- [Privacidad por diseño: datos, retención y borrado](https://sazardev.github.io/software-architecture/es/docs/privacidad-por-diseno-gdpr): Minimización, base legal, retención con plazos y borrado que llega a copias y respaldos: la privacidad como requisito de arquitectura.
- [Diseñar para borrar: retirar código sin miedo](https://sazardev.github.io/software-architecture/es/docs/disenar-para-borrar): Por qué el código que no se puede borrar acumula coste, y cómo diseñar límites, flags con caducidad y retiradas por fases que se pueden revertir.
- [Incidentes y postmortems sin culpa](https://sazardev.github.io/software-architecture/es/docs/gestion-incidentes-postmortems): Roles durante un incidente, severidades, comunicación y postmortems sin culpa que terminan en acciones con dueño y fecha.
- [Secretos y claves: rotación sin sobresaltos](https://sazardev.github.io/software-architecture/es/docs/gestion-secretos-claves): Por qué los secretos no van en el repositorio, cómo trabajan las bóvedas y las identidades de carga, y cómo rotar claves sin cortar el servicio.
- [Cadena de suministro: SBOM, firmas y SLSA](https://sazardev.github.io/software-architecture/es/docs/cadena-de-suministro-software): Guía para arquitectos: qué inventario, firmas y procedencia exigir a tu software, cómo fijar dependencias y qué nivel SLSA apuntar, a octubre de 2026.
- [Ramas y entrega continua: trunk-based frente a ramas largas](https://sazardev.github.io/software-architecture/es/docs/ramas-y-entrega-continua): Cómo la distancia entre el código y el tronco decide el coste de integrar: trunk-based frente a ramas largas, flags que caducan, tronco sano y qué medir.
- [Chaos engineering y game days: fallar a propósito](https://sazardev.github.io/software-architecture/es/docs/chaos-engineering-game-days): Cómo probar la resiliencia con fallos inyectados de forma controlada: hipótesis, radio de impacto, condición de parada y game days con los equipos.
- [Capacidad y pruebas de carga: medir con cargas reales](https://sazardev.github.io/software-architecture/es/docs/capacidad-y-pruebas-de-carga): Cuánta capacidad necesita un sistema y cómo comprobarlo con cargas parecidas al tráfico real: modelo de carga, tipos de prueba, errores de medición y margen.
- [Trazas distribuidas con OpenTelemetry](https://sazardev.github.io/software-architecture/es/docs/trazas-distribuidas-opentelemetry): Cómo seguir una petición entre servicios con trazas, qué datos hacen útil cada tramo y cómo muestrear y gobernar la telemetría con OpenTelemetry.
- [Infraestructura como código y GitOps](https://sazardev.github.io/software-architecture/es/docs/infraestructura-como-codigo-gitops): Infraestructura como código revisable: estado remoto con bloqueo, drift, módulos versionados, permisos mínimos y GitOps frente a un pipeline que empuja.

## Tendencias — Lenguajes, plataformas y cambios de la industria que conviene entender antes de decidir.

- [Lenguajes y frameworks en la era de la IA](https://sazardev.github.io/software-architecture/es/docs/lenguajes-era-ia): Guía para arquitectos: qué papel juegan Python, TypeScript, Rust, Go, Mojo y Zig en la era de la IA, y cómo elegir entre ellos.
- [Arquitectura de aplicaciones con LLM y agentes](https://sazardev.github.io/software-architecture/es/docs/arquitectura-agentes-llm): Guía para arquitectos: cuándo usar workflows o agentes, qué componentes necesita una aplicación con LLM, cómo asegurarla y qué trade-offs asumir.
- [Arquitectura de datos: lakehouse y data mesh](https://sazardev.github.io/software-architecture/es/docs/arquitectura-de-datos-lakehouse): Cuándo un data warehouse basta, cuándo conviene un lakehouse sobre formatos de tabla abiertos y cuándo el data mesh tiene sentido organizativo.
- [RAG en producción y evaluación continua](https://sazardev.github.io/software-architecture/es/docs/rag-y-evaluacion-continua): Cómo llevar un RAG a producción: indexación, recuperación y generación como una cadena medible, con métricas por etapa y evaluación continua de cada cambio.
- [Costo de inferencia: modelo, caché y despliegue](https://sazardev.github.io/software-architecture/es/docs/costo-de-inferencia): Cómo reducir el costo por petición de un LLM: elegir el modelo más pequeño que sirve, usar caché con criterio y decidir dónde ejecutar la inferencia.
- [Software sostenible: la huella como atributo](https://sazardev.github.io/software-architecture/es/docs/software-sostenible-carbono): Cómo tratar la huella de carbono del software como atributo de calidad: qué medir, dónde se genera y cómo elegir región, horario y cómputo con criterio.
- [MLOps: llevar un modelo a producción](https://sazardev.github.io/software-architecture/es/docs/mlops-modelo-a-produccion): Cómo versionar datos, código y modelos por separado, desplegar con sombra y canary, vigilar la deriva y decidir cuándo reentrenar o retirar un modelo.
- [Edge y CDN: qué ejecutar en el borde](https://sazardev.github.io/software-architecture/es/docs/edge-computing-cdn): Qué sirve una CDN, qué puede ejecutarse en el borde, cómo se reparten la latencia y la caché, y cuándo acercar la lógica al usuario no compensa.
- [MCP y A2A: integrar herramientas y agentes](https://sazardev.github.io/software-architecture/es/docs/mcp-y-a2a-integracion-de-herramientas): Qué estandarizan MCP y A2A, qué ganas y qué pagas al adoptarlos, y cuándo exponer una herramienta por MCP en lugar de una API normal.
- [Context engineering y memoria de agentes](https://sazardev.github.io/software-architecture/es/docs/context-engineering-y-memoria-de-agentes): Cómo tratar el contexto de un agente como recurso escaso: qué entra en la ventana, cuándo compactar, qué guardar como memoria y cómo medir que funciona.
- [Agentes que usan interfaces: navegador y escritorio](https://sazardev.github.io/software-architecture/es/docs/agentes-que-usan-interfaces): Cuándo un agente debe manejar una interfaz gráfica en vez de una API, qué riesgos añade la página y cómo acotarlo con sandbox, aprobaciones y trazas.
- [Modelos pequeños, on-device y soberanía de datos](https://sazardev.github.io/software-architecture/es/docs/modelos-pequenos-on-device-soberania): Cuándo un modelo pequeño en el dispositivo o en infraestructura propia gana a una API frontier: latencia, privacidad, coste, soberanía y lo que se pierde.
- [Datos para IA: calidad, sintéticos y licencias](https://sazardev.github.io/software-architecture/es/docs/calidad-datos-para-ia): Calidad de datos para modelos y RAG, datos sintéticos con sus riesgos y el marco de licencias y consentimiento que cambia según la jurisdicción.
- [Arquitectura con IA: qué apostar, qué vigilar](https://sazardev.github.io/software-architecture/es/docs/futuro-arquitectura-con-ia): Mirada prospectiva a 2027 para decidir hoy: tendencias verificadas, hipótesis etiquetadas, señales de revisión y decisiones reversibles.

## Nube — Masterclass para arquitectos: servicios, modelos de despliegue, híbrido, dependencia de proveedores, costos y resiliencia en la nube.

- [Servicios en la nube para arquitectos](https://sazardev.github.io/software-architecture/es/docs/servicios-nube-para-arquitectos): El modelo de servicio como contrato de responsabilidades: IaaS, CaaS, PaaS, FaaS y SaaS, las categorías clave y cómo elegir entre gestionado y propio.
- [Modelos de despliegue: público, privado, híbrido](https://sazardev.github.io/software-architecture/es/docs/modelos-de-despliegue-nube): Nube pública, privada, comunitaria e híbrida según NIST: qué cambia en control, datos y costo, y cómo elegir el modelo por carga de trabajo.
- [Nube híbrida en detalle](https://sazardev.github.io/software-architecture/es/docs/nube-hibrida-en-detalle): Patrones, conectividad redundante, identidad federada, despliegue consistente y qué debe seguir funcionando cuando se corta el enlace con la nube.
- [Casado a un proveedor: lock-in y plan de salida](https://sazardev.github.io/software-architecture/es/docs/casado-a-un-proveedor): Tipos de lock-in en la nube, cómo estimar el costo de salida, portabilidad por capas y cómo documentar un plan de salida que se haya probado.
- [Multinube: cuándo tiene sentido](https://sazardev.github.io/software-architecture/es/docs/multinube-cuando-tiene-sentido): Qué es la multinube y en qué se distingue del híbrido, qué motivos funcionan y cuáles fallan, sus costos ocultos, patrones y un marco para decidir.
- [Serverless y computación gestionada](https://sazardev.github.io/software-architecture/es/docs/serverless-y-computacion-gestionada): Del control a la abstracción: modelo de ejecución de funciones, arranque en frío, estado, reintentos, costo por invocación y acoplamiento al proveedor.
- [Redes, identidad y seguridad en la nube](https://sazardev.github.io/software-architecture/es/docs/redes-identidad-seguridad-nube): Redes virtuales, endpoints privados, identidad de carga de trabajo, mínimo privilegio, secretos, claves y registros: cómo proteger una carga en la nube.
- [Regiones, zonas y recuperación ante desastres](https://sazardev.github.io/software-architecture/es/docs/regiones-zonas-y-recuperacion): Zonas y regiones como dominios de fallo, replicación síncrona y asíncrona, RTO y RPO, las cuatro estrategias de recuperación y cómo probarlas de verdad.
- [FinOps: el costo como atributo de arquitectura](https://sazardev.github.io/software-architecture/es/docs/finops-costo-como-atributo): Cómo tratar el costo de la nube como atributo de calidad: modelos de precio, costo por unidad, etiquetado, costos ocultos y gobierno con FinOps.
- [Cuánto costaría salir de tu nube](https://sazardev.github.io/software-architecture/es/docs/salida-de-la-nube): El costo de salida del proveedor no es parejo: los datos suelen pesar más que la API. Cómo estimarlo y por qué conviene probar el plan de salida.
- [Autorización a escala: RBAC, ABAC y ReBAC](https://sazardev.github.io/software-architecture/es/docs/autorizacion-rbac-abac-rebac): Cuándo usar roles, atributos o relaciones para decidir quién puede hacer qué, y cómo evitar duplicar reglas de acceso en cada servicio.
- [Migrar a la nube: las 6R con criterio](https://sazardev.github.io/software-architecture/es/docs/migracion-nube-6r): Rehost, replatform, refactor, repurchase, retire y retain: cómo elegir la estrategia de migración a la nube por aplicación, con criterio.
- [Sesiones, tokens y SSO: qué elegir y por qué](https://sazardev.github.io/software-architecture/es/docs/sesiones-tokens-sso): Sesiones del servidor frente a tokens autocontenidos, expiración y rotación, revocación, SSO sobre OAuth 2.0 y dónde guardar los tokens.
- [Costes por equipo y funcionalidad: etiquetar y alertar](https://sazardev.github.io/software-architecture/es/docs/costes-por-equipo-y-funcionalidad): Cómo atribuir el gasto de nube a equipos y funcionalidades: etiquetas obligatorias, reparto de costes compartidos y alertas de presupuesto antes del límite.
- [Kubernetes: cuándo sí y cuándo no](https://sazardev.github.io/software-architecture/es/docs/kubernetes-cuando-si-cuando-no): Qué resuelve Kubernetes de verdad, qué coste operativo trae y cuándo un servicio gestionado, un PaaS o una VM bien gestionada son la decisión más barata.

## Decisiones, procesos e IA — Marcos para decidir, presentar ideas, mejorar flujos y programas, y controlar la IA en el trabajo de negocio y de ingeniería.

- [Marcos de priorización: RICE, WSJF, ICE](https://sazardev.github.io/software-architecture/es/docs/marcos-de-priorizacion): Cómo ordenar un backlog con RICE, ICE y WSJF: fórmulas, costo del retraso, un ejemplo con cinco iniciativas y las trampas de la falsa precisión.
- [Marcos de decisión estratégica: Cynefin y mapas de Wardley](https://sazardev.github.io/software-architecture/es/docs/marcos-de-decision-estrategica): Cynefin para saber qué tipo de problema tienes y mapas de Wardley para decidir qué construir, comprar o alquilar según la evolución de cada componente.
- [Presentar ideas y propuestas que se aprueban](https://sazardev.github.io/software-architecture/es/docs/presentar-ideas-y-propuestas): Cómo escribir una propuesta técnica o de negocio que se entiende y se decide: conclusión primero, opciones con criterios, riesgos y costo de no hacer.
- [Flujo de valor y cuellos de botella](https://sazardev.github.io/software-architecture/es/docs/flujo-de-valor-y-cuellos-de-botella): Mapa del flujo de valor, tiempo de espera frente a tiempo de proceso, teoría de restricciones, ley de Little y límites de WIP para acortar la entrega.
- [Mejora continua y experimentos](https://sazardev.github.io/software-architecture/es/docs/mejora-continua-y-experimentos): Ciclo PDSA, kaizen y kata de mejora; cómo diseñar experimentos con hipótesis, métrica de guarda y criterio de parada, y retrospectivas que sí cambian algo.
- [Medir decisiones: OKR, KPI y métricas guía](https://sazardev.github.io/software-architecture/es/docs/medir-decisiones-okr-kpi): Cómo medir para decidir: KPI de salud, OKR con resultados clave, métricas guía contra efectos colaterales y umbrales que disparan una decisión.
- [IA para decidir: investigar, escenarios y pre-mortem](https://sazardev.github.io/software-architecture/es/docs/ia-para-decidir-negocio): Cómo usar un modelo de lenguaje para mejorar una decisión de negocio sin delegarla: qué pedirle, dónde falla, cómo verificar y un pre-mortem guiado.
- [Controlar la IA: gobierno, autonomía y evaluación](https://sazardev.github.io/software-architecture/es/docs/controlar-la-ia-gobierno-y-autonomia): Cuánta autonomía dar a un sistema con IA, dónde exigir aprobación humana, cómo evaluarlo de forma continua y qué piden NIST AI RMF, el EU AI Act y OWASP.
- [Diseñar flujos con agentes de IA](https://sazardev.github.io/software-architecture/es/docs/disenar-flujos-con-agentes): Qué pasos de un flujo hace el código y cuáles un agente, dónde validar, aprobar y parar, y cómo trazar estado, costo e idempotencia de cada paso.
- [El trabajo del arquitecto con agentes: roles y productividad](https://sazardev.github.io/software-architecture/es/docs/trabajo-del-arquitecto-con-agentes): Qué cambia en el rol del arquitecto cuando el equipo trabaja con agentes de IA: especificar, delegar con criterio, revisar y medir el flujo sin engañarse.
- [Herramientas para decidir y documentar](https://sazardev.github.io/software-architecture/es/docs/herramientas-para-decidir-y-documentar): Un marco para elegir software de decisiones y documentación por integración, exportación, costo de salida, permisos y búsqueda, no por moda.
- [Librerías internas: extraer, versionar o copiar](https://sazardev.github.io/software-architecture/es/docs/librerias-internas-sin-infierno-versiones): Cuándo convertir código compartido en una librería interna, cuándo es mejor copiarlo y cómo versionarla y retirarla sin que cada cambio sea un incendio.
- [Pensamiento sistémico y sesgos en las decisiones](https://sazardev.github.io/software-architecture/es/docs/pensamiento-sistemico-y-sesgos): Bucles de refuerzo y equilibrio, retrasos, soluciones que empeoran el problema y sesgos que distorsionan decisiones, con técnicas para contrarrestarlos.
- [Tu organigrama dibuja tu arquitectura](https://sazardev.github.io/software-architecture/es/docs/organigrama-y-sistema): La ley de Conway en la práctica: cómo la comunicación de tu organización acaba en el sistema y cómo usar la maniobra inversa para diseñar equipos a propósito.
- [Las decisiones tienen ciclo de vida](https://sazardev.github.io/software-architecture/es/docs/adr-ciclo-de-vida): Un ADR se propone, se acepta y, con el tiempo, queda obsoleto o se reemplaza. Cómo mantener un registro de decisiones sin borrar la historia.
- [Cuánta autonomía dar a un agente](https://sazardev.github.io/software-architecture/es/docs/autonomia-de-la-ia): Niveles de autonomía para sistemas con IA: qué pasos son deterministas, dónde poner aprobación humana, cómo parar y cómo trazar costo e idempotencia.
- [Plataforma interna: cuándo construir un IDP](https://sazardev.github.io/software-architecture/es/docs/plataforma-interna-idp): Qué es una plataforma interna para desarrolladores, cuándo justifica su coste y cómo tratarla como producto con caminos dorados medibles.
- [Monorepo o polirepo: la decisión con sus costos](https://sazardev.github.io/software-architecture/es/docs/monorepo-o-polirepo): Cuándo un monorepo compensa, cuándo un polirepo es mejor y qué costos ocultos aparecen en cada opción, con criterios explícitos para decidir.
- [RFC y revisiones de arquitectura sin burocracia](https://sazardev.github.io/software-architecture/es/docs/rfc-y-revisiones-de-arquitectura): Cómo llevar propuestas técnicas a revisión con plazos, criterios claros de decisión y registro en ADR, sin convertir cada cambio en un comité.
- [Catálogo de servicios y gobierno de APIs](https://sazardev.github.io/software-architecture/es/docs/catalogo-servicios-gobierno-apis): Un catálogo de servicios con dueño, estado y contrato por servicio, reglas de gobierno ligeras y un ciclo de vida de API con fechas de deprecación y retiro.
- [Documentar la arquitectura para que alguien la use](https://sazardev.github.io/software-architecture/es/docs/documentar-arquitectura-util): Qué preguntas debe responder la documentación de arquitectura, cómo elegir su nivel de detalle, mantenerla cerca del código y medir si alguien la usa.

_125 artículos en es. Generado desde https://sazardev.github.io/software-architecture/es._