Read in English · Lire en français · Auf Deutsch lesen

Glosario de arquitectura de software

Definiciones breves de los 914 términos usados en los capítulos publicados, cada una enlazada al capítulo que la explica.

A

Abstracción: Una visión simplificada de algo que conserva lo que importa para un propósito y omite el resto, como un "archivo" que oculta discos, sectores y caché. Capítulo 3
Abstracción con fugas (leaky abstraction): Abstracción cuyos detalles ocultos siguen afectando a quienes la usan; por ejemplo, una llamada remota que parece local hasta que la red es lenta o falla. Bautizada por Joel Spolsky en 2002. Capítulo 3
Accesibilidad: El grado en que las personas con discapacidad, incluidas las que usan tecnologías de apoyo como los lectores de pantalla, pueden usar un producto. Capítulo 2
ACID: Atomicidad, consistencia, aislamiento y durabilidad: las garantías que ofrece una transacción de base de datos para que los datos sigan siendo correctos a pesar de caídas y usuarios simultáneos. Capítulo 0
Acoplamiento: Cuánto depende una parte de un sistema de los detalles de otra. Un acoplamiento débil significa que un cambio en una parte rara vez obliga a hacer cambios en otras. Capítulo 0
Acoplamiento aferente (Ca): El número de elementos externos a un componente que dependen de él: sus dependencias entrantes. Un Ca alto significa que muchos otros se ven afectados si cambia. Capítulo 3
Acoplamiento de cambio: Dos o más archivos o componentes que tienden a cambiar en los mismos commits, lo que revela una dependencia que puede no ser visible en el código. Capítulo 1
Acoplamiento de despliegue: Una situación en la que dos partes deben lanzarse juntas, o en un orden fijo, porque un cambio en una rompe la otra. Capítulo 3
Acoplamiento eferente (Ce): El número de elementos externos a un componente de los que este depende: sus dependencias salientes. Un Ce alto significa que está expuesto a los cambios de muchos otros. Capítulo 3
Acoplamiento semántico: Dependencia de un significado o de reglas de negocio compartidos que no es visible en ninguna interfaz, como dos servicios que deben coincidir en qué significa 'cliente activo'. Capítulo 3
Acoplamiento temporal: En los sistemas distribuidos, la dependencia de que otra parte esté disponible y responda en el mismo momento, como ocurre con una llamada síncrona. En otros ámbitos el término puede significar un orden obligatorio de llamadas o (en el análisis del control de versiones) archivos que cambian juntos, lo que este capítulo llama acoplamiento de cambio. Capítulo 3
Activo-activo (multisitio): Una configuración en la que dos o más regiones atienden tráfico real al mismo tiempo, de modo que perder una región no requiere failover, solo redistribuir el tráfico. Capítulo 10
Actualización perdida: Anomalía en la que dos transacciones leen un valor, cada una calcula uno nuevo y lo vuelve a escribir, de modo que un cambio sobrescribe al otro sin aviso. Capítulo 7
Acuerdo de nivel de servicio (SLA): Contrato con los clientes que establece un nivel de servicio y las consecuencias, como créditos de servicio, si no se cumple. Capítulo 2
Adaptador: Código que traduce entre un puerto y una tecnología concreta, como un controlador HTTP, un repositorio SQL o el SDK de un proveedor de pagos. Un puerto puede tener muchos adaptadores. Capítulo 5
Adaptador conducido (secundario): Un adaptador que implementa una interfaz a la que llama la aplicación cuando necesita algo del exterior, como almacenar datos, cobrar en una tarjeta o enviar un mensaje. Capítulo 5
Adaptador conductor (primario): Un adaptador que recibe solicitudes del exterior, como un controlador web, un arnés de pruebas o un trabajo programado, y llama a la aplicación a través de un puerto conductor. Capítulo 5
Agencia excesiva: Dar a un sistema de IA más herramientas, permisos o autonomía de los que su tarea necesita, de modo que un modelo manipulado o equivocado pueda causar daños reales. Capítulo 12
Agente: Un sistema en el que un modelo elige acciones repetidamente, como llamadas a herramientas, observa los resultados y decide qué hacer a continuación hasta alcanzar un objetivo o un límite. Capítulo 12
Ágil: Una familia de enfoques de desarrollo de software, formulada en el Manifiesto Ágil de 2001, que entregan software funcional en ciclos cortos y adaptan los planes según la retroalimentación. Capítulo 0
Agregado: Un grupo de objetos de dominio que se modifica como una unidad a través de una única entidad raíz, que hace cumplir las reglas que siempre deben mantenerse para el grupo. Capítulo 5
Agrupación de solicitudes (request coalescing): Dejar que una sola solicitud obtenga un elemento que falta mientras las demás solicitudes del mismo elemento esperan y comparten su resultado; también se llama single flight. Capítulo 7
Aislamiento de instantánea (snapshot isolation): Nivel de aislamiento en el que cada transacción lee una instantánea coherente de los datos confirmados desde su inicio, y se rechazan las escrituras en conflicto sobre la misma fila. Evita las actualizaciones perdidas, pero permite el write skew. Capítulo 7
Ajuste de tamaño (rightsizing): Adecuar el tamaño de los recursos aprovisionados (tipos de máquina, solicitudes de los contenedores, niveles de base de datos) a lo que una carga de trabajo usa realmente. Capítulo 10
Alerta multiventana y de múltiples tasas de consumo: Alerta de SLO que solo se dispara cuando la tasa de consumo (burn rate) supera un umbral tanto en una ventana larga como en una corta, lo que combina una detección rápida con un restablecimiento ágil y pocas falsas alarmas. Capítulo 9
Algoritmo: Un método preciso, paso a paso, para resolver un problema, como ordenar una lista o encontrar la ruta más corta, que siempre termina. Capítulo 0
Almacén clave-valor: Base de datos que guarda valores bajo claves únicas y los recupera solo por clave, como un diccionario muy grande y muy rápido. Capítulo 0
Almacén de columnas anchas (wide-column): Base de datos NoSQL que agrupa los datos en filas identificadas por una clave, cada una con muchas columnas, repartidas entre muchas máquinas. Diseñada para volúmenes de escritura muy grandes. Capítulo 0
Almacén de datos (data warehouse): Una base de datos construida para el análisis que integra datos depurados de muchos sistemas operativos y conserva su historial. Capítulo 7
Alucinación: Una salida de un modelo que es fluida y segura de sí misma, pero falsa o no respaldada por sus fuentes, como una cita o una política inventadas. Capítulo 12
Amplitud técnica: Saber que existen muchas tecnologías y enfoques, en qué son buenos y malos y cuándo usarlos, aun sin una experiencia práctica profunda en cada uno. Capítulo 1
Análisis canario automatizado: Comparación estadística de las métricas de un canario con las de una línea base que ejecuta la versión anterior, que el pipeline usa para promover o revertir sin juicio humano. Capítulo 10
Análisis de composición de software (SCA): Herramientas y prácticas que identifican los componentes de código abierto de un software y los cotejan con bases de datos de vulnerabilidades y licencias conocidas. Capítulo 8
Ancho de banda: Cuántos datos puede transportar una conexión por segundo, por ejemplo 100 megabits por segundo. Un ancho de banda alto no reduce la latencia. Capítulo 0
Anomalía (fenómeno): Un resultado incorrecto causado por la interferencia entre transacciones concurrentes, como una lectura sucia, una actualización perdida o un sesgo de escritura (write skew); los niveles de aislamiento se definen según las anomalías que evitan. Capítulo 7
Anonimización: Tratar los datos de modo que dejen de referirse a una persona identificable por cualquier medio que razonablemente pueda utilizarse; los datos verdaderamente anónimos quedan fuera del RGPD (GDPR). Capítulo 8
Antipatrón: Una solución de uso común que parece razonable pero que, de forma sistemática, causa más problemas de los que resuelve. Capítulo 5
Anycast: Anunciar la misma dirección IP desde muchas ubicaciones, de modo que el enrutamiento de internet entregue los paquetes de cada usuario en la ubicación más cercana que la anuncia. Capítulo 9
API (interfaz de programación de aplicaciones): Un conjunto definido de operaciones, entradas y salidas a través del cual un software usa otro, sin necesidad de saber cómo funciona por dentro. Capítulo 0
API del equipo: Todo lo que un equipo ofrece a otros equipos y espera de ellos: sus interfaces de código, su documentación, sus reglas de versionado, sus formas de trabajar, sus canales de comunicación y cómo pedirle trabajo. Capítulo 11
API del módulo: La parte pequeña y deliberadamente pública de un módulo que otros módulos pueden usar; todo lo demás es interno y puede cambiar libremente. Capítulo 5
API gateway (puerta de enlace de API): Un punto de entrada único delante de los servicios que se encarga de inquietudes transversales como TLS, autenticación, limitación de tasa (rate limiting) y enrutamiento. Capítulo 6
API web: API ofrecida a través de una red, normalmente mediante HTTP, para que programas en máquinas distintas, escritos en lenguajes distintos, puedan trabajar juntos. Capítulo 0
Aplicación de doce factores (twelve-factor app): Metodología de doce prácticas para construir aplicaciones web desplegables y escalables, escrita por Adam Wiggins en Heroku en 2011 y publicada como código abierto en 2024. Capítulo 10
Aplicación sin estado (stateless): Aplicación que no guarda datos por usuario en su propia memoria entre solicitudes, de modo que cualquier copia puede atender cualquier solicitud y pueden añadirse o retirarse copias libremente. Capítulo 5
Aprendizaje automático (machine learning): Construir una función a partir de ejemplos en lugar de reglas escritas a mano: se ajusta un modelo a los datos y luego se usa para hacer predicciones sobre entradas nuevas. Capítulo 12
Aprendizaje no supervisado: Aprendizaje automático sin etiquetas, en el que el modelo encuentra estructura por sí mismo, como grupos de clientes similares o transacciones inusuales. Capítulo 12
Aprendizaje por refuerzo: Aprendizaje automático en el que un agente realiza acciones y aprende de una señal de recompensa en lugar de a partir de respuestas correctas. Capítulo 12
Aprendizaje por refuerzo a partir de retroalimentación humana (RLHF): Etapa de entrenamiento en la que personas comparan respuestas del modelo, un modelo de recompensa aprende sus preferencias y el modelo se optimiza para puntuar bien según él. Capítulo 12
Aprendizaje supervisado: Aprendizaje automático a partir de ejemplos etiquetados, en el que cada entrada de entrenamiento viene con la respuesta correcta, como pagos marcados como fraudulentos o legítimos. Capítulo 12
Árbol de ataque: Un árbol cuya raíz es el objetivo de un atacante y cuyos hijos son las formas alternativas (OR) o combinadas (AND) de alcanzarlo, popularizado por Bruce Schneier en 1999. Capítulo 8
Árbol de utilidad: Árbol, procedente del ATAM, que refina la utilidad global en atributos de calidad y después en escenarios concretos, cada uno valorado según su importancia para el negocio y su dificultad técnica. Capítulo 2
arc42: Una plantilla gratuita de doce secciones para documentar y comunicar la arquitectura de software, creada por Gernot Starke y Peter Hruschka. Capítulo 4
Archivo: Una secuencia de bytes con nombre almacenada en un disco y gestionada por el sistema operativo, como una foto, una hoja de cálculo o un registro. Capítulo 0
Arquitectónicamente significativo: Describe una decisión o un requisito que es costoso de cambiar más adelante, afecta a muchas partes de un sistema o determina un atributo de calidad clave. Capítulo 1
Arquitectura basada en células: Ejecutar muchas copias completas e independientes (células) de un sistema, cada una al servicio de un subconjunto fijo de clientes, detrás de un enrutador ligero, de modo que un fallo afecte solo a una célula. Capítulo 10
Arquitectura basada en espacios: Estilo arquitectónico que atiende las solicitudes desde muchas unidades de procesamiento idénticas que guardan los datos en mallas replicadas en memoria y actualizan la base de datos de forma asíncrona, para que quede fuera de la ruta de la solicitud. Capítulo 6
Arquitectura basada en servicios: Estilo distribuido con unos pocos servicios de dominio de grano grueso desplegados por separado (normalmente de 4 a 12) que a menudo comparten una base de datos; bautizado por Mark Richards y Neal Ford. Capítulo 6
Arquitectura de microkernel: Estilo arquitectónico, también llamado arquitectura de plug-ins, en el que un pequeño sistema central proporciona el flujo de trabajo general y plug-ins independientes añaden o modifican comportamiento mediante contratos publicados. Capítulo 5
Arquitectura de referencia: Arquitectura plantilla para un dominio o una plataforma que asigna las funciones típicas a un conjunto estándar de partes, y que los proyectos adaptan en lugar de diseñar desde cero. Capítulo 5
Arquitectura de software: Las estructuras fundamentales de un sistema de software y las decisiones importantes que les dieron forma: sus partes principales, cómo se relacionan, sus propiedades importantes y los principios que guían cómo se construye y evoluciona. Capítulo 1
Arquitectura de soluciones: La arquitectura de la solución a un problema de negocio concreto, que a menudo abarca varias aplicaciones, proveedores y equipos, como un nuevo proceso de reclamaciones en línea para una aseguradora. Capítulo 1
Arquitectura de transición: Software temporal, como capas de enrutamiento, adaptadores y tareas de sincronización, construido solo para que los sistemas antiguos y nuevos coexistan durante una migración y que se elimina cuando esta termina. Capítulo 11
Arquitectura dirigida por eventos: Un estilo en el que los componentes se comunican publicando eventos sobre cosas que han ocurrido y reaccionando a los eventos publicados por otros, normalmente a través de un intermediario. Capítulo 6
Arquitectura distribuida: Una arquitectura formada por varias unidades desplegadas por separado que cooperan enviándose mensajes a través de una red. Capítulo 5
Arquitectura empresarial: La arquitectura a nivel de toda una organización: cómo encajan sus capacidades de negocio, su información, sus aplicaciones y su tecnología, y cómo cambian con el tiempo. Capítulo 1
Arquitectura en capas: Estilo que organiza los componentes en capas horizontales, cada una con un único papel técnico, donde cada capa usa solo las capas que tiene debajo. Capítulo 5
Arquitectura evolutiva: Una arquitectura que admite cambios guiados e incrementales en múltiples dimensiones, con funciones de aptitud que proporcionan la guía (Ford, Parsons, Kua y Sadalage). Capítulo 11
Arquitectura monolítica: Arquitectura en la que toda la aplicación se construye y despliega como una sola unidad, sea cual sea su estructura interna. Capítulo 5
Arquitectura orientada a servicios (SOA): Enfoque, dominante en las empresas desde principios de los años 2000, que expone las capacidades de negocio como servicios compartidos con contratos explícitos, normalmente conectados mediante un bus de servicios empresarial. Capítulo 6
Arquitectura sociotécnica: Diseñar a la vez la estructura del software y la estructura de los equipos, porque cada una da forma a la otra. La idea se remonta a la investigación sobre sistemas sociotécnicos del Tavistock Institute, que empezó con el estudio de 1951 de Eric Trist y Ken Bamforth sobre la minería del carbón. Capítulo 11
Arranque en frío (cold start): El retraso adicional que se produce cuando una plataforma serverless debe crear e inicializar una nueva instancia de función antes de atender una solicitud, desde decenas de milisegundos hasta varios segundos. Capítulo 6
Ascensor del arquitecto (architect elevator): La imagen de Gregor Hohpe del arquitecto como alguien que se desplaza entre el ático de una organización (la estrategia y los directivos) y su sala de máquinas (el código y la infraestructura), conectando ambos. Capítulo 11
AsyncAPI: Una especificación legible por máquinas para describir API dirigidas por mensajes: los canales, las operaciones que envían o reciben en ellos y los esquemas de los mensajes. Capítulo 6
ATAM (Architecture Tradeoff Analysis Method): El método de evaluación basado en escenarios del SEI (Kazman, Klein y Clements, 2000). En nueve pasos a lo largo de dos reuniones, relaciona los impulsores de negocio y los escenarios priorizados con los enfoques arquitectónicos, y produce riesgos, no riesgos, puntos de sensibilidad, puntos de compromiso y temas de riesgo. Capítulo 11
Ataque a la cadena de suministro de software: Ataque que compromete algo que consume una organización, como una dependencia, una herramienta de compilación, una actualización o un registro, para llegar a esa organización y a otras situadas aguas abajo. Capítulo 8
Atributo de calidad: Propiedad medible de un sistema que indica lo bien que hace su trabajo, como el rendimiento, la disponibilidad, la seguridad o la modificabilidad. El Capítulo 2 los trata en profundidad. Capítulo 1
Autenticación: Verificar que un usuario o sistema es quien o lo que dice ser, por ejemplo, mediante una contraseña, una passkey o un certificado. Capítulo 8
Autenticación multifactor (MFA): Autenticación que exige dos o más tipos distintos de factor: algo que sabes, algo que tienes y algo que eres. Capítulo 8
Autoescalado: Cambiar automáticamente el número de instancias a medida que cambia la carga, de forma reactiva a partir de una métrica, según un calendario o de forma predictiva a partir de una previsión. Capítulo 9
Autoridad de certificación (CA): Una organización o un sistema que emite certificados digitales firmándolos, garantizando así que una clave pública pertenece a un servidor, una persona o una carga de trabajo determinados. Capítulo 8
Autorización: Decidir si un usuario o sistema autenticado tiene permiso para realizar una acción concreta sobre un recurso concreto. Capítulo 8

B

Back pressure (contrapresión): Una forma de que un consumidor lento haga que un productor rápido reduzca su ritmo, en lugar de dejar que los búferes y las colas crezcan sin límite. Capítulo 5
Backend como servicio (BaaS): Servicios de terceros totalmente gestionados, como autenticación, bases de datos, almacenamiento y mensajería, que sustituyen componentes del lado del servidor que una organización tendría que construir y operar por su cuenta. Capítulo 6
Backend for frontend (BFF): Una API del lado del servidor construida para un tipo de cliente, como la app móvil, de modo que cada cliente obtenga operaciones y datos adaptados a sus propias necesidades. Capítulo 3
Backend for frontend (BFF): Un backend ligero construido para un tipo de cliente, como la app móvil, que llama a los servicios y adapta sus datos para ese cliente. Capítulo 6
Backfill (relleno de datos): Rellenar una nueva columna o tabla con valores para las filas existentes, normalmente en lotes pequeños para no perturbar el sistema en funcionamiento. Capítulo 7
Backoff exponencial: Esperar cada vez más entre reintentos sucesivos, normalmente duplicando el retraso cada vez hasta un límite, para que un servicio con dificultades tenga tiempo de recuperarse. Capítulo 9
Balanceador de carga: Componente que recibe las solicitudes entrantes y las reparte entre varios servidores, omitiendo los que no están en buen estado. Capítulo 0
Balanceador de carga de capa 4: Balanceador de carga que trabaja en el nivel de transporte (TCP o UDP) y reenvía conexiones o paquetes sin leer la solicitud HTTP que contienen. Capítulo 9
Balanceador de carga de capa 7: Balanceador de carga que entiende el protocolo de aplicación, normalmente HTTP, de modo que puede enrutar cada solicitud por ruta, cabecera o cookie, terminar TLS y reintentar. Capítulo 9
Balanceo de carga global: Distribuir a los usuarios entre centros de datos o regiones, normalmente mediante respuestas DNS que varían según la ubicación y el estado, o mediante enrutamiento anycast. Capítulo 9
Bandeja de salida transaccional (transactional outbox): Patrón en el que un servicio escribe los mensajes salientes en una tabla de bandeja de salida (outbox) en la misma transacción local que su cambio de negocio; más tarde un retransmisor los publica, lo que da una entrega al menos una vez sin transacción distribuida. Capítulo 6
Base de datos: Una colección organizada de datos almacenada de modo que pueda consultarse, actualizarse y mantenerse coherente, normalmente gestionada por un sistema de gestión de bases de datos. Capítulo 0
Base de datos de grafos: Una base de datos que almacena los elementos como nodos y las relaciones entre ellos como aristas, de modo que recorrer cadenas de conexiones es rápido. Capítulo 0
Base de datos de integración: Una base de datos compartida por varias aplicaciones, que se integran a través de ella leyendo y escribiendo las mismas tablas. Martin Fowler (2004) la desaconseja porque acopla profundamente las aplicaciones. Capítulo 7
Base de datos de series temporales: Base de datos optimizada para mediciones con marca de tiempo que llegan en orden, con compresión, reducción de resolución (downsampling) y eliminación barata de datos antiguos. Capítulo 7
Base de datos documental: Una base de datos NoSQL que almacena cada registro como un documento autónomo, normalmente de tipo JSON, que puede contener datos anidados y no necesita compartir un esquema fijo. Capítulo 0
Base de datos gestionada: Servicio de base de datos operado por un proveedor de nube, que se encarga de la instalación, los parches, las copias de seguridad y la conmutación por error (failover), mientras el cliente gestiona el esquema, las consultas y el acceso. Capítulo 0
Base de datos por servicio: La regla de que cada servicio es propietario de sus datos y ningún otro servicio los lee ni los escribe directamente; los demás usan la API del propietario o sus eventos. Capítulo 6
Base de datos relacional: Base de datos que guarda los datos en tablas de filas y columnas y vincula las tablas mediante claves. Se consulta con SQL. Capítulo 0
Base de datos vectorial: Almacén de embeddings (listas de números que representan significado) que encuentra los elementos más similares a una consulta, normalmente con índices de vecinos más cercanos aproximados. Capítulo 7
Base jurídica: Uno de los seis fundamentos del artículo 6 del RGPD (GDPR) (consentimiento, contrato, obligación legal, intereses vitales, misión de interés público, intereses legítimos) en los que debe basarse el tratamiento de datos personales. Capítulo 8
Biblioteca: Código reutilizable escrito por otra persona al que tu código llama cuando lo necesita, como una biblioteca para fechas o para enviar correo electrónico. Capítulo 0
Big design up front (BDUF, gran diseño inicial): Un enfoque en el que la arquitectura y el diseño se completan en detalle antes de que empiece la implementación. Capítulo 1
Bit: Un dígito binario, 0 o 1: la unidad de información más pequeña que almacena una computadora. Capítulo 0
Bitácora de decisiones (decision log): La colección ordenada de los ADR de un sistema, normalmente con un índice que enumera el número, el título, el estado y la fecha de cada registro. Capítulo 4
Bloque de construcción (building block): En arc42, cualquier parte de la estructura estática de un sistema, como un subsistema, un servicio, un componente o un módulo, que se muestra en la vista de bloques de construcción. Capítulo 4
Bloqueo pesimista: Prevenir los conflictos bloqueando las filas cuando se leen (por ejemplo, con SELECT ... FOR UPDATE), de modo que otras transacciones esperan hasta que se libera el bloqueo. Capítulo 7
BM25: Una función clásica de clasificación por palabras clave que puntúa los documentos según la frecuencia con que contienen los términos de la consulta, dando más peso a los términos poco frecuentes y normalizando según la longitud del documento. Capítulo 12
Branch by abstraction (ramificación por abstracción): Una técnica para cambios grandes dentro de una misma base de código: poner una abstracción delante de la parte que se va a sustituir, trasladar a ella a quienes la llaman, construir la nueva implementación detrás, cambiar a ella y eliminar la antigua, manteniendo el sistema listo para lanzarse en todo momento. Capítulo 11
Bucle de reconciliación: El ciclo sin fin de un controlador que observa el estado real, lo compara con el estado deseado y actúa para eliminar la diferencia. Capítulo 10
Bug: Un error en el software que hace que se comporte de forma distinta a la prevista, desde un bloqueo hasta una respuesta silenciosamente incorrecta. Capítulo 0
Bug bounty (programa de recompensas): Un programa que paga a investigadores externos por informar de vulnerabilidades de seguridad válidas mediante un proceso acordado. Capítulo 8
Build once, deploy many (compilar una vez, desplegar muchas): La regla de que un cambio se compila en un único artefacto inmutable exactamente una vez, y ese mismo artefacto se promueve por todos los entornos, cambiando solo la configuración. Capítulo 10
Build, release, run (construcción, lanzamiento, ejecución): La separación estricta entre convertir el código en un artefacto (construcción), combinarlo con la configuración de un entorno (lanzamiento) y ejecutarlo (ejecución). Capítulo 10
Bulkhead (mamparo): Dividir recursos como grupos de hilos, grupos de conexiones o instancias, para que un fallo o una sobrecarga en una parte no pueda consumir los recursos de las demás. Capítulo 9
Bus de servicios empresarial (ESB): Middleware situado en el centro de la SOA clásica que enruta, transforma y media en los mensajes entre servicios y que a menudo también ejecuta procesos de negocio. Capítulo 6
Búsqueda aproximada de vecinos más cercanos: Encontrar rápidamente los vectores más cercanos a un vector de consulta usando un índice que sacrifica un poco de exhaustividad (recall) a cambio de grandes ganancias de velocidad. Capítulo 12
Búsqueda híbrida: Una recuperación que combina resultados por palabras clave (dispersos) y por embeddings (densos), normalmente fusionando sus clasificaciones, para obtener las ventajas de ambos. Capítulo 12
Byte: Un grupo de ocho bits, capaz de contener 256 valores distintos. Los tamaños de los archivos y de la memoria se cuentan en bytes (kilobytes, megabytes, gigabytes). Capítulo 0
Bytecode: Instrucciones compactas para una máquina virtual en lugar de para una CPU real. Java y Python compilan el código fuente a bytecode, que luego sus entornos de ejecución ejecutan en cualquier máquina compatible. Capítulo 0

C

Caché: Una copia de datos guardada en un lugar al que se accede más rápido, para que las solicitudes repetidas eviten trabajo lento. Cambia memoria adicional, y el riesgo de datos desactualizados, por velocidad. Capítulo 0
Caché de prompts (prompt caching): Reutilización del estado calculado de un modelo para un prefijo de prompt idéntico visto recientemente, lo que reduce el costo y la latencia de la parte repetida. Capítulo 12
Caché semántica: Devolver una respuesta almacenada cuando una consulta nueva tiene un significado similar a otra anterior, según la comparación de sus embeddings, sin llamar al modelo. Capítulo 12
Cache stampede (estampida de caché): Una oleada de solicitudes que fallan en la caché en el mismo momento, normalmente cuando caduca un elemento popular, y llegan todas a la vez a la fuente más lenta; está estrechamente relacionada con el problema de la manada atronadora (thundering herd). Capítulo 7
Caché write-behind: Patrón de caché en el que las escrituras se confirman en cuanto llegan a la caché y se escriben en el almacén subyacente más tarde, en segundo plano; también se llama write-back. Capítulo 7
Caché write-through: Patrón de caché en el que cada escritura va a la caché y al almacén subyacente antes de confirmarse, de modo que la caché nunca es más antigua que el almacén. Capítulo 7
Cache-aside: Un patrón de caché en el que la propia aplicación consulta la caché, carga desde la base de datos cuando hay un fallo de caché y coloca el resultado en la caché; también se denomina carga diferida (lazy loading). Capítulo 7
Calendario de conservación: Lista documentada de cuánto tiempo se conserva cada categoría de datos, por qué y qué ocurre con ellos al final de ese periodo. Capítulo 8
Calidad en uso: La calidad que un producto ofrece a las personas en un contexto de uso específico (si es beneficioso, está libre de riesgos y es aceptable). Desde 2023 tiene su propia norma, ISO/IEC 25019. Capítulo 2
Cambio compatible hacia atrás: Un cambio en una interfaz o un esquema que los consumidores existentes pueden soportar sin modificaciones, como añadir un campo opcional. Eliminar o renombrar un campo es un cambio incompatible (breaking change). Capítulo 6
Cambio incompatible (breaking change): Un cambio en una API que hace que el código cliente existente y correcto deje de funcionar, como renombrar o eliminar un campo. Capítulo 0
Camino dorado (golden path o paved road): Una forma definida, con soporte y documentada de realizar una tarea común, como crear un nuevo servicio, que es la más fácil pero no la única permitida. Capítulo 10
Camino pavimentado (paved road, golden path): Una forma predeterminada, con soporte y bien documentada, de construir y ejecutar software, como una plantilla de servicio con el registro de logs, la seguridad y el despliegue ya configurados, que los equipos pueden abandonar cuando tienen un buen motivo. Capítulo 11
Canary release (lanzamiento canario): Enviar primero una pequeña parte del tráfico real a una nueva versión, comparar su comportamiento con el de la versión anterior y ampliar esa parte solo si está sana. Capítulo 10
Capa: Grupo de componentes con la misma responsabilidad técnica, que ofrece servicios a la capa superior y usa la capa inferior. Capítulo 5
Capa abierta: Capa que la capa superior puede saltarse, normalmente una capa de servicios compartidos que solo necesitan algunas solicitudes. Capítulo 5
Capa anticorrupción: Una capa de traducción, procedente del diseño guiado por el dominio, que convierte entre el modelo de otro sistema y el tuyo, para que los conceptos y peculiaridades del otro modelo no se filtren en tu código. Capítulo 11
Capa anticorrupción: Una capa de traducción que construye un contexto descendente para que el modelo de otro contexto o sistema no pueda filtrarse en el suyo. Capítulo 5
Capa cerrada: Una capa por la que debe pasar toda solicitud: la capa superior no puede saltársela para llamar directamente a una capa inferior. Capítulo 5
Capacidad de prueba (testabilidad): La facilidad con que puede demostrarse, mediante pruebas, que un sistema o componente se comporta como se pretende, lo que depende de poder controlar sus entradas y su estado y observar sus salidas. Capítulo 2
Capacidad spot: Capacidad sobrante de la nube vendida con un gran descuento que el proveedor puede recuperar con poca antelación; solo es adecuada para trabajo que tolera interrupciones. Capítulo 10
Capas de aislamiento: La propiedad de que un cambio dentro de una capa no se propaga a otras capas mientras su interfaz se mantenga igual; depende de que las capas sean cerradas. Capítulo 5
Captura de datos de cambios (CDC): Leer el propio registro de cambios o de replicación de una base de datos para transmitir a otros sistemas cada inserción, actualización y eliminación confirmada. Debezium es una plataforma de CDC de código abierto muy utilizada. Capítulo 6
Característica de arquitectura: Término de Richards y Ford para un atributo de calidad que la arquitectura debe soportar, como la escalabilidad, la desplegabilidad o la tolerancia a fallos. Capítulo 5
Carbono incorporado: Los gases de efecto invernadero emitidos al fabricar, transportar y desechar el hardware, a diferencia de las emisiones de la electricidad que consume mientras funciona. Capítulo 11
Cardinalidad: El número de valores distintos que puede tomar un campo; en las métricas, el número de combinaciones distintas de etiquetas, cada una de las cuales se convierte en una serie temporal independiente que hay que almacenar. Capítulo 9
Carga cognitiva: La cantidad de esfuerzo mental que una persona o un equipo debe dedicar para entender un sistema y trabajar en él; Team Topologies la utiliza para dimensionar las responsabilidades de los equipos. Capítulo 10
Carga cognitiva del equipo: La cantidad total de conocimiento y esfuerzo mental que necesita un equipo para construir, operar y cambiar las partes de un sistema que le pertenecen. Cuando supera la capacidad del equipo, la calidad y la velocidad caen. Capítulo 3
Cascada de modelos: Diseño que envía primero una solicitud a un modelo más barato y solo la escala a uno más capaz cuando una comprobación indica que la primera respuesta no es lo bastante buena. Capítulo 12
Caso de negocio (business case): Un argumento estructurado a favor de una inversión que expone el problema, las opciones (incluida no hacer nada), sus costos, beneficios y riesgos, y una recomendación que los responsables de decidir pueden comparar con otros usos del dinero. Capítulo 11
CBAM (Cost Benefit Analysis Method): Un método del SEI que se basa en el ATAM y estima el beneficio de cada estrategia arquitectónica a partir de la utilidad que añade a los escenarios priorizados, dividiéndolo por su costo para comparar la relación entre valor y costo. Capítulo 11
Centro de datos: Un edificio diseñado para alojar muchos servidores con alimentación eléctrica fiable, refrigeración, seguridad física y conexiones de red. Capítulo 0
Chargeback (imputación de costos): Cargar al presupuesto de cada equipo o producto los costos que se le atribuyen, para que el gasto aparezca en sus propias cuentas. Capítulo 10
Chunking (fragmentación): Dividir los documentos en pasajes lo bastante pequeños para indexarlos, recuperarlos y colocarlos en un prompt, idealmente siguiendo la propia estructura de los documentos. Capítulo 12
Ciclo de dependencias: Un bucle en el que los módulos dependen unos de otros directa o indirectamente, de modo que ninguno puede entenderse, probarse ni lanzarse por separado. Capítulo 1
Cifrado de sobre (envelope encryption): Cifrar los datos con una clave de datos y luego cifrar (envolver) esa clave de datos con una clave de cifrado de claves guardada en un KMS, de modo que los datos masivos nunca viajan al KMS y las claves pueden rotarse con poco costo. Capítulo 8
Cifrado simétrico: Cifrado en el que la misma clave secreta cifra y descifra, como AES; es rápido, por lo que se usa para grandes volúmenes de datos. Capítulo 8
Circuit breaker (disyuntor): Un envoltorio alrededor de las llamadas a una dependencia que, tras suficientes fallos, deja de llamarla durante un tiempo y falla rápidamente, y luego deja pasar llamadas de prueba para comprobar si se ha recuperado (Michael Nygard, 2007). Capítulo 9
Clase y objeto: Una clase es una plantilla que agrupa datos con las funciones (métodos) que trabajan con ellos; un objeto es una instancia creada a partir de esa plantilla, como la cuenta de un cliente concreto. Capítulo 0
Clave de API: Una cadena secreta larga que identifica a la aplicación que llama ante una API. Cualquiera que tenga la clave puede actuar como esa aplicación, por lo que debe mantenerse en secreto. Capítulo 0
Clave de idempotencia: Un valor único que un cliente envía con una solicitud no idempotente, como POST, para que el servidor pueda reconocer un reintento de la misma operación y devolver el resultado original en lugar de hacer el trabajo dos veces. Capítulo 6
Clave foránea: Una columna de una tabla que contiene la clave primaria de una fila de otra tabla, vinculando ambas. La base de datos puede rechazar valores que no apunten a nada. Capítulo 0
Clave primaria: Columna, o conjunto de columnas, cuyo valor identifica de forma única cada fila de una tabla, como customer_id. Capítulo 0
Código de estado HTTP: Un número de tres dígitos presente en cada respuesta HTTP que indica cómo ha ido la solicitud: 2xx éxito, 3xx redirección, 4xx un problema con la solicitud, 5xx un problema en el servidor. Capítulo 0
Código de Ética de la ACM (ACM Code of Ethics): El Código de Ética y Conducta Profesional de la Association for Computing Machinery, actualizado en 2018, cuyos principios incluyen contribuir a la sociedad, evitar daños, la honestidad, la equidad, la privacidad y la confidencialidad. Capítulo 11
Código fuente: El texto legible por personas de un programa, escrito en un lenguaje de programación como Python o Java, que luego se compila o se interpreta para que una computadora pueda ejecutarlo. Capítulo 0
Código máquina: Instrucciones codificadas como números que una familia concreta de CPU puede ejecutar directamente. El código máquina de una familia (por ejemplo, x86-64) no se ejecuta en otra (por ejemplo, Arm). Capítulo 0
Código muerto: Código que ya no debería ejecutarse pero que sigue presente en el sistema desplegado, donde puede activarse por error. Capítulo 1
Cohesión: Hasta qué punto el contenido de una parte de un sistema está relacionado entre sí. Una cohesión alta significa que un módulo hace un único trabajo claro. Capítulo 0
Cola (canal punto a punto): Canal de mensajería en el que cada mensaje se entrega exactamente a uno de los consumidores que leen de él, de modo que varias instancias pueden repartirse el trabajo. Capítulo 6
Cola de mensajes: Software que almacena los mensajes de los emisores hasta que los receptores están listos para procesarlos, de modo que no es necesario que ambos estén en ejecución o sean rápidos al mismo tiempo. Capítulo 0
Cola de mensajes fallidos (dead-letter queue): Un lugar aparte donde se aparcan para su inspección los mensajes cuyo procesamiento falla repetidamente, para que no bloqueen el resto del flujo. Capítulo 5
Colisión de datos: En una caché en memoria replicada, dos unidades que actualizan el mismo elemento antes de que se haya propagado la replicación de la primera actualización, de modo que una actualización sobrescribe la otra. Capítulo 6
Comando: Un mensaje que pide a un manejador concreto que haga algo, como AuthorisePayment. A diferencia de un evento, puede rechazarse. Capítulo 6
Commit: Una instantánea guardada de los cambios en el control de versiones, con un autor, una marca de tiempo y un mensaje que explica el cambio. Capítulo 0
Compatibilidad hacia adelante: Un cambio de esquema es compatible hacia adelante cuando el código que usa el esquema antiguo todavía puede leer datos escritos con el nuevo, normalmente ignorando los campos que no conoce. Capítulo 7
Compatibilidad hacia atrás: Un cambio de esquema es compatible hacia atrás cuando el código que usa el nuevo esquema todavía puede leer datos escritos con el antiguo. Capítulo 7
Compilación reproducible (reproducible build): Compilación que produce una salida idéntica bit a bit a partir del mismo código fuente y las mismas entradas, de modo que cualquiera pueda recompilar y comprobar que un artefacto publicado no ha sido manipulado. Capítulo 8
Compilador: Un programa que traduce el código fuente a otra forma, como código máquina o bytecode, antes de que el programa se ejecute. Capítulo 0
Complejidad accidental: Complejidad introducida por la forma en que se construye una solución (herramientas, estructura, soluciones provisionales) y no por el problema. En principio, puede eliminarse. Capítulo 3
Complejidad ciclomática: La medida de Thomas McCabe de 1976 del número de caminos independientes a través de un fragmento de código, calculada a partir de su grafo de flujo de control; en el código sencillo equivale al número de decisiones más uno. Capítulo 3
Complejidad esencial: Complejidad que pertenece al propio problema, como las reglas reales de los impuestos o los seguros, y que no puede eliminarse sin cambiar lo que hace el sistema. Capítulo 3
Componente: Una unidad que existe cuando el sistema se ejecuta, como un servicio, un proceso o una base de datos, y que interactúa con otros componentes a través de conectores. Capítulo 1
Componente (C4): En el modelo C4, un grupo de funcionalidades relacionadas detrás de una interfaz clara, que se ejecuta dentro de un contenedor y se despliega con él. Capítulo 4
Componente de vista: En ISO/IEC/IEEE 42010:2022, una parte de una vista, como un diagrama, una tabla o un modelo, regida por un tipo de modelo. La edición de 2011 lo llamaba modelo de arquitectura. Capítulo 4
Comprobación de estado (health check): Una prueba periódica, como una solicitud HTTP a un endpoint de estado, que un balanceador de carga o un orquestador usa para decidir si una instancia debe recibir tráfico o reiniciarse. Capítulo 9
Compromiso: Elección en la que obtener un beneficio implica aceptar un costo o renunciar a otro beneficio, como una entrega más rápida a cambio de un costo de operación más alto. Capítulo 1
Compuerta de gobernanza (gate): Un punto de control en el que el trabajo se detiene hasta que alguien lo aprueba, como el visto bueno de una junta de revisión antes de la construcción o el lanzamiento. Capítulo 11
Computación consciente del carbono: Ejecutar software de modo que haga más cuando la electricidad es más limpia y menos cuando es más contaminante, desplazando el trabajo en el tiempo o en la ubicación, o modulando la demanda. Capítulo 11
Computación en la nube: Alquilar recursos informáticos (servidores, almacenamiento, bases de datos y otros servicios) a través de internet, bajo demanda, y pagar por lo que usas. Capítulo 0
Comunicación asíncrona: Una interacción en la que el emisor entrega un mensaje a un intermediario, como un intermediario de mensajes (message broker), y continúa sin esperar; el receptor lo procesa cuando está listo. Capítulo 6
Comunicación síncrona: Interacción en la que quien llama envía una solicitud y espera la respuesta antes de continuar, como en una llamada telefónica. Ambas partes deben estar disponibles en el mismo momento. Capítulo 6
Concepto transversal: Una regla o solución que se aplica a muchas partes de un sistema, como la seguridad, el manejo de errores, el registro o la persistencia. Capítulo 4
Conector: El mecanismo de tiempo de ejecución mediante el que interactúan los componentes: una llamada HTTP, una cola de mensajes, una base de datos compartida, un flujo de eventos o una llamada a función. Capítulo 1
Confirmación en dos fases (two-phase commit, 2PC): Protocolo que hace que varios participantes confirmen o aborten juntos: un coordinador pide primero a todos que se preparen y voten, y después comunica a todos el resultado. Los participantes que votaron sí quedan bloqueados si el coordinador falla. Capítulo 6
Conjunto dorado (golden set): Una colección seleccionada y versionada de entradas de prueba con el resultado esperado, la respuesta de referencia o la rúbrica de puntuación de cada una, que se usa para evaluar un sistema de IA. Capítulo 12
Connascence: Dos elementos son connascentes si un cambio en uno exigiría un cambio en el otro para que el sistema siga siendo correcto. Es una forma más detallada de describir el acoplamiento, introducida por Meilir Page-Jones. Capítulo 3
Connascence dinámica: Connascence que solo se manifiesta cuando el programa se ejecuta, como la dependencia del orden o los tiempos de ejecución, de valores relacionados o de que dos partes compartan la misma instancia de un objeto. Capítulo 3
Connascence estática: Connascence visible en el código fuente sin ejecutarlo, como el acuerdo sobre un nombre, un tipo, el significado de un valor, el orden de los parámetros o un algoritmo. Capítulo 3
Consenso: Una regla de decisión en la que el grupo continúa hasta que todos están activamente de acuerdo con la propuesta, o al menos la apoyan; es inclusiva pero lenta, y propensa al bloqueo en grupos grandes. Capítulo 11
Consenso aproximado (rough consensus): Decisión alcanzada cuando todas las objeciones se han considerado y respondido, aunque no necesariamente atendido; descrito en el RFC 7282 del IETF. Capítulo 4
Consistencia causal: Un modelo de consistencia en el que todos ven en el mismo orden las operaciones relacionadas causalmente (una pudo haber influido en la otra); las operaciones concurrentes no relacionadas pueden verse en órdenes distintos. Capítulo 6
Consistencia eventual: Una garantía de que las copias de unos datos que han dejado de actualizarse convergerán al mismo valor al cabo de un tiempo, mientras que entretanto los lectores pueden ver valores obsoletos. Capítulo 6
Consistencia secuencial: Modelo de consistencia en el que todos los clientes ven las operaciones en un único orden acordado que conserva el orden propio de cada cliente, pero ese orden no tiene por qué coincidir con el tiempo real. Capítulo 6
Consumidor idempotente: Un receptor de mensajes que registra qué mensajes ha procesado, en la misma transacción que sus efectos, de modo que los duplicados no cambian nada. Capítulo 6
Consumidores competidores: Un patrón en el que varios workers leen de la misma cola y cada mensaje lo procesa solo uno de ellos, de modo que el rendimiento (throughput) aumenta al añadir workers. Capítulo 9
Contador (counter): Una métrica cuyo valor solo aumenta (o vuelve a cero al reiniciar), como el total de solicitudes atendidas; normalmente se observa su tasa de aumento. Capítulo 9
Contenedor: Una aplicación empaquetada con sus bibliotecas y su configuración, que se ejecuta como un proceso aislado que comparte el kernel del sistema operativo del host. Es más ligero y arranca más rápido que una máquina virtual. Capítulo 0
Contenedor (C4): En el modelo C4, una unidad que se puede ejecutar o desplegar por separado y que ejecuta código o almacena datos, como una aplicación web, una app móvil, un servicio o una base de datos. No es un contenedor Docker. Capítulo 4
Contenedores como servicio (CaaS): Un servicio en la nube que ejecuta imágenes de contenedor por ti, ya sea como Kubernetes gestionado o como una plataforma de contenedores serverless en la que nunca ves las máquinas. Capítulo 10
Contexto delimitado (bounded context): Un límite explícito dentro del cual un modelo de dominio y su lenguaje ubicuo se aplican de forma coherente; fuera de él, las mismas palabras pueden significar otra cosa. Capítulo 5
Contramedida de saga: Técnica de diseño que reduce las anomalías causadas por la falta de aislamiento de las sagas, como un bloqueo semántico (un estado PENDING), las actualizaciones conmutativas o volver a leer un valor antes de actualizarlo. Capítulo 6
Contrato de API: La promesa documentada que hace una API: qué solicitudes acepta, qué devuelve cada una, qué errores pueden producirse y qué no cambiará sin previo aviso. Capítulo 0
Contrato de datos: Un acuerdo explícito y versionado entre el propietario de unos datos y sus consumidores que abarca el esquema, el significado, la calidad, la actualidad, la propiedad y cómo se anuncian los cambios. Capítulo 7
Contrato de plug-in: La interfaz publicada entre un sistema central y sus plug-ins: las operaciones, los tipos de datos, el comportamiento ante errores y la versión que ambas partes acuerdan. Capítulo 5
Contrato dirigido por el consumidor: Un contrato construido a partir de lo que cada consumidor usa realmente de la API de un proveedor; el proveedor ejecuta en su propia compilación las expectativas de todos sus consumidores, de modo que sabe qué cambios romperían a quién. Capítulo 6
Control de acceso basado en atributos (ABAC): Decidir el acceso evaluando una política sobre atributos del usuario, el recurso, la acción y el contexto, como el país, la clasificación de los datos o la hora del día. Capítulo 8
Control de acceso basado en relaciones (ReBAC): Decidir el acceso a partir de las relaciones entre usuarios y objetos (propietario de, miembro de, trabaja en), almacenadas como un grafo; Zanzibar de Google (2019) es el ejemplo más conocido. Capítulo 8
Control de acceso basado en roles (RBAC): Conceder permisos a roles y roles a usuarios, de modo que el acceso se gestiona asignando a las personas roles como agente de soporte o gerente de restaurante. Capítulo 8
Control de concurrencia multiversión (MVCC): Técnica en la que las escrituras crean nuevas versiones de las filas en lugar de sobrescribirlas, de modo que los lectores ven una instantánea coherente sin bloquear a los escritores. Capítulo 7
Control de concurrencia optimista: Detectar los conflictos en lugar de prevenirlos: una escritura solo tiene éxito si un número de versión o una marca de tiempo no ha cambiado desde que se leyeron los datos; de lo contrario, quien escribe lo reintenta. Capítulo 7
Control de versiones: Sistema que registra cada cambio en un conjunto de archivos, quién lo hizo y por qué, para que las personas puedan trabajar en paralelo, revisar los cambios y volver a cualquier versión anterior. Capítulo 0
Controles hipermedia (HATEOAS): Enlaces en una respuesta de una API que indican al cliente qué acciones puede realizar a continuación, de modo que el cliente sigue enlaces en lugar de construir las URL por sí mismo. Es el nivel 3 del modelo de madurez de Richardson. Capítulo 6
Cooldown (ventana de estabilización): Un periodo posterior a una acción de escalado durante el cual el autoescalador espera antes de volver a actuar, para que pueda medirse el efecto del último cambio. Capítulo 9
Coordinador del incidente (incident commander): La persona que coordina la respuesta a un incidente: fija prioridades, asigna funciones y toma decisiones, en lugar de arreglar las cosas personalmente. Capítulo 9
Copia de seguridad: Una copia de los datos guardada por separado del original para poder restaurarla tras una pérdida, corrupción o eliminación. Capítulo 0
Copia de seguridad inmutable: Una copia de seguridad que no puede modificarse ni eliminarse antes de que termine su periodo de retención, ni siquiera por un administrador, lo que la protege del ransomware y de personas internas malintencionadas. Capítulo 8
Coreografía: Coordinación de un proceso de varios pasos mediante participantes que reaccionan a los eventos de los demás, sin que ningún componente esté al mando. Capítulo 6
Correspondencia: Una relación registrada entre elementos de una descripción de arquitectura, por ejemplo, entre un contenedor en una vista y el servidor en el que se ejecuta en otra. Capítulo 4
Costo de cambio: El esfuerzo, el dinero y el riesgo totales necesarios para pasar de una tecnología o un proveedor a otro. Capítulo 10
Costo del cambio: El esfuerzo, el dinero, el tiempo y el riesgo necesarios para modificar una decisión una vez que se ha construido trabajo sobre ella. Capítulo 1
Costo del retraso: El valor que se pierde por cada unidad de tiempo en que un trabajo no se entrega; Don Reinertsen lo popularizó como forma de priorizar el trabajo con criterios económicos. Capítulo 11
Costo unitario: El costo de operar un sistema dividido por una unidad de trabajo útil, como el costo por pedido o por usuario activo, para poder seguir la eficiencia a medida que crece el negocio. Capítulo 2
CPU (procesador): La unidad central de procesamiento: el chip que ejecuta las instrucciones de un programa, un paso sencillo cada vez, miles de millones de veces por segundo. Las CPU modernas tienen varios núcleos que trabajan en paralelo. Capítulo 0
CQRS: Segregación de responsabilidades de comando y consulta (command query responsibility segregation): usar modelos separados, y a menudo almacenes separados, para actualizar los datos y para leerlos. Capítulo 6
Crédito de servicio: Reembolso o descuento que se debe a un cliente según un SLA cuando el proveedor no alcanza un nivel de servicio prometido. Capítulo 9
Criptografía asimétrica (de clave pública): Criptografía con un par de claves: una clave pública que cualquiera puede tener y una clave privada que se mantiene en secreto; se usa para el intercambio de claves, las firmas digitales y los certificados. Capítulo 8
Crypto-shredding (destrucción criptográfica): Hacer ilegibles los datos destruyendo la clave de cifrado que los protege; se usa para borrar datos personales de registros y copias de seguridad que no pueden editarse. Capítulo 7
Cuanto de arquitectura (architecture quantum): Una parte de un sistema desplegable de forma independiente y con alta cohesión funcional, que incluye todo lo que necesita para ejecutarse, como su base de datos; el ámbito dentro del cual se aplica un mismo conjunto de características de arquitectura. Capítulo 5
Cuatro señales doradas: Latencia, tráfico, errores y saturación: las cuatro mediciones que el libro de SRE de Google recomienda supervisar en cualquier sistema orientado al usuario. Capítulo 9
Cubo de escalado: Modelo de Abbott y Fisher con tres formas de escalar: eje X (copias idénticas detrás de un balanceador de carga), eje Y (división por función) y eje Z (división por datos, por ejemplo por cliente). Capítulo 5
Cultura sin culpas (blameless): Un enfoque en el que las personas que participaron en un incidente pueden describir lo que hicieron y por qué sin miedo a ser castigadas, para que la organización aprenda cómo funciona realmente el sistema. Capítulo 9
CVE: Common Vulnerabilities and Exposures: el programa que asigna a cada vulnerabilidad conocida públicamente un identificador único, como CVE-2021-44228. Capítulo 8
CVSS: El Common Vulnerability Scoring System, mantenido por FIRST, que califica la gravedad de una vulnerabilidad conocida de 0 a 10; la versión 4.0 se publicó en 2023. Capítulo 8

D

Dark launching (lanzamiento oculto): Invocar un nuevo comportamiento del backend en producción con tráfico real ocultando sus resultados a los usuarios, para probar el rendimiento y la corrección antes de un lanzamiento visible. Capítulo 11
Data lake (lago de datos): Un almacén grande y barato, normalmente almacenamiento de objetos, que guarda datos sin procesar de muchas fuentes en su forma original para analizarlos más adelante. Capítulo 7
Data mesh: El enfoque de Zhamak Dehghani para los datos analíticos en el que los equipos de dominio son propietarios de sus datos y los publican como productos en una plataforma de autoservicio bajo una gobernanza federada. Capítulo 7
Datos personales: Según el RGPD (GDPR), toda información sobre una persona física (un individuo vivo) identificada o identificable, como un nombre, un número de identificación, datos de localización o un identificador en línea. Capítulo 8
Declaración Y (Y-statement): Registro de decisión en una sola frase, de Olaf Zimmermann: en el contexto de, ante, decidimos, y descartamos, para lograr, aceptando que. Capítulo 4
Defecto (fault): La causa de un problema, como un bug, un disco averiado o una configuración errónea. Un defecto puede permanecer latente hasta que algo lo activa. Capítulo 2
Defensa en profundidad: Superponer varios controles independientes para que un atacante que supere uno siga enfrentándose a otros, por ejemplo, una comprobación en el gateway, una comprobación en el servicio y el cifrado de los propios datos. Capítulo 8
Degradación elegante: Seguir proporcionando las funciones más importantes cuando falla parte de un sistema, en lugar de fallar por completo; por ejemplo, una tienda que sigue aceptando pedidos mientras las recomendaciones están fuera de servicio. Capítulo 2
Delegado confundido (confused deputy): Un programa que tiene autoridad y al que se engaña para que la use en nombre de alguien que carece de ella (Norm Hardy, 1988). Capítulo 12
Dependencia: Cualquier software que tu código necesita para funcionar, como una biblioteca, un framework u otro servicio. Si cambia o se rompe, tu código también puede romperse. Capítulo 0
Dependencia del proveedor (lock-in): El costo y la dificultad de dejar un proveedor, producto, plataforma o tecnología una vez que un sistema depende de él. Capítulo 10
Dependencia transitiva: Paquete que tu software usa indirectamente porque una de tus dependencias, o una de las suyas, depende de él. Capítulo 8
Deployment (Kubernetes): Un objeto de Kubernetes que declara cuántos pods idénticos de una aplicación sin estado deben ejecutarse y despliega las nuevas versiones de forma gradual mediante ReplicaSets. Capítulo 10
Derechos de decisión: Una declaración explícita de quién puede tomar qué decisiones, a quién hay que consultar y a quién hay que informar; fijarlos antes de un debate evita la mayoría de las disputas sobre el proceso. Capítulo 11
Deriva (drift): Un cambio gradual en las entradas de un sistema de IA, sus fuentes de conocimiento, el mundo o el propio modelo que hace que sus resultados sean menos precisos con el tiempo sin ningún cambio en el código. Capítulo 12
Deriva de configuración: Diferencias que se acumulan entre la configuración prevista en el código y la infraestructura real, normalmente por cambios manuales o actualizaciones parciales. Capítulo 10
Deriva de la arquitectura: Cambios realizados sin conocer la arquitectura prevista que, aunque no rompen reglas explícitas, alejan al sistema de ella y difuminan sus conceptos. Capítulo 1
Desarrollo basado en trunk (trunk-based development): Forma de trabajar en la que los desarrolladores integran cambios pequeños en una única rama principal compartida al menos una vez al día, en lugar de mantener ramas de funcionalidad de larga duración. Capítulo 10
Descarte de carga (load shedding): Rechazar deliberadamente algunas solicitudes, de forma barata y temprana, cuando un sistema está sobrecargado, para que las solicitudes que acepta sigan completándose a tiempo. Capítulo 9
Descomposición: Dividir un sistema en partes (módulos) y decidir de qué se encarga cada parte. El criterio usado para dividir importa más que el número de partes. Capítulo 3
Descripción de arquitectura: Un producto de trabajo (documentos, diagramas, modelos, registros de decisiones) que expresa una arquitectura. La arquitectura existe tanto si se describe como si no; la descripción es la forma en que las personas la comparten. Capítulo 1
Descripción del diseño de software (SDD): Documento que describe en detalle un diseño de software, cuyo contenido especifica la norma IEEE Std 1016-2009; habitual en proyectos regidos por contrato. Capítulo 4
Descubrimiento de servicios: Mecanismo, como un registro o DNS, mediante el cual los clientes encuentran las direcciones de red actuales de las instancias de servicio en buen estado. Capítulo 6
Descuento por compromiso de uso: Un precio más bajo a cambio de comprometerse con un nivel de uso o de gasto durante uno o tres años, como las instancias reservadas, los savings plans o los descuentos por compromiso de uso (committed use discounts). Capítulo 10
Desechabilidad (disposability): La propiedad de los procesos que arrancan rápido, se detienen de forma ordenada y pueden eliminarse en cualquier momento sin causar daño, de modo que pueden sustituirse y escalarse libremente. Capítulo 10
Desplegabilidad: La rapidez, la seguridad y la previsibilidad con que un cambio puede ponerse en producción, y retirarse de nuevo si es necesario. Capítulo 2
Desplegabilidad independiente: La capacidad de modificar y lanzar a producción un servicio sin modificar, probar ni lanzar ningún otro servicio al mismo tiempo. Capítulo 6
Despliegue azul-verde (blue-green): Ejecutar dos entornos de producción completos y cambiar todo el tráfico del antiguo (azul) al nuevo (verde) de una sola vez, manteniendo el antiguo listo para volver a él al instante. Capítulo 10
Despliegue continuo: Lanzar automáticamente a producción cada cambio que supera el pipeline, sin ningún paso de aprobación manual. Capítulo 0
Despliegue gradual (rolling deployment): Sustituir las instancias de un servicio unas pocas cada vez, de modo que la versión antigua y la nueva se ejecuten lado a lado hasta que todas las instancias ejecuten la nueva. Capítulo 10
Deuda arquitectónica: Deuda técnica en la estructura de un sistema, como límites equivocados, una base de datos compartida o dependencias cíclicas, que es costosa de saldar porque afecta a muchas partes. Capítulo 1
Deuda técnica: El costo futuro adicional de los cambios causado por atajos o por un diseño que ya no encaja, que se paga con un trabajo más lento y arriesgado hasta que se salda mejorando el diseño. Capítulo 1
DevOps: Una cultura y un conjunto de prácticas en los que desarrollo y operaciones trabajan como uno solo, compartiendo la responsabilidad de construir, lanzar y operar el software, con el apoyo de la automatización y la medición. Capítulo 0
Diagrama de actividades: Un diagrama UML que muestra un flujo de trabajo como acciones, decisiones, bifurcaciones y uniones paralelas, a menudo dividido en calles (swimlanes) según quién hace qué. Capítulo 4
Diagrama de contenedores: Un diagrama C4 que muestra las aplicaciones, los servicios y los almacenes de datos dentro de un sistema, con sus tecnologías y cómo se comunican. Capítulo 4
Diagrama de contexto del sistema: Diagrama C4 que muestra un sistema como una sola caja, las personas que lo usan y los demás sistemas con los que interactúa. Capítulo 4
Diagrama de despliegue: Un diagrama (en C4 o UML) que muestra cómo se asigna el software a la infraestructura en un entorno, incluidos los nodos, las réplicas y las rutas de red. Capítulo 4
Diagrama de flujo de datos (DFD): Un diagrama de entidades externas, procesos, almacenes de datos y los flujos de datos entre ellos, con límites de confianza trazados a través de los flujos; es el modelo habitual para el modelado de amenazas. Capítulo 8
Diagrama de máquina de estados: Diagrama UML que muestra los estados en que puede estar un objeto y las transiciones entre ellos, cada una desencadenada por un evento. Capítulo 4
Diagrama de secuencia: Diagrama UML que muestra los mensajes intercambiados entre participantes a lo largo del tiempo para un escenario, con el tiempo avanzando hacia abajo en la página. Capítulo 4
Diagrama dinámico: Un diagrama C4 complementario que muestra cómo colaboran los elementos en tiempo de ejecución en un escenario, normalmente como interacciones numeradas. Capítulo 4
Diagramas como código: Escribir diagramas como texto en un pequeño lenguaje, como PlantUML, Mermaid, D2 o Structurizr DSL, que una herramienta distribuye y dibuja. Capítulo 4
Diccionario (mapa): Una estructura de datos que almacena valores bajo claves únicas, de modo que un valor puede encontrarse directamente por su clave, normalmente en un tiempo aproximadamente constante. También se llama mapa o tabla hash. Capítulo 0
Dirección IP: La dirección numérica que identifica un dispositivo en una red para que puedan entregársele paquetes, como 192.0.2.10 (IPv4) o 2001:db8::1 (IPv6). Capítulo 0
Disagree and commit (discrepar y comprometerse): Una norma según la cual las personas expresan abiertamente su desacuerdo antes de una decisión y, una vez tomada, se comprometen plenamente a llevarla a cabo. Capítulo 11
Diseño detallado: Decisiones sobre el interior de una parte de un sistema (sus clases, funciones, algoritmos y estructuras de datos locales) que pueden cambiarse sin afectar al resto. Capítulo 1
Diseño emergente: Un enfoque en el que el diseño crece de forma incremental, moldeado por las necesidades de cada nueva funcionalidad y por la refactorización continua. Capítulo 1
Diseño guiado por el dominio (DDD): Un enfoque introducido por Eric Evans en 2003 que construye el software en torno a un modelo del dominio del negocio, desarrollado junto con expertos del dominio, y divide los dominios grandes en modelos delimitados explícitamente. Capítulo 5
Diseño por contrato: El método de Bertrand Meyer para especificar cada operación con precondiciones que debe cumplir quien la llama, postcondiciones que la operación garantiza e invariantes que siempre se mantienen. Capítulo 3
Disponibilidad: La proporción del tiempo, o de las solicitudes, en la que un sistema está listo para prestar su servicio cuando se le pide, normalmente expresada como un porcentaje, por ejemplo 99.9%. Capítulo 2
DNS: Domain Name System (sistema de nombres de dominio): el servicio de directorio de internet, que convierte nombres como www.example.com en direcciones IP. Capítulo 0
Doble de prueba: Sustituto de un colaborador real usado en una prueba, como un stub con respuestas predefinidas, un fake con una implementación sencilla que funciona o un mock que comprueba las llamadas que recibe. Capítulo 2
Docker: Un conjunto de herramientas muy utilizado, publicado en 2013, para construir imágenes de contenedor y ejecutar contenedores. Su formato de imagen se convirtió en un estándar abierto. Capítulo 0
Documentación como código (docs as code): Producir documentación con las mismas herramientas y el mismo flujo de trabajo que el software: archivos de texto plano en control de versiones, revisión de código, comprobaciones automatizadas y publicación. Capítulo 4
Documentación justa y necesaria: Documentación dimensionada según lo que sus lectores realmente necesitan, de modo que escribir y mantener más costaría más de lo que aporta. Capítulo 4
Documentación viva: Documentación que evoluciona con el sistema que describe, a menudo porque se genera a partir del propio sistema o se verifica contra él. Capítulo 4
Documento de diseño (RFC): Una propuesta escrita para un cambio significativo, que abarca el problema, los objetivos, el diseño y las alternativas, y que se distribuye para recibir comentarios antes de construir el cambio. Capítulo 4
Dominio central (core domain): El subdominio que da al negocio su ventaja competitiva y que, por tanto, merece a las mejores personas, el modelado más rico y código propiedad de la empresa. Capítulo 5
Drenaje de conexiones (connection draining): Dejar de enviar nuevas solicitudes a una instancia que se va a retirar mientras se deja terminar las solicitudes ya en curso, para que la reducción de escala y los despliegues no pierdan trabajo. Capítulo 9
DRY: Don't repeat yourself (no te repitas): el principio de The Pragmatic Programmer según el cual cada pieza de conocimiento debe tener una única representación autorizada en un sistema. Se refiere al conocimiento, no a textos que parecen idénticos. Capítulo 3

E

Economía unitaria (unit economics): Expresar el costo (y los ingresos) por unidad de valor de negocio, como el costo por pedido o por cliente activo, para poder juzgar la eficiencia con independencia del crecimiento. Capítulo 10
Ejecución en paralelo: Ejecutar la implementación antigua y la nueva lado a lado con las mismas entradas y comparar sus resultados, mientras la antigua sigue siendo la autoritativa, para demostrar que la nueva es equivalente antes del cambio. Capítulo 11
Elasticidad: La capacidad de añadir y quitar recursos automáticamente a medida que la carga sube y baja, de modo que la capacidad sigue a la demanda y solo pagas por lo que usas. Capítulo 2
Elemento: Una parte de un sistema que un arquitecto analiza como una unidad, como un módulo, un servicio, una base de datos, una cola o un servidor. Capítulo 1
Elicitación: Obtener activamente los requisitos de las partes interesadas, los documentos, la normativa y los sistemas existentes, en lugar de esperar a que alguien los formule. Capítulo 2
Embedding: Un vector de números que representa el significado de un texto, una imagen o un elemento, organizado de modo que los significados similares queden cerca entre sí. Capítulo 12
Encapsulamiento: Mantener privados los datos internos y los detalles de un objeto o un módulo, de modo que otro código solo pueda usarlo mediante las operaciones que decide ofrecer. Capítulo 0
Encargado del tratamiento: Organización que trata datos personales por cuenta de un responsable del tratamiento, siguiendo sus instrucciones y en virtud de un contrato, como un proveedor en la nube de SMS o de correo electrónico. Capítulo 8
Encolamiento (queueing): Esperar a un recurso ocupado. La teoría de colas estudia cómo crece el tiempo de espera con la utilización; explica por qué el tiempo de respuesta se dispara a medida que un recurso se acerca al 100% de ocupación. Capítulo 2
Enfoque arquitectónico: Una decisión de diseño significativa o una combinación de decisiones, como un estilo, un patrón o una táctica, que la arquitectura usa para lograr una cualidad: por ejemplo, un intermediario de eventos con un outbox o una región de reserva en caliente (warm standby). Capítulo 11
Entidad: Un objeto de dominio definido por una identidad que perdura en el tiempo mientras cambian sus atributos, como un pedido o un cliente. Capítulo 5
Entidad de interés: En ISO/IEC/IEEE 42010:2022, aquello cuya arquitectura se describe: un sistema de software, un sistema de sistemas, una línea de productos o una empresa. Capítulo 4
Entorno: Una copia separada y completa del sistema y su configuración que se usa con un fin, como desarrollo, pruebas, staging o producción. Capítulo 0
Entrega al menos una vez (at-least-once): Una garantía de que cada mensaje se procesa, posiblemente más de una vez; el receptor debe gestionar los duplicados. Capítulo 6
Entrega continua: Mantener el software siempre en un estado apto para lanzarse, de modo que cualquier versión que supere el pipeline automatizado pueda ponerse en producción con solo pulsar un botón. Capítulo 0
Entrega progresiva: Lanzar un cambio para audiencias cada vez mayores con comprobaciones automáticas en cada paso, de modo que un cambio defectuoso llegue al menor número posible de usuarios antes de detenerlo. Capítulo 10
EPSS: El Exploit Prediction Scoring System de FIRST, que estima la probabilidad de que una vulnerabilidad se explote en los próximos 30 días. Capítulo 8
Equipo alineado al flujo (stream-aligned): Equipo estable y multifuncional alineado con un flujo de cambio, como un producto, un recorrido de usuario o una capacidad de negocio, que puede construir, operar y cambiar su parte de extremo a extremo. La mayoría de los equipos de una organización deberían ser de este tipo. Capítulo 11
Equipo de plataforma: Equipo que proporciona servicios internos, herramientas e infraestructura como un producto de autoservicio, para que los equipos alineados al flujo puedan entregar sin un conocimiento profundo de la tecnología subyacente. Capítulo 11
Equipo de subsistema complicado: Un equipo responsable de una parte del sistema que requiere conocimientos especializados escasos, como un algoritmo de optimización o un códec de vídeo, para que los equipos alineados con el flujo puedan usarla sin dominarla. Capítulo 11
Equipo facilitador: Un equipo de especialistas que ayuda a otros equipos a adquirir una capacidad que les falta, como la automatización de pruebas o la observabilidad, durante un periodo limitado y luego pasa a otra cosa, en lugar de hacer el trabajo por ellos. Capítulo 11
Erosión de la arquitectura: La degradación gradual de un sistema a medida que los cambios infringen su arquitectura prevista, por ejemplo, saltándose capas o añadiendo dependencias prohibidas. Capítulo 1
Error: Parte del estado interno de un sistema que es incorrecta porque se ha activado un defecto, como un registro corrupto. Un error puede provocar o no un fallo. Capítulo 2
Escalabilidad: La capacidad de un sistema para soportar más carga añadiendo recursos, idealmente con un aumento predecible y aproximadamente proporcional de la capacidad y del costo. Capítulo 2
Escalado horizontal (scaling out): Soportar más carga añadiendo más máquinas y repartiendo el trabajo entre ellas, normalmente detrás de un balanceador de carga. Capítulo 0
Escalado vertical (scaling up): Soportar más carga pasando a una máquina más grande con más procesadores o memoria. Capítulo 0
Escalera de alternativas (fallback ladder): Una lista ordenada de alternativas (otras regiones, proveedores, modelos y, por último, una respuesta sin IA) que se prueban sucesivamente cuando el modelo preferido falla o no está disponible. Capítulo 12
Escenario concreto: Un escenario escrito para un sistema en particular, con actores, eventos, condiciones y cifras específicos, listo para diseñar a partir de él y probarlo. Capítulo 2
Escenario de atributo de calidad: Enunciado breve y comprobable de un requisito de calidad con seis partes: fuente del estímulo, estímulo, artefacto, entorno, respuesta y medida de la respuesta. Capítulo 2
Escenario general: Una plantilla independiente del sistema que enumera las fuentes, los estímulos, los entornos, las respuestas y las medidas típicos de un atributo de calidad. Capítulo 2
Escritura dual: Actualizar dos sistemas, como una base de datos y un intermediario de mensajes, en operaciones separadas; una caída entre ambas deja los dos sistemas incoherentes. Capítulo 6
Espacio de tuplas: Memoria asociativa compartida en la que los procesos escriben tuplas y de la que leen o toman las tuplas que coinciden, sin saber unos de otros. Presentado con el lenguaje Linda de David Gelernter (1985). Capítulo 6
Esqueleto andante (walking skeleton): Implementación diminuta del sistema que realiza una pequeña función de extremo a extremo a través de todos los componentes arquitectónicos principales; normalmente se construye primero. Capítulo 1
Esquema: La estructura declarada de una base de datos: sus tablas, columnas, tipos de datos, claves y reglas. Capítulo 0
Esquema en estrella: Modelo dimensional con una tabla de hechos central de mediciones rodeada de tablas de dimensiones que las describen, como fecha, cliente y producto. Capítulo 7
Estabilidad estática: La propiedad de que un sistema siga funcionando durante un fallo sin tener que hacer cambios, como lanzar servidores nuevos o actualizar la configuración, en el momento del fallo. Capítulo 10
Estado (infraestructura como código): El registro que mantiene una herramienta de infraestructura de qué recursos reales corresponden a qué definiciones del código, y que se usa para calcular qué crear, cambiar o eliminar. Capítulo 10
Estado deseado: Una descripción declarativa de cómo debería ser un sistema (por ejemplo, tres copias de la versión 2.4), que la automatización compara con el estado real y trabaja para alcanzar. Capítulo 10
Estilo arquitectónico: Una familia de arquitecturas con nombre propio, definida por los tipos de elemento y conector que usa y por las restricciones sobre cómo pueden combinarse, como el estilo en capas o el de tuberías y filtros. Capítulo 5
Estímulo: El evento del que trata un escenario de atributo de calidad, como una ráfaga de solicitudes, la caída de un servidor, una solicitud de cambio o un ataque. Capítulo 2
Estrategia de salida: Un plan documentado, e idealmente ensayado, para abandonar un proveedor o un producto, que abarca la exportación de datos, los servicios de sustitución, los contratos, el tiempo y el costo. Capítulo 10
Estructura: Conjunto de elementos y las relaciones entre ellos, visto desde un ángulo: por ejemplo, los módulos de código y sus dependencias, o los servicios en ejecución y cómo se comunican. Capítulo 1
Estructura de datos: Una forma de organizar los datos en memoria, como una lista, un diccionario, un conjunto, una cola, una pila, un árbol o un grafo, elegida para que las operaciones que necesitas sean rápidas. Capítulo 0
ETag: Una cabecera de respuesta HTTP que contiene un identificador de una versión de un recurso, que un cliente puede devolver en If-None-Match para preguntar si ha cambiado. Capítulo 7
ETL: Extract, transform, load (extraer, transformar, cargar): un pipeline que toma datos de los sistemas de origen, los depura y les da nueva forma, y los carga en un almacén de destino como un almacén de datos. Capítulo 5
Eval (evaluación): Un experimento repetible que pasa un conjunto fijo de entradas por un sistema de IA y puntúa los resultados, produciendo cifras que pueden compararse entre versiones. Capítulo 12
Evaluación de impacto relativa a la protección de datos (EIPD): Una evaluación exigida por el artículo 35 del RGPD (GDPR) antes de un tratamiento que probablemente entrañe un alto riesgo para las personas, que describe el tratamiento, su necesidad, los riesgos y las medidas que los abordan. Capítulo 8
Evaluación de la arquitectura: Un examen estructurado de una arquitectura, antes o después de construirla, para averiguar si sus decisiones permitirán que el sistema cumpla sus objetivos de negocio y sus requisitos de calidad, y dónde ponen en riesgo esos objetivos. Capítulo 11
Evaluación de regresión (regression eval): Evaluación automatizada que se ejecuta cada vez que cambian los prompts, los modelos, la recuperación o las herramientas, y que bloquea el lanzamiento si la calidad cae por debajo de un umbral o de una referencia. Capítulo 12
Evaluación offline: Evaluar una versión de un sistema de IA con conjuntos de datos fijos antes de que llegue a los usuarios. Capítulo 12
Evaluación online: Evaluar un sistema de IA con tráfico real, por ejemplo mediante despliegues en sombra, canarios o pruebas A/B. Capítulo 12
Event sourcing: Almacenar cada cambio de una entidad como un evento, de modo que el registro de eventos es la fuente de verdad y el estado actual se obtiene reproduciéndolo. Capítulo 6
Event storming: Un formato de taller creado por Alberto Brandolini en el que expertos del dominio y desarrolladores colocan eventos de dominio en una línea de tiempo para explorar un proceso de negocio y encontrar límites. Capítulo 5
Evento: Un registro inmutable de algo que ha ocurrido, nombrado en tiempo pasado, como OrderPlaced. Cualquier número de receptores puede reaccionar a él. Capítulo 6
Evento de dominio: Un registro de algo significativo que ocurrió en el dominio del negocio, nombrado en tiempo pasado, como OrderPlaced o CourierAssigned. Capítulo 5
Evento en proceso: Un mensaje publicado dentro de una aplicación en ejecución para que otros módulos puedan reaccionar a algo que ha ocurrido, sin que el publicador sepa quién escucha. Capítulo 5
Expandir y contraer (expand and contract): Hacer un cambio incompatible en pasos seguros: añadir la nueva estructura junto a la antigua, migrar los lectores, los escritores y los datos, y luego eliminar la estructura antigua. También se llama cambio paralelo (parallel change). Capítulo 7
Experimento de caos: Una prueba controlada que inyecta un fallo real, como eliminar una instancia o ralentizar una dependencia, para comprobar una hipótesis formulada sobre cómo el sistema mantiene su estado estable. Capítulo 11

F

Factor contribuyente: Una de las varias condiciones que, juntas, hicieron posible o agravaron un incidente; las revisiones buscan muchos factores contribuyentes en lugar de una única causa raíz. Capítulo 9
Failover (conmutación por error): Trasladar el trabajo de un componente que ha fallado a una réplica o un componente de reserva sano, de forma automática o manual. Capítulo 2
Falacias de la computación distribuida: Ocho suposiciones falsas sobre las redes enumeradas en Sun Microsystems por L Peter Deutsch y sus colegas, con James Gosling añadiendo la octava: por ejemplo, que la red es fiable y que la latencia es cero. Capítulo 6
Fallo (failure): Un suceso en el que el servicio que presta un sistema se desvía de lo que debería ser, de un modo que sus usuarios pueden observar. Capítulo 2
Fallo en cascada: Un fallo que se propaga: un componente lento o caído hace que quienes lo llaman esperen y agoten sus propios recursos, de modo que también fallan, y así sucesivamente a lo largo de la cadena. Capítulo 6
Fallo parcial: Situación en la que algunas partes de un sistema distribuido funcionan mientras otras han fallado, son lentas o no son accesibles, a menudo sin que las partes que funcionan puedan saber cuáles. Capítulo 6
Fan-out (abanico): Un patrón en el que una solicitud entrante desencadena varias solicitudes paralelas a otros servicios o servidores, cuyas respuestas luego se combinan. Capítulo 2
Feature flag: Un interruptor de configuración que activa o desactiva un comportamiento en tiempo de ejecución sin desplegar código nuevo. Capítulo 1
Fiabilidad: La probabilidad de que un sistema funcione correctamente, sin fallos, durante un periodo determinado y en unas condiciones determinadas. Un sistema puede tener una disponibilidad alta y aun así ser poco fiable si falla a menudo pero se recupera rápido. Capítulo 2
Fidelidad (faithfulness): En la evaluación de RAG, el grado en que cada afirmación de una respuesta está respaldada por los pasajes recuperados; también se llama fundamentación (groundedness). Capítulo 12
Filtro: Un paso de procesamiento autónomo que lee una entrada y luego la produce, la transforma, la comprueba o la consume, sin saber qué pasos van antes ni después de él. Capítulo 5
Fine-tuning (ajuste fino): Entrenamiento adicional de un modelo existente con un conjunto de datos más pequeño y específico para enseñarle una tarea, un formato, un tono o un vocabulario. Capítulo 12
FinOps: Una práctica en la que los equipos de ingeniería, finanzas y negocio comparten la responsabilidad del gasto en la nube y en tecnología, usando datos de costos oportunos para tomar decisiones que maximicen el valor para el negocio. Capítulo 10
Flapping (oscilación): Un autoescalador que añade y quita capacidad repetidamente porque reacciona a cambios de corta duración o a los efectos de sus propias acciones. Capítulo 9
Flujo de eventos: La secuencia ordenada de eventos de un agregado, numerada por versión, a partir de la cual se reconstruye el estado de ese agregado. Capítulo 7
Formato de tabla abierto: Especificación, como Apache Iceberg, Delta Lake o Apache Hudi, que organiza los archivos de datos y los metadatos para que muchos motores puedan tratarlos como tablas con transacciones y viaje en el tiempo. Capítulo 7
Foro asesor de arquitectura: Una reunión periódica y abierta en la que se debaten las decisiones propuestas, los spikes y los consejos recibidos. Ofrece consejo y visibilidad, pero no decide por sí misma. Capítulo 11
Framework: Código reutilizable que proporciona la estructura general de una aplicación y llama a tu código en los momentos adecuados, como Django o Spring. Capítulo 0
Fuerza (de la connascence): Lo difícil que es descubrir y refactorizar una forma de connascence. La de nombre es la forma más débil; las formas dinámicas, como las de temporización, valor e identidad, están entre las más fuertes. Capítulo 3
Función: Un fragmento de código reutilizable y con nombre que recibe entradas (parámetros), realiza un trabajo y normalmente devuelve una salida. Capítulo 0
Función de aptitud (fitness function): Una comprobación automatizada que te dice si un sistema sigue teniendo una propiedad arquitectónica, como una prueba que falla cuando un módulo depende de otro que no debe usar. Capítulo 1
Función de aptitud atómica: Una función de aptitud que comprueba una característica arquitectónica en un único contexto, como una prueba que prohíbe las importaciones entre dos paquetes. Capítulo 11
Función de aptitud continua: Una función de aptitud que se ejecuta todo el tiempo contra el sistema en funcionamiento, como la supervisión de SLO o las transacciones sintéticas, en lugar de activarse por una compilación o un evento. Capítulo 11
Función de aptitud holística: Una función de aptitud que comprueba varias características juntas en un contexto compartido, como una prueba de carga que mide la latencia con la seguridad y el registro activados. Capítulo 11
Función en el borde (edge function): Un pequeño fragmento de código que una CDN o un proveedor de borde (edge) ejecuta en ubicaciones cercanas a los usuarios, para gestionar o modificar las solicitudes antes de que lleguen al origen (o en lugar de ello). Capítulo 10
FURPS+: Una clasificación de la calidad que surgió en Hewlett-Packard como FURPS (funcionalidad, usabilidad, fiabilidad, rendimiento y soportabilidad), ampliada después con "+" para restricciones como las de diseño, implementación, interfaz y límites físicos. Capítulo 2

G

Game day (día de juego): Un ejercicio planificado en el que un equipo provoca o simula deliberadamente un fallo y practica cómo detectarlo, responder y recuperarse de él. Capítulo 9
Garantías de sesión: Promesas de consistencia por cliente, descritas por Terry y colaboradores en 1994: leer tus propias escrituras, lecturas monótonas, escrituras monótonas y escrituras que siguen a las lecturas. Capítulo 6
Gateway API: La API de Kubernetes para enrutar el tráfico externo e interno hacia los servicios, disponible de forma general desde 2023 y sucesora recomendada de Ingress. Capítulo 10
Gateway de IA (AI gateway): Un componente situado entre las aplicaciones y los proveedores de modelos que centraliza credenciales, enrutamiento, alternativas, cuotas, registro y comprobaciones de políticas para las llamadas a modelos. Capítulo 12
Gauge (indicador): Una métrica que registra un valor actual que puede subir o bajar, como la longitud de una cola, la memoria en uso o la temperatura. Capítulo 9
Generación aumentada por recuperación (RAG): Recuperar pasajes relevantes de tus propias fuentes en el momento de la consulta y proporcionárselos al modelo para que responda a partir de hechos actuales, permitidos y citables. Capítulo 12
Gestión de la configuración: Herramientas como Ansible, Chef y Puppet que llevan servidores existentes y de larga duración a una configuración descrita, instalando paquetes y editando archivos en ellos. Capítulo 10
Gestión de secretos: Almacenar, distribuir, rotar y auditar credenciales como contraseñas, claves de API y claves privadas en una bóveda dedicada en lugar de en el código o en archivos de configuración. Capítulo 8
Gestor de paquetes: Herramienta, como pip (Python) o npm (JavaScript), que descarga bibliotecas y las bibliotecas de las que estas dependen, en las versiones que especifica un proyecto. Capítulo 0
Git: El sistema de control de versiones más utilizado, creado por Linus Torvalds en 2005. Cada desarrollador tiene una copia completa del historial del proyecto. Capítulo 0
GitOps: Operar sistemas guardando su estado deseado declarativo en Git y dejando que unos agentes lo obtengan y reconcilien continuamente el sistema en ejecución para que coincida con él. Capítulo 10
Gobernanza de la arquitectura: Las prácticas mediante las que una organización se asegura de que las decisiones técnicas significativas se toman bien, son coherentes con sus objetivos y se cumplen realmente, incluido quién decide, cómo y con qué controles. Capítulo 11
Grado (de la connascence): Cuántos elementos comparten una connascence concreta. Un valor acordado por dos funciones es mucho más fácil de cambiar que uno acordado por cuarenta servicios. Capítulo 3
Grado de abstracción (A): La métrica de Martin: el número de clases abstractas e interfaces de un componente dividido por su número total de clases, de 0 (totalmente concreto) a 1 (totalmente abstracto). Capítulo 3
Gran bola de barro (big ball of mud): Un sistema sin estructura reconocible, en el que casi todo depende de todo lo demás; el nombre procede de Brian Foote y Joseph Yoder (1997). Capítulo 5
Granularidad: El tamaño de los módulos o servicios en relación con todo el sistema. De grano grueso significa pocas partes grandes; de grano fino, muchas partes pequeñas. Cada opción tiene sus costos. Capítulo 3
GraphQL: Un lenguaje de consulta y un entorno de ejecución para API, publicado por Facebook en 2015, en el que el cliente envía una consulta que nombra exactamente los campos que quiere de un esquema tipado y recibe una respuesta con la misma forma. Capítulo 6
Grid de datos en memoria (in-memory data grid): Software que mantiene datos en la memoria de muchas máquinas como un único almacén lógico, con particionado y replicación, para un acceso muy rápido. Hazelcast, Apache Ignite y Oracle Coherence son ejemplos. Capítulo 6
gRPC: Un framework de llamada a procedimiento remoto, liberado como código abierto por Google en 2015, que envía mensajes de Protocol Buffers sobre HTTP/2 y genera código tipado de cliente y de servidor. Admite streaming en una o en ambas direcciones. Capítulo 6
Grupo de consumidores: Un conjunto de consumidores que se reparten el trabajo de leer un topic: cada partición la lee un miembro, y cada grupo mantiene sus propios desplazamientos (offsets). Capítulo 6
Guarda (guard): Una condición entre corchetes en una transición o un flujo que debe ser verdadera para que se tome, como [code matches]. Capítulo 4
Guardrail (salvaguarda): Un límite o una comprobación automáticos que mantienen seguro el uso en autoservicio (por ejemplo, una política que bloquea los buckets de almacenamiento públicos) sin que una persona tenga que aprobar cada solicitud. Capítulo 10

H

Hardware: Las partes físicas de una computadora que podrías tocar: el procesador, la memoria, el almacenamiento, la tarjeta de red, la pantalla, etc. Capítulo 0
Hash de contraseñas: Guardar una contraseña como el resultado de una función deliberadamente lenta y con sal, como Argon2id, scrypt o bcrypt, para que una base de datos robada no pueda volver a convertirse en contraseñas de forma barata. Capítulo 8
Hashing consistente: Una forma de asignar claves a nodos en un anillo de hash de modo que añadir o quitar un nodo mueva solo alrededor de 1/N de las claves (Karger y colaboradores, 1997). Capítulo 7
Heartbeat (latido): Un mensaje periódico de "sigo vivo" que envía un componente; si los mensajes se detienen, un monitor supone que el componente ha fallado y actúa. Capítulo 2
Herramienta de dibujo: Una herramienta de diagramas que solo conoce formas, líneas y texto, de modo que el mismo elemento dibujado en dos diagramas no tiene ningún vínculo entre ellos. Capítulo 4
Herramienta de modelado: Herramienta que almacena elementos y relaciones en un modelo y genera diagramas como vistas de él, manteniendo la coherencia de todas las vistas. Capítulo 4
Hilo (thread): Una secuencia de instrucciones que se ejecuta dentro de un proceso. Los hilos de un mismo proceso comparten su memoria, de modo que pueden trabajar a la vez pero deben coordinarse. Capítulo 0
Hipervisor: Software que crea y ejecuta máquinas virtuales, repartiendo entre ellas los procesadores, la memoria y los dispositivos de una computadora física y manteniéndolas aisladas. Capítulo 0
Hipótesis de estado estable: En un experimento de caos, la predicción de que una señal medible de comportamiento normal, como los pedidos por minuto, se mantendrá dentro de unos límites mientras se inyecta un fallo. Capítulo 9
Hipótesis del espejo (mirroring hypothesis): La versión académica de la ley de Conway: las dependencias técnicas de un producto tienden a coincidir con los vínculos de comunicación y organizativos entre las personas que lo construyen. Capítulo 3
Histograma: Una métrica que cuenta las observaciones en rangos de valores llamados buckets, como las duraciones de las solicitudes, para poder estimar percentiles y sumar los histogramas de muchos servidores. Capítulo 9
Historia de usuario: Descripción breve de una funcionalidad desde el punto de vista de la persona que la quiere, a menudo escrita así: Como [rol], quiero [capacidad], para [beneficio]. Capítulo 0
HNSW: Grafos jerárquicos navegables de mundo pequeño (hierarchical navigable small world; Malkov y Yashunin, 2016): un índice muy utilizado para la búsqueda aproximada de vecinos más cercanos sobre vectores. Capítulo 12
Horizontal Pod Autoscaler (HPA): Un controlador de Kubernetes que cambia el número de réplicas de pods para mantener una métrica, como el uso medio de CPU en relación con lo solicitado (requests), cerca de un objetivo. Capítulo 10
Hotspot (punto caliente): Una parte del código que es a la vez compleja y modificada con frecuencia, que se encuentra combinando el historial del control de versiones con una medida de complejidad; un lugar probable donde saldar deuda. Capítulo 1
HTTP: Hypertext Transfer Protocol: el lenguaje de solicitud y respuesta de la web, en el que un cliente envía un método como GET a una URL y un servidor responde con un código de estado y un contenido. Capítulo 0
Humano en el bucle (human in the loop): Un diseño en el que una persona revisa, aprueba o corrige la salida de un modelo antes o después de que surta efecto. Capítulo 12

I

IaaS (infraestructura como servicio): Un modelo de nube en el que alquilas máquinas virtuales, almacenamiento y redes, y gestionas tú mismo el sistema operativo y todo lo que está por encima. Capítulo 0
Idempotencia: La propiedad de una operación que tiene el mismo efecto tanto si se realiza una vez como varias, lo que hace que los reintentos sean seguros. Normalmente se consigue con un identificador único de solicitud o de evento que el receptor recuerda. Capítulo 6
Idempotente: Describe una operación que tiene el mismo efecto tanto si se aplica una vez como varias, de modo que puede reintentarse con seguridad. Capítulo 5
Identidad de carga de trabajo: Identidad verificable para un servicio en ejecución en lugar de para una persona, emitida por la plataforma (por ejemplo, un SPIFFE ID en un certificado de corta duración), que se usa en lugar de secretos compartidos. Capítulo 8
Imagen de contenedor: Un paquete de solo lectura y versionado que contiene una aplicación y todo lo que necesita para ejecutarse, a partir del cual pueden iniciarse contenedores idénticos en cualquier lugar. Capítulo 0
Impulsor arquitectónico: Un objetivo, un requisito de atributo de calidad o una restricción que da forma de manera significativa a la arquitectura. Capítulo 2
Impulsor de decisión: Una fuerza o un criterio, como un objetivo de calidad o una restricción, que una decisión arquitectónica debe satisfacer y con respecto al cual se comparan las opciones. Capítulo 4
Impulsores de negocio (business drivers): Los objetivos de negocio, las restricciones y el contexto que explican por qué existe un sistema y qué significa el éxito, como objetivos de crecimiento, normativa o contratos. En el ATAM se presentan primero para que cada hallazgo pueda vincularse con ellos. Capítulo 11
Indicador de nivel de servicio (SLI): Medición cuidadosamente definida del comportamiento de un servicio, como la proporción de solicitudes que tienen éxito en menos de 300 ms. Capítulo 2
Índice: Una estructura de datos adicional, mantenida junto a los datos, que permite a un sistema encontrar elementos por un campo elegido sin recorrerlo todo, como el índice al final de un libro. Capítulo 0
Índice de base de datos: Una estructura de datos adicional, normalmente un árbol B, que permite a la base de datos encontrar filas por el valor de una columna sin leer toda la tabla. Acelera las lecturas, pero ralentiza las escrituras y ocupa espacio. Capítulo 0
Índice secundario: Índice sobre un atributo distinto de la clave primaria o de partición. En un almacén particionado es local a cada partición o global y particionado por el valor indexado. Capítulo 7
Inestabilidad (I): La métrica de Martin I = Ce / (Ca + Ce), de 0 (máximamente estable: solo dependencias entrantes) a 1 (máximamente inestable: solo dependencias salientes). Capítulo 3
Inferencia: Usar un modelo entrenado para producir salidas a partir de nuevas entradas. En producción es un servicio con latencia, rendimiento (throughput) y costo por llamada, a diferencia del entrenamiento, que es un trabajo por lotes pesado. Capítulo 12
Inferencia por lotes: Procesar muchas solicitudes a un modelo juntas, de forma asíncrona, con un costo menor por solicitud pero con una espera más larga para obtener los resultados. Capítulo 12
Infraestructura como código (IaC): Definir servidores, redes, bases de datos y otra infraestructura en archivos bajo control de versiones que las herramientas aplican automáticamente, en lugar de configurarlos a mano. Capítulo 10
Infraestructura de clave pública (PKI): Las autoridades de certificación, los certificados, los almacenes de confianza, las políticas y los mecanismos de revocación que, en conjunto, permiten a las partes verificar las claves públicas de las demás. Capítulo 8
Infraestructura inmutable: La práctica de no modificar nunca en su sitio un servidor o un contenedor en ejecución; cada cambio se hace construyendo una nueva imagen y sustituyendo las instancias antiguas. Capítulo 10
Ingeniería de plataformas: La disciplina de construir y operar plataformas internas que permiten a los equipos de producto aprovisionar, desplegar y operar software mediante autoservicio. Capítulo 10
Ingeniería del caos: Experimentar con un sistema, idealmente en producción y de forma controlada, inyectando fallos realistas para ganar confianza en que resiste condiciones turbulentas. Capítulo 9
Inquietud: Un interés que una parte interesada tiene en un sistema, como su costo, su rendimiento, su seguridad, su facilidad de cambio o su cumplimiento legal. Capítulo 1
Inquietud transversal (cross-cutting concern): Una inquietud que afecta a muchas partes de un sistema a la vez, como el registro, la seguridad, el manejo de errores o la persistencia, y que por eso suele decidirse una sola vez para todo el sistema. Capítulo 1
Integración continua (CI): La práctica de fusionar con frecuencia, al menos a diario, los cambios de cada desarrollador en la línea principal compartida, con una compilación y unas pruebas automatizadas que verifican cada cambio. Capítulo 0
Intercepción de eventos: Un patrón de desplazamiento de sistemas heredados que captura las solicitudes o los eventos que cambian el estado en su camino hacia un sistema heredado y reenvía algunos de ellos también a un nuevo componente, o en su lugar. Capítulo 11
Interés (de la deuda técnica): El esfuerzo, el retraso o el riesgo adicionales que se pagan en cada cambio porque la deuda no se ha saldado. Capítulo 1
Interfaz: El conjunto acordado de operaciones que un software ofrece a otros, con sus entradas y salidas: un contrato que oculta cómo se hace el trabajo. Capítulo 0
Interfaz proporcionada: En un diagrama de componentes UML, una interfaz que un componente ofrece a otros, representada como un pequeño círculo (una bola) sobre un palo. Capítulo 4
Interfaz requerida: En un diagrama de componentes UML, una interfaz que un componente necesita que otro componente proporcione, representada como un semicírculo (un enchufe). Capítulo 4
Interoperabilidad: El grado en que los sistemas pueden intercambiar información y usar correctamente lo que intercambian, lo que requiere acuerdo tanto sobre el significado como sobre el formato. Capítulo 2
Intérprete: Un programa que lee código y ejecuta sus instrucciones sobre la marcha, en lugar de traducir todo el programa por adelantado. Capítulo 0
Invalidación de caché: Eliminar o marcar como obsoleta una copia almacenada en caché cuando cambian los datos originales, para que las lecturas posteriores obtengan el nuevo valor. Capítulo 7
Invariante: Una condición que siempre es verdadera para un módulo u objeto entre operaciones, como "el saldo de una cuenta nunca baja de su límite de descubierto". Capítulo 3
Inversión de control: La organización en la que un framework, y no tu propio código, controla el flujo del programa y llama a tu código cuando hace falta. Capítulo 0
Inversión de dependencias: Hacer que un módulo de alto nivel y uno de bajo nivel dependan ambos de una abstracción, normalmente propiedad del lado de alto nivel, de modo que la dependencia del código fuente apunte en sentido contrario al flujo de control. Capítulo 3
Inyección de dependencias: Proporcionar a un componente desde fuera los colaboradores que necesita (una base de datos, un reloj, una pasarela de pagos) en lugar de dejar que los cree, para que puedan intercambiarse, por ejemplo, por imitaciones en las pruebas. Capítulo 2
Inyección de prompts (prompt injection): Ataque en el que un texto aportado por un usuario u oculto en contenido que lee el modelo contiene instrucciones que anulan o subvierten el comportamiento previsto de la aplicación. Capítulo 12
Inyección indirecta de prompts: Inyección de prompts que llega a través de contenido que lee el sistema, como una página web, un correo electrónico, un documento o el resultado de una herramienta, en lugar de que la escriba el usuario. Capítulo 12
ISO/IEC 25010: La norma internacional que define el modelo de calidad del producto. La edición de 2023 define nueve características, desde la adecuación funcional hasta la seguridad física (safety), cada una dividida en subcaracterísticas. Capítulo 2
ISO/IEC 42001: La norma internacional (2023) que especifica los requisitos de un sistema de gestión de IA certificable dentro de una organización. Capítulo 12

J

Jailbreak: Una entrada diseñada para hacer que un modelo incumpla las políticas de seguridad con las que lo entrenó su proveedor. Capítulo 12
Jitter (fluctuación aleatoria): Aleatoriedad que se añade a los retrasos de los reintentos o a las programaciones para que muchos clientes no actúen en el mismo momento y generen picos sincronizados. Capítulo 9
Join: Operación SQL que combina filas de dos o más tablas haciendo coincidir columnas relacionadas, como los pedidos con los clientes que los hicieron. Capítulo 0
JSON (JavaScript Object Notation): Formato de texto para datos estructurados compuesto por objetos (pares nombre-valor entre llaves), arrays (listas entre corchetes), cadenas, números, true, false y null. Estandarizado en el RFC 8259. Capítulo 0
JSON Web Token (JWT): Token compacto, firmado (y opcionalmente cifrado) que transporta afirmaciones (claims) como emisor, sujeto, audiencia y caducidad, definido en el RFC 7519; muy usado para tokens de acceso y tokens de ID. Capítulo 8
Junta de revisión de arquitectura: Un grupo permanente de arquitectos sénior que revisa y aprueba los diseños significativos, normalmente en momentos fijos de un proyecto. Puede aportar un juicio independiente, pero a menudo se convierte en un punto de control lento. Capítulo 11

K

Kanban: Forma de gestionar el trabajo como un flujo continuo en un tablero visual, limitando cuántos elementos pueden estar en curso a la vez. Capítulo 0
Kata de arquitectura: Un ejercicio práctico creado por Ted Neward en el que pequeños equipos diseñan una arquitectura para un enunciado breve y deliberadamente incompleto, y luego la presentan y defienden ante sus compañeros. Capítulo 11
KISS: Keep it simple (mantenlo simple): una regla práctica de diseño, procedente de la ingeniería de los años sesenta, según la cual debe evitarse la complejidad innecesaria porque hace que un sistema sea más difícil de entender, operar y reparar. Capítulo 3
Kubernetes: El orquestador de contenedores de código abierto más usado, creado en Google, anunciado en 2014 y publicado como versión 1.0 en 2015; mantiene el estado real de un clúster en coincidencia con un estado deseado declarado. Capítulo 10

L

Lakehouse: Arquitectura que añade funciones de almacén de datos, como transacciones, esquemas y consultas rápidas, a datos guardados en formatos de archivo abiertos sobre almacenamiento de objetos. Capítulo 7
Las siete R (Seven Rs): Las estrategias de migración que AWS enumera para trasladar aplicaciones a la nube: retire (retirar), retain (conservar), rehost (realojar), relocate (reubicar), repurchase (recomprar), replatform (cambiar de plataforma) y refactor o re-architect (refactorizar o rediseñar la arquitectura). Surgieron de las cinco R anteriores de Gartner. Capítulo 11
Last write wins (gana la última escritura): Regla de resolución de conflictos que conserva la escritura con la marca de tiempo más reciente y descarta las demás. Es simple, pero las actualizaciones concurrentes se pierden sin aviso y las diferencias entre relojes pueden elegir al ganador equivocado. Capítulo 6
Latencia: El retardo antes de que lleguen los datos o vuelva una respuesta, medido normalmente en milisegundos. La distancia, los saltos de red y el procesamiento lento se suman a ella. Capítulo 0
Latencia de cola (tail latency): Los tiempos de respuesta de las solicitudes más lentas, descritos normalmente con percentiles altos como p99 o p99.9. A gran escala, la cola suele decidir la experiencia de los usuarios. Capítulo 2
LCOM (falta de cohesión de los métodos): Familia de métricas a nivel de clase que estiman la cohesión a partir de cómo comparten los métodos de una clase sus campos; un valor alto sugiere que la clase reúne varias responsabilidades sin relación entre sí. Capítulo 3
Leaky bucket (cubeta con fugas): Algoritmo de limitación de tasa o de conformación del tráfico en el que las solicitudes entran en una cubeta y salen a un ritmo constante; cuando la cubeta está llena, las solicitudes nuevas se rechazan. Capítulo 9
Lector tolerante (tolerant reader): Consumidor que lee solo los campos que necesita e ignora todo lo que no reconoce, de modo que los proveedores pueden añadir campos sin romperlo. Capítulo 7
Lecturas monótonas: Garantía de que, una vez que un cliente ha visto un valor, sus lecturas posteriores nunca devuelven uno más antiguo, de modo que los datos nunca parecen retroceder en el tiempo. Capítulo 6
Leer tus propias escrituras (read-your-writes): Garantía de que, después de que un cliente escribe un valor, las lecturas posteriores de ese mismo cliente ven la escritura o algo más reciente, aunque otros clientes todavía no la vean. Capítulo 6
Lenguaje publicado: Formato documentado y compartido para intercambiar información entre contextos, como un esquema de eventos versionado, que a menudo se ofrece mediante un servicio de host abierto. Capítulo 5
Lenguaje ubicuo: Vocabulario compartido por los desarrolladores y los expertos del dominio y usado de forma coherente en las conversaciones, los documentos, las pruebas y el código dentro de un contexto delimitado. Capítulo 5
Lenguaje Unificado de Modelado (UML): Lenguaje gráfico de modelado de propósito general estandarizado por el Object Management Group. La versión actual es la 2.5.1 (2017). Capítulo 4
Ley de Amdahl: Una fórmula (Gene Amdahl, 1967) que muestra que la aceleración obtenida al añadir procesadores está limitada por la parte del trabajo que debe ejecutarse en serie. Capítulo 2
Ley de Conway: La observación de Melvin Conway de 1968 de que las organizaciones diseñan sistemas cuya estructura refleja la propia estructura de comunicación de la organización. Capítulo 1
Ley de escalabilidad universal (USL): Modelo de Neil Gunther sobre cómo crece la capacidad al añadir nodos, teniendo en cuenta la contención por los recursos compartidos y el costo de mantener la coherencia de los datos. Predice un máximo a partir del cual añadir nodos reduce la capacidad. Capítulo 2
Ley de Goodhart: La observación, formulada a menudo como "cuando una medida se convierte en objetivo, deja de ser una buena medida", de que las personas optimizan la cifra en lugar de aquello que debía indicar. Capítulo 3
Ley de Hyrum: La observación, que lleva el nombre de Hyrum Wright, de que con suficientes usuarios de una API, alguien dependerá de cada comportamiento observable, prometa lo que prometa el contrato. Capítulo 3
Ley de Little: La regla L = λ × W: el número medio de elementos en un sistema estable es igual a la tasa media de llegada multiplicada por el tiempo medio que cada elemento pasa en él. Capítulo 2
Limitación de tasa (rate limiting): Restringir cuántas solicitudes puede hacer un cliente, una clave o un inquilino (tenant) en un periodo, para proteger la capacidad y repartirla de forma justa; las solicitudes que exceden el límite suelen responderse con HTTP 429. Capítulo 9
Límite de confianza: Línea de un sistema en la que los datos o el control pasan entre partes con distintos niveles de confianza o privilegio, como de internet a una API, por lo que la entrada debe comprobarse allí. Capítulo 8
Límite de tasa: Tope de cuántas solicitudes puede hacer un cliente en un periodo, como 100 por minuto. Las solicitudes que lo superan se rechazan, normalmente con el código de estado HTTP 429. Capítulo 0
Linaje de datos: Un registro de dónde procede un dato y de cada transformación por la que ha pasado en el camino. Capítulo 7
Línea de vida: En un diagrama de secuencia, la línea vertical discontinua bajo un participante, a lo largo de la cual se muestran sus mensajes y activaciones en orden temporal. Capítulo 4
Linealizabilidad: El modelo de consistencia de objeto único más fuerte: cada operación parece ocurrir en un instante entre su inicio y su fin, en un orden que comparten todos los clientes y que respeta el tiempo real, como si hubiera una sola copia. Capítulo 6
Linux: Núcleo de sistema operativo libre y de código abierto que, junto con otro software, se usa como sistema operativo en la mayoría de los servidores, máquinas en la nube y contenedores, así como en los teléfonos Android. Capítulo 0
Lista de materiales de software (SBOM): Inventario legible por máquina de los componentes y dependencias de una pieza de software, en un formato estándar como SPDX o CycloneDX. Capítulo 8
Llamada a herramientas (tool calling): Capacidad de un modelo por la que este devuelve una solicitud estructurada para llamar a una función que la aplicación ha descrito; quien la ejecuta es la aplicación, no el modelo. Capítulo 12
Llamada síncrona: Solicitud en la que quien llama espera la respuesta antes de continuar, como en una llamada normal a una API HTTP. Capítulo 0
LLM como juez (LLM-as-judge): Usar un modelo de lenguaje para puntuar o comparar resultados según una rúbrica; es escalable, pero está sujeto a sesgos que deben medirse frente al juicio humano. Capítulo 12
LLMOps: Prácticas para construir, lanzar, monitorizar y mejorar aplicaciones basadas en modelos de lenguaje grandes, incluido el versionado de prompts y modelos, el trazado de llamadas y la evaluación en el pipeline. Capítulo 12
Localidad (de la connascence): Lo cerca que están entre sí los elementos con connascence: dentro de una función, un módulo, un componente o a través de una red. Una connascence fuerte solo es tolerable cuando es local. Capítulo 3
Lockfile (archivo de bloqueo): Archivo generado por un gestor de paquetes que registra las versiones exactas, y normalmente los hashes, de cada dependencia resuelta, de modo que cada instalación use los mismos paquetes. Capítulo 8
Logging estructurado (structured logging): Escribir las entradas de log como registros clave-valor legibles por máquina (a menudo JSON) con nombres de campo coherentes, en lugar de frases de texto libre. Capítulo 9

M

MADR: Markdown Architectural Decision Records: una plantilla de ADR muy utilizada con impulsores de la decisión, opciones consideradas, el resultado, las consecuencias y la confirmación. Capítulo 4
Maniobra inversa de Conway: Dar forma deliberadamente a los equipos y a sus vías de comunicación para que coincidan con la arquitectura que quieres, de modo que la ley de Conway juegue a tu favor y no en tu contra. Capítulo 3
Mantenibilidad: En ISO/IEC 25010, la eficacia y eficiencia con que puede modificarse un producto; abarca la modularidad, la reusabilidad, la analizabilidad, la modificabilidad y la capacidad de prueba. Capítulo 2
Mapa de contextos: Una representación de los contextos delimitados de un sistema y de las relaciones entre ellos, como cliente-proveedor o capa anticorrupción, que abarca tanto la integración como las relaciones entre equipos. Capítulo 5
Máquina virtual (VM): Imitación por software de una computadora completa, con su propio sistema operativo, que se ejecuta junto a otras VM en una máquina física bajo un hipervisor. Capítulo 0
Marca de agua (watermark): La estimación móvil de un procesador de flujos de que probablemente han llegado todos los eventos hasta un determinado tiempo de evento, que se usa para decidir cuándo puede emitirse el resultado de una ventana. Capítulo 7
Marco de descripción de arquitectura: En ISO/IEC/IEEE 42010:2022, un conjunto establecido de convenciones para elaborar descripciones de arquitectura, como puntos de vista, plantillas y reglas. Capítulo 4
Marco SPACE: Marco de 2021 para la productividad de los desarrolladores que abarca la satisfacción y el bienestar, el desempeño, la actividad, la comunicación y la colaboración, y la eficiencia y el flujo. Capítulo 10
Margen de capacidad (headroom): Capacidad sobrante que se mantiene deliberadamente por encima de la carga máxima prevista, para absorber picos, fallos y el tiempo que se tarda en añadir más capacidad. Capítulo 9
Matriz de decisión ponderada: Tabla que puntúa cada opción según criterios ponderados para que el razonamiento detrás de una elección sea explícito y pueda cuestionarse. Capítulo 1
Matriz poder/interés: Mapa de dos por dos que sitúa a las partes interesadas según su poder sobre un proyecto y su interés en él, y que se usa para planificar con qué intensidad implicar a cada grupo. Capítulo 1
Medida de la respuesta: El número que hace comprobable un escenario, como '99% en menos de 800 ms', 'servicio restablecido en 2 minutos' o 'cambio completado en 3 días-persona'. Capítulo 2
Menos conexiones (least connections): Algoritmo de balanceo de carga que envía cada solicitud nueva a la instancia con menos solicitudes o conexiones en curso en ese momento. Capítulo 9
Menos frecuentemente usado (LFU): Política de desalojo que elimina el elemento que se ha leído menos veces cuando la caché está llena. Capítulo 7
Menos recientemente usado (LRU): Política de desalojo que elimina el elemento que lleva más tiempo sin leerse cuando la caché está llena. Capítulo 7
Mensaje: Cualquier dato enviado de un programa a otro a través de un canal; puede contener un evento, un comando, una consulta o una respuesta. Capítulo 6
Mensajería asíncrona: Comunicación en la que el emisor deja un mensaje en algún lugar para que el receptor lo procese más tarde, y continúa sin esperar respuesta. Capítulo 0
Método RED: Lista de comprobación de Tom Wilkie para monitorizar servicios basados en solicitudes: Rate (tasa), Errors (errores) y Duration (duración) de las solicitudes. Capítulo 9
Método USE: Lista de comprobación de Brendan Gregg para analizar recursos: para cada recurso, comprueba la utilización (Utilisation), la saturación (Saturation) y los errores (Errors). Capítulo 9
Métricas DORA: Las medidas de rendimiento de la entrega de software del programa de investigación DORA: tiempo de entrega de cambios, frecuencia de despliegue, tiempo de recuperación de despliegues fallidos, tasa de fallos de cambios y tasa de retrabajo de despliegues. Capítulo 2
Microsegmentación: Dividir una red en zonas muy pequeñas, hasta cargas de trabajo individuales, de modo que cada una acepte tráfico solo de los llamantes que necesita. Capítulo 8
Microservicios: Estilo en el que una aplicación se construye como pequeños servicios, cada uno en su propio proceso, organizados en torno a una capacidad de negocio, desplegables de forma independiente y comunicados mediante mecanismos ligeros. Capítulo 6
Migración: Script versionado que cambia el esquema de una base de datos o sus datos de una versión a la siguiente, guardado en el control de versiones y aplicado automáticamente. Capítulo 7
Mínimo privilegio: El principio de que cada usuario, programa y servicio recibe solo los permisos que necesita para su tarea y solo durante el tiempo que los necesita, de modo que un error o un compromiso cause daños limitados. Capítulo 8
Model card (ficha del modelo): Documento breve publicado junto con un modelo que describe su uso previsto, los resultados de evaluación en distintos grupos, los datos de entrenamiento, las limitaciones y las consideraciones éticas (Mitchell et al., 2019). Capítulo 12
Model Context Protocol (MCP): Protocolo abierto, presentado por Anthropic en noviembre de 2024 y hoy gobernado bajo la Linux Foundation, para conectar aplicaciones de IA con servidores que exponen herramientas, datos y prompts. Capítulo 12
Modelado de amenazas: Forma estructurada de preguntarse, sobre un diseño, qué estamos construyendo, qué puede salir mal, qué vamos a hacer al respecto y si lo hemos hecho lo bastante bien. Capítulo 8
Modelo C4: El enfoque de Simon Brown para los diagramas de arquitectura: una jerarquía de diagramas de contexto del sistema, de contenedores, de componentes y de código, más algunos diagramas complementarios. Capítulo 4
Modelo cliente-servidor: Una organización en la que los clientes (como los navegadores o las apps móviles) envían solicitudes y los servidores, que contienen los datos y la lógica compartidos, responden. Capítulo 0
Modelo de calidad: Lista estructurada de características de calidad y sus subcaracterísticas, que se usa como vocabulario compartido y como lista de comprobación al especificar o evaluar la calidad. Capítulo 2
Modelo de carga abierto: Modelo de carga en el que las solicitudes nuevas llegan a un ritmo fijo con independencia de lo rápido que se respondan las anteriores, como los clientes que llegan a un sitio web. Capítulo 9
Modelo de carga cerrado: Un modelo de carga con un número fijo de usuarios, cada uno de los cuales envía una nueva solicitud solo después de recibir respuesta a la anterior (más un tiempo de reflexión), de modo que la carga disminuye cuando el sistema se ralentiza. Capítulo 9
Modelo de consistencia: El contrato que ofrece un almacén de datos sobre qué valores pueden devolver las lecturas en función de las escrituras que se han producido y, por tanto, para qué resultados obsoletos o reordenados deben estar preparados los clientes. Capítulo 6
Modelo de datos canónico: Una única representación de cada entidad de negocio para toda la empresa, a la que se traducen todos los mensajes y desde la que se traducen. Rara vez encaja bien en todas las partes de un negocio. Capítulo 6
Modelo de dominio: Un pequeño diagrama o descripción de los conceptos de negocio clave de un sistema, sus atributos y cómo se relacionan, compartido por los desarrolladores y los expertos del dominio. Capítulo 4
Modelo de IA de uso general: Según el Reglamento de IA de la UE, un modelo de IA, como un modelo de lenguaje de gran tamaño, que puede realizar una amplia gama de tareas e integrarse en muchos sistemas posteriores. Capítulo 12
Modelo de lenguaje grande (LLM): Transformer de gran tamaño entrenado con enormes cantidades de texto para predecir el siguiente token y luego ajustado para seguir instrucciones; genera texto, código y datos estructurados. Capítulo 12
Modelo de pesos abiertos (open-weight): Modelo cuyos pesos entrenados se publican para que otros los ejecuten, con una licencia que puede ser permisiva o restrictiva. Los pesos abiertos no convierten por sí solos un modelo en código abierto. Capítulo 12
Modelo de razonamiento: Modelo de lenguaje entrenado para generar tokens de razonamiento intermedios antes de responder, a cambio de un costo y una latencia adicionales, para obtener mejores resultados en tareas difíciles de varios pasos. Capítulo 12
Modelo de responsabilidad compartida: El reparto de las obligaciones de seguridad y operación entre un proveedor de nube, que protege la propia nube, y el cliente, que protege sus datos, identidades y configuración en la nube. Capítulo 10
Modelo de vistas 4+1: Enfoque de Philippe Kruchten de 1995 que describe un sistema mediante las vistas lógica, de procesos, de desarrollo y física, unidas por un pequeño conjunto de escenarios. Capítulo 4
Modelo dirigido por riesgos: Enfoque de George Fairbanks en el que la cantidad de trabajo de arquitectura la fijan los riesgos a los que se enfrenta un proyecto: identificar los riesgos, aplicar técnicas y evaluar la reducción. Capítulo 1
Modificabilidad: Lo barato y seguro que resulta cambiar un sistema: el costo, el esfuerzo y el riesgo de un cambio, y hasta dónde se propaga más allá del lugar donde se hace. Capítulo 2
Modo de interacción: En Team Topologies, una de las tres formas deliberadas en que dos equipos trabajan juntos: colaboración, X como servicio (X-as-a-Service) o facilitación. Se espera que los modos cambien a medida que los límites se descubren y se asientan. Capítulo 11
Modularidad: El grado en que un sistema está dividido en partes que pueden entenderse, cambiarse y probarse en gran medida por separado. Es una subcaracterística de la mantenibilidad en ISO/IEC 25010. Capítulo 3
Módulo: Unidad de código, a menudo un solo archivo, que agrupa funciones y datos relacionados bajo un nombre y decide qué pone a disposición de otro código. Un paquete es un grupo de módulos. Capítulo 0
Módulo de seguridad de hardware (HSM): Hardware resistente a manipulaciones que genera y usa claves en su interior y nunca las libera en texto plano; los servicios KMS suelen construirse sobre HSM. Capítulo 8
Módulo físico: Unidad que se compila, se versiona o se despliega, como un archivo JAR, un paquete de Python, una imagen de contenedor o un servicio. Un mismo diseño lógico puede empaquetarse en módulos físicos de muchas formas. Capítulo 3
Módulo lógico: Unidad de responsabilidad en el diseño, como Pedidos o Pagos, con independencia de cómo se empaquete o despliegue su código. Capítulo 3
Módulo profundo: Término de John Ousterhout para un módulo cuya interfaz sencilla oculta una gran cantidad de funcionalidad. Un módulo superficial ofrece poco comportamiento para la complejidad de su interfaz. Capítulo 3
Momento de vinculación (binding time): El momento en que se fija una decisión: al escribir el código, en la compilación, en el despliegue, en el arranque o mientras el sistema se ejecuta. Capítulo 2
Monitorización: Recopilar y vigilar mediciones y comprobaciones predefinidas para que los tipos de fallo conocidos se detecten y se notifiquen. Capítulo 9
MonolithFirst (primero el monolito): Consejo de Martin Fowler de 2015 de empezar un sistema nuevo como un monolito bien modularizado y extraer servicios más adelante, cuando los límites se entiendan y hagan falta. Capítulo 5
Monolito: Sistema construido y desplegado como una sola unidad, aunque su código esté dividido internamente en módulos bien separados. Capítulo 1
Monolito distribuido: Un sistema desplegado como servicios separados que están tan fuertemente acoplados que deben modificarse y lanzarse juntos, con lo que tiene los costos de la distribución sin sus beneficios. Capítulo 5
Monolito modular: Aplicación desplegable única cuyo código está dividido en módulos según límites de negocio, cada uno con una interfaz pública explícita y sus propios datos. Capítulo 5
Motor de búsqueda: Almacén construido en torno a un índice invertido de palabras a documentos, que ofrece búsqueda de texto completo ordenada por relevancia y tolerante a erratas; normalmente se alimenta desde un sistema de registro. Capítulo 7
Movimiento lateral: El avance de un atacante desde la primera máquina o cuenta que compromete hacia otros sistemas dentro de la misma red u organización. Capítulo 8
Muestreo de trazas: Conservar solo algunas trazas para controlar el costo: el muestreo en cabeza (head-based) decide cuando empieza una solicitud y el muestreo en cola (tail-based) decide cuando termina, por lo que puede conservar las solicitudes lentas y las fallidas. Capítulo 9
Multinube (multi-cloud): Usar servicios de dos o más proveedores de nube pública, por servicios diferenciales, adquisiciones, poder de negociación o planes de salida exigidos por la regulación. Capítulo 10
Multiplicidad: En un diagrama de clases UML, cuántos objetos pueden participar en cada extremo de una asociación, como 1, 0..1, 0..* o 1..*. Capítulo 4

N

Nativo de la nube (cloud native): Un enfoque para construir y operar software como sistemas débilmente acoplados, automatizados, observables y resilientes, que se despliegan de forma programática y repetible en nubes públicas, privadas o híbridas. Describe cómo se construye un sistema, no dónde se ejecuta. Capítulo 10
NIST AI RMF: El marco voluntario de gestión de riesgos de IA (AI Risk Management Framework) publicado por el Instituto Nacional de Estándares y Tecnología de EE. UU. (versión 1.0, 2023), basado en las funciones Govern, Map, Measure y Manage (gobernar, mapear, medir y gestionar). Capítulo 12
Nivel (tier): Límite físico en tiempo de ejecución, como un proceso o servidor separado. Una capa es un límite lógico en el código; varias capas pueden ejecutarse en un mismo nivel. Capítulo 5
Nivel de aislamiento: Un ajuste que indica cuánto pueden afectarse entre sí las transacciones concurrentes: read uncommitted, read committed, repeatable read, snapshot o serializable. Los nombres significan cosas distintas en bases de datos distintas. Capítulo 7
Nivel de gravedad: Clasificación predefinida de lo grave que es un incidente, como de SEV1 a SEV4, que decide a quién se llama, con qué rapidez y con qué amplitud se comunica. Capítulo 9
No riesgo: Decisión considerada sólida para un escenario dado, registrada junto con los supuestos de los que depende, para poder reexaminarla si esos supuestos cambian. Capítulo 11
NoSQL: Término general para las bases de datos que no usan el modelo relacional de tablas, como las bases de datos documentales, clave-valor, de columnas anchas y de grafos. Capítulo 0
Notación O grande (Big-O): Una forma de describir cómo crece el trabajo que hace un algoritmo a medida que crece la cantidad de datos, por ejemplo O(n) para un crecimiento lineal u O(1) para un tiempo constante. Capítulo 0
Notificación de eventos: Un evento que solo señala un cambio, a menudo con apenas un identificador, de modo que los receptores que necesiten detalles deben preguntar al publicador. Capítulo 6
Nube híbrida: Una combinación de nube privada y pública (o de sistemas locales) conectadas de modo que los datos y las aplicaciones puedan funcionar entre ellas. Capítulo 10
Nube privada: Infraestructura de nube dedicada a una sola organización, que ofrece aprovisionamiento de autoservicio basado en API; puede estar en las propias instalaciones o alojada por un tercero. Capítulo 10
Núcleo compartido (shared kernel): Pequeña parte de un modelo, y su código, que dos contextos acuerdan explícitamente compartir y que solo puede cambiarse con el consentimiento de ambos equipos. Capítulo 5

O

OAuth 2.0: El marco de autorización delegada del RFC 6749, en el que un servidor de autorización emite tokens de acceso que permiten a un cliente llamar a un servidor de recursos en nombre del propietario del recurso, sin ver su contraseña. Capítulo 8
Objetivo de nivel de servicio (SLO): Objetivo interno para un SLI en una ventana de tiempo, como que el 99.9% de las solicitudes tengan éxito en 30 días. Capítulo 2
Objetivo de punto de recuperación (RPO): La mayor cantidad de datos, medida como un periodo de tiempo, que el negocio puede aceptar perder en un desastre; por ejemplo, los cambios de los últimos 15 minutos. Capítulo 2
Objetivo de tiempo de recuperación (RTO): El tiempo máximo que el negocio puede aceptar entre un desastre y el restablecimiento del servicio. Capítulo 2
Objeto de valor: Objeto de dominio definido solo por sus valores, sin identidad propia y normalmente inmutable, como una cantidad de dinero o una dirección. Capítulo 5
Observabilidad: Lo bien que las personas pueden entender lo que ocurre dentro de un sistema en ejecución a partir de los datos que emite (logs, métricas, trazas), incluso ante problemas que nadie había previsto. Capítulo 2
Ocultación de información: El principio de David Parnas (1972) según el cual cada módulo debe ocultar una decisión de diseño difícil o con probabilidad de cambiar, para que esa decisión pueda cambiar sin afectar a otros módulos. Capítulo 3
Offset (desplazamiento): La posición secuencial de un evento dentro de una partición; los consumidores registran el offset al que han llegado para poder reanudar después de un reinicio. Capítulo 6
OLAP: Online analytical processing (procesamiento analítico en línea): cargas de trabajo de consultas grandes que recorren y agregan muchos registros, como los ingresos por región y por mes. Capítulo 7
OLTP: Online transaction processing (procesamiento de transacciones en línea): cargas de trabajo de muchas lecturas y escrituras pequeñas de registros individuales, como hacer pedidos o registrar pagos. Capítulo 7
Omisión coordinada (coordinated omission): Un error de medición, bautizado por Gil Tene, en el que un generador de carga espera las respuestas lentas antes de enviar más solicitudes y, por tanto, nunca registra los retrasos que habrían sufrido los usuarios reales. Capítulo 9
Open Container Initiative (OCI): Proyecto de la Linux Foundation, fundado en 2015, que mantiene estándares abiertos para formatos de imagen de contenedor, entornos de ejecución y registros, de modo que las herramientas de distintos proveedores interoperen. Capítulo 10
OpenAPI: Formato estándar y legible por máquina para describir API HTTP (rutas, operaciones, parámetros, esquemas), antes llamado especificación Swagger. Sirve de base para la documentación, la generación de código y las pruebas. Capítulo 6
OpenID Connect (OIDC): Capa de identidad sobre OAuth 2.0 que añade un token de ID, un JWT firmado que indica al cliente quién es el usuario y cómo y cuándo se autenticó. Capítulo 8
OpenTelemetry: Proyecto de la CNCF, de código abierto e independiente de proveedores, que proporciona API, SDK, un protocolo (OTLP) y un recolector para producir y exportar trazas, métricas y logs. Capítulo 9
OpenTofu: Bifurcación (fork) de código abierto de Terraform creada en 2023 después de que HashiCorp pasara Terraform a la Business Source Licence; alojada por la Linux Foundation y proyecto de la CNCF. Capítulo 10
Organización en capas (layering): Organizar los módulos en capas donde cada capa solo puede usar las capas inferiores. La organización estricta permite usar solo la capa inmediatamente inferior; la relajada permite cualquier capa inferior. Capítulo 3
Orquestación: Coordinación de un proceso de varios pasos por parte de un componente que indica a cada participante qué hacer y decide qué ocurre a continuación. Capítulo 6
Orquestación de contenedores: Programar automáticamente los contenedores en las máquinas y mantenerlos en ejecución: reiniciar los que fallan, escalar, desplegar nuevas versiones y conectarlos a redes y almacenamiento. Capítulo 10
Orquestador de sagas: Componente que coordina una saga enviando comandos a los participantes, siguiendo el progreso en una máquina de estados persistente y desencadenando compensaciones en caso de fallo. Capítulo 6

P

PaaS (plataforma como servicio): Modelo de nube en el que tú aportas el código o el contenedor de tu aplicación y el proveedor ejecuta, parchea y escala la plataforma que hay debajo. Capítulo 0
PACELC: La extensión de CAP de Daniel Abadi: si hay una Partición (Partition), elige entre Disponibilidad (Availability) y Consistencia (Consistency); si no (Else), en funcionamiento normal, elige entre Latencia (Latency) y Consistencia (Consistency). Capítulo 6
Página de estado: Página pública u orientada a los clientes que informa de los incidentes en curso y del estado del servicio, actualizada por el responsable de comunicaciones del incidente. Capítulo 9
Paginación por cursor: Recorrer una colección por páginas pasando un token opaco que marca el último elemento visto, en lugar de un desplazamiento numérico. Sigue siendo rápida y estable cuando se añaden elementos durante la paginación. Capítulo 6
Pago por uso (pay-as-you-go): Modelo de precios en el que se te cobra por los recursos solo mientras los usas, por ejemplo por segundo de tiempo de servidor o por gigabyte almacenado. Capítulo 0
Paquete (de red): Pequeño fragmento de datos enviado por una red con información de direccionamiento adjunta. Los mensajes grandes se dividen en muchos paquetes y se vuelven a ensamblar en el otro extremo. Capítulo 0
Parte interesada: Persona, equipo u organización con interés en un sistema, como usuarios, patrocinadores, desarrolladores, operadores, responsables de seguridad o reguladores. Capítulo 1
Partición (de un topic): En Kafka y registros similares, una parte ordenada de solo anexado (append-only) de un topic. Los eventos con la misma clave van a la misma partición; el orden solo está garantizado dentro de ella. Capítulo 6
Partición de red: Fallo de red que divide un sistema en grupos de nodos que no pueden comunicarse entre sí, aunque cada grupo pueda seguir funcionando y ser accesible para algunos clientes. Capítulo 6
Particionamiento (sharding): Dividir un conjunto de datos de modo que cada máquina guarde solo una parte, elegida mediante una clave de partición, para escalar las escrituras y el almacenamiento más allá de una sola máquina. Capítulo 7
Particionamiento por dominio: Dividir la estructura de nivel superior de un sistema por capacidad de negocio o subdominio, como pedidos, pagos y entregas. Capítulo 5
Particionamiento técnico: Dividir la estructura de nivel superior de un sistema según el papel técnico, como interfaz de usuario, lógica de negocio y acceso a datos. Capítulo 5
Passkey (llave de acceso): Credencial FIDO2/WebAuthn: un par de claves creado para un sitio web, cuya clave privada permanece en el dispositivo o el gestor de contraseñas del usuario, lo que hace el inicio de sesión resistente al phishing y no deja ningún secreto compartido en el servidor. Capítulo 8
Patrón arquitectónico: Una solución documentada y reutilizable a un problema estructural recurrente en un contexto determinado, que nombra las partes, sus responsabilidades y cómo se relacionan. A menudo se usa como sinónimo de estilo. Capítulo 5
Patrón de diseño: Una solución reutilizable a un problema recurrente a la escala de unas pocas clases u objetos, como Strategy u Observer; de alcance menor que un patrón arquitectónico. Capítulo 5
Patrón oscuro (dark pattern): Una interfaz de usuario diseñada para engañar o presionar a las personas para que tomen decisiones que de otro modo no tomarían, como costos ocultos o suscripciones difíciles de cancelar; Harry Brignull acuñó el término en 2010 y ahora los llama patrones engañosos (deceptive patterns). Capítulo 11
Percentil (p95, p99): El valor por debajo del cual queda una proporción dada de las mediciones. Un p99 de 400 ms significa que el 99% de las solicitudes tardaron 400 ms o menos y el 1% tardó más. Capítulo 2
Periodo de recuperación (payback): Cuánto tiempo tardan los beneficios acumulados en devolver el costo de una inversión; el periodo de recuperación descontado hace lo mismo con flujos de caja descontados. Capítulo 11
Persistencia políglota: Usar distintos tipos de base de datos para distintos datos dentro de un mismo sistema, elegidos según cómo se usa cada conjunto de datos, a costa de tener más tecnologías que operar. Capítulo 7
Perspectiva: En el enfoque de Rozanski y Woods, una inquietud de calidad, como la seguridad o el rendimiento, que se aplica a todas las vistas en lugar de representarse como una vista propia. Capítulo 4
Pilot light (piloto encendido): Estrategia de recuperación ante desastres que mantiene los datos replicados y la infraestructura básica aprovisionada en una segunda región, pero que solo arranca y escala los servidores de aplicaciones durante un desastre. Capítulo 10
Pipeline de CI/CD: La secuencia automatizada de pasos (compilación, pruebas, despliegue en staging, despliegue en producción) por la que pasa cada cambio en su camino hacia los usuarios. Capítulo 0
Pipeline de despliegue: La secuencia automatizada de etapas (compilación, pruebas, empaquetado, despliegue, verificación) por la que pasa cada cambio en su camino desde un commit hasta producción. Capítulo 10
Pirámide de pruebas: Guía, de Mike Cohn, sobre las proporciones de las pruebas automatizadas: muchas pruebas unitarias rápidas, menos pruebas de integración y solo unas pocas pruebas lentas de extremo a extremo. Capítulo 0
Pirámide del conocimiento: Modelo con tres capas: lo que sabes, lo que sabes que no sabes y lo que no sabes que no sabes. Los arquitectos amplían deliberadamente la capa intermedia. Capítulo 1
Pista arquitectónica (architectural runway): En el Scaled Agile Framework, el código, los componentes y la infraestructura existentes necesarios para implementar funcionalidades a corto plazo sin rediseños ni retrasos excesivos. Capítulo 1
Pista de auditoría: Un registro completo, cronológico y a prueba de manipulaciones de acciones definidas, que muestra quién hizo qué y cuándo, conservado para establecer la rendición de cuentas. Capítulo 8
PKCE: Proof Key for Code Exchange (RFC 7636): el cliente envía un hash de un secreto de un solo uso cuando inicia el flujo de código de autorización y el propio secreto cuando canjea el código, de modo que un código robado no sirve de nada. Capítulo 8
Planificación de capacidad: Prever la demanda futura, medir cuánto puede soportar cada unidad de infraestructura y disponer de capacidad suficiente, con margen, antes de que se necesite. Capítulo 9
Plano de control: Los componentes que toman decisiones para un clúster o un sistema (en Kubernetes: el servidor de API, etcd, el planificador y los controladores), a diferencia de los nodos que ejecutan las cargas de trabajo. Capítulo 10
Plano de fractura: Una línea divisoria natural por la que puede dividirse un sistema de software para que cada parte se ajuste a un equipo, por ejemplo, un contexto delimitado, un límite regulatorio, un ritmo de cambio distinto o un perfil de riesgo distinto. Capítulo 11
Plataforma interna para desarrolladores (IDP): El conjunto de herramientas, servicios, plantillas y documentación de autoservicio que proporciona el equipo de plataforma de una organización para que los equipos de producto puedan construir y operar software sin tickets. Capítulo 10
Plataforma viable más delgada (thinnest viable platform): El conjunto más pequeño de servicios compartidos y documentación que realmente acelera a los equipos de producto; la advertencia de Team Topologies contra construir más plataforma de la necesaria. Capítulo 10
Plug-in: Módulo construido por separado que añade comportamiento a una aplicación anfitriona mediante un contrato que publica el anfitrión, sin que cambie el código del anfitrión. Capítulo 5
Pod: La unidad desplegable más pequeña de Kubernetes: uno o más contenedores planificados juntos en un nodo, que comparten una dirección de red y volúmenes de almacenamiento. Capítulo 10
Poder de dos elecciones aleatorias (power of two choices): Método de balanceo de carga que elige dos instancias al azar y envía la solicitud a la menos cargada; Mitzenmacher demostró que equilibra casi tan bien como comprobar todas las instancias. Capítulo 9
Política como código: Escribir reglas sobre la infraestructura y los despliegues (ningún almacenamiento público, cifrado obligatorio, regiones aprobadas) como código que las herramientas comprueban automáticamente antes o durante los cambios. Capítulo 10
Política de presupuesto de errores: Una declaración escrita y acordada de lo que hará un equipo cuando su presupuesto de errores se esté gastando demasiado rápido o se haya agotado, como congelar los lanzamientos arriesgados. Capítulo 9
Portal para desarrolladores: Una interfaz web, como Backstage, que reúne en un solo lugar un catálogo de software, plantillas, documentación y enlaces a los servicios de la plataforma. Capítulo 10
Postcondición: Condición que una operación garantiza que será verdadera cuando termine, siempre que se haya cumplido su precondición. Capítulo 3
Pre-mortem: Técnica de Gary Klein (2007) en la que un equipo imagina que su proyecto ya ha fracasado y cada persona escribe por qué, lo que saca a la luz riesgos que de otro modo la gente se resiste a plantear. Capítulo 11
Precisión y exhaustividad (recall): La precisión es la proporción de elementos que un modelo marca que son realmente positivos; la exhaustividad (recall) es la proporción de positivos reales que el modelo detecta. Aumentar una suele reducir la otra. Capítulo 12
Precondición: Condición que debe ser verdadera antes de llamar a una operación; cumplirla es obligación de quien llama. Capítulo 3
Presupuesto de errores: La cantidad de falta de fiabilidad que permite un SLO: uno menos el objetivo, aplicado a la ventana. Un SLO de 99.9% sobre 1 000 000 de solicitudes permite 1000 solicitudes erróneas. Capítulo 9
Presupuesto de latencia: La parte de un objetivo de tiempo de respuesta de extremo a extremo asignada a cada paso o servicio en el recorrido de una solicitud, para que cada equipo conozca el límite que debe respetar. Capítulo 11
Presupuesto de reintentos: Límite de reintentos expresado como una proporción del tráfico normal (por ejemplo, el 10%), para que los reintentos ayuden con los fallos ocasionales pero no puedan multiplicar la carga durante una caída del servicio. Capítulo 9
Presupuesto de rendimiento: Límite acordado sobre una medida de rendimiento, como el peso de la página o la latencia p99 por llamada a un servicio, que un cambio no debe superar, idealmente comprobado de forma automática. Capítulo 9
Prima de los microservicios (microservice premium): Término de Martin Fowler (2015) para el costo y el riesgo adicionales que añaden los microservicios, que solo compensan cuando un sistema y una organización son lo bastante complejos. Capítulo 5
Principal (de la deuda técnica): El esfuerzo necesario para corregir una porción de deuda técnica, es decir, para llevar el código o la estructura al estado en que debería estar. Capítulo 1
Principio abierto-cerrado (OCP): Un módulo debe estar abierto a la extensión pero cerrado a la modificación: el comportamiento nuevo debe añadirse agregando código, como una nueva implementación de una interfaz, no editando código que funciona. Formulado por primera vez por Bertrand Meyer en 1988. Capítulo 3
Principio de abstracciones estables: Principio de Robert C. Martin según el cual un componente debe ser tan abstracto como estable, para que los componentes estables puedan seguir extendiéndose. Capítulo 3
Principio de arquitectura: Una regla duradera que orienta las decisiones arquitectónicas, redactada al estilo de TOGAF con un nombre, un enunciado, una justificación y sus implicaciones. Capítulo 11
Principio de cierre común (CCP): Las clases que cambian por los mismos motivos y en los mismos momentos deben estar en el mismo componente; es el principio de responsabilidad única aplicado a los componentes. Capítulo 3
Principio de dependencias acíclicas: Principio de Robert C. Martin según el cual el grafo de dependencias entre componentes no debe contener ciclos. Capítulo 3
Principio de dependencias estables: Principio de Robert C. Martin según el cual un componente solo debe depender de componentes más estables que él: depender en la dirección de la estabilidad. Capítulo 3
Principio de equivalencia entre reutilización y lanzamiento (REP): La unidad de reutilización es la unidad de lanzamiento: las clases agrupadas en un componente deben tener sentido para lanzarse, versionarse y reutilizarse juntas. Capítulo 3
Principio de inversión de dependencias (DIP): La política de alto nivel no debe depender de los detalles de bajo nivel; ambos deben depender de abstracciones, y la abstracción debe pertenecer al lado de la política. Capítulo 3
Principio de responsabilidad única (SRP): Un módulo debe responder ante un solo actor: un grupo de personas que solicita sus cambios. El código que cambia por motivos distintos, a petición de personas distintas, debe mantenerse separado. Capítulo 3
Principio de reutilización común (CRP): Las clases que se usan juntas deben estar juntas, y no se debe obligar a quienes usan un componente a depender de clases que no utilizan. Capítulo 3
Principio de segregación de interfaces (ISP): No se debe obligar a los clientes a depender de operaciones que no usan; es preferible tener varias interfaces pequeñas y específicas para cada cliente que una grande. Capítulo 3
Principio de sustitución de Liskov (LSP): Todo lo que afirma ser un subtipo debe poder usarse dondequiera que se espere su supertipo sin que quien llama note una diferencia de comportamiento. Lleva el nombre de Barbara Liskov. Capítulo 3
Problem details (RFC 9457): Formato JSON estándar para los errores de las API HTTP, con los miembros type, title, status, detail e instance, servido como application/problem+json. El RFC 9457 (2023) sustituyó al RFC 7807. Capítulo 6
Problema de las consultas N+1: Fallo de rendimiento en el que el código hace una consulta para obtener una lista de N elementos y luego una consulta más por elemento, lo que da N+1 viajes de ida y vuelta donde bastarían uno o dos. Capítulo 6
Procedencia (provenance): Información verificable sobre el origen de un artefacto: qué plataforma de compilación lo construyó, a partir de qué revisión del código fuente, con qué entradas y qué parámetros. Capítulo 8
Procedencia de los datos: El origen y el historial documentados de los datos: de dónde proceden, bajo qué licencia o consentimiento, y cómo se han transformado. Capítulo 12
Procesamiento de flujos (stream processing): Procesar de forma continua un flujo ilimitado de registros, cada uno poco después de que llegue. Capítulo 5
Procesamiento por lotes: Procesar un conjunto acotado de datos en una sola ejecución, como todos los pedidos de ayer, y terminar. Capítulo 5
Proceso: Instancia en ejecución de un programa, con su propia memoria privada y su parte del tiempo de CPU, creada y gestionada por el sistema operativo. Capítulo 0
Proceso de consejo (advice process): Una forma descentralizada de tomar decisiones en la que cualquiera puede decidir, siempre que antes pida consejo a los afectados y a los expertos pertinentes. Capítulo 4
Proceso en segundo plano (background worker): Un proceso que toma trabajos lentos o con picos, como correos electrónicos o informes, de una cola y los procesa fuera de la solicitud que los creó. Capítulo 5
Producción: El entorno real del que dependen los usuarios reales y los datos reales. Capítulo 0
Producto de datos: Un conjunto de datos que un equipo de dominio publica para que otros lo usen, con un propietario, documentación, garantías de calidad y una interfaz estable. Capítulo 7
Programa: Lista de instrucciones precisas que una computadora sigue para hacer un trabajo. Un programa en ejecución se llama proceso. Capítulo 0
Prompt: Todo lo que se envía a un modelo de lenguaje en una llamada: instrucciones del sistema, historial de la conversación, documentos recuperados, definiciones de herramientas y el mensaje del usuario. Capítulo 12
Propagación de contexto: Pasar los identificadores de traza (y otro contexto de la solicitud) de un servicio al siguiente con cada llamada o mensaje, por ejemplo en la cabecera traceparent del W3C. Capítulo 9
Propagación de plazos (deadline propagation): Pasar a cada llamada descendente el tiempo que le queda a una solicitud completa, para que ningún servicio siga trabajando en una solicitud que quien la hizo ya ha abandonado. Capítulo 9
Propiedad conjunta: Situación en la que varios servicios escriben todos los mismos datos. Puede resolverse dividiendo la tabla, con un pequeño dominio de datos compartido, delegando las escrituras en un único propietario o fusionando los servicios. Capítulo 7
Propiedad de los datos: La regla de que cada dato lo escribe exactamente un módulo o servicio, al que los demás deben preguntar en lugar de leer o modificar directamente su almacenamiento. Capítulo 3
Protección de datos desde el diseño y por defecto: La obligación del artículo 25 del RGPD (GDPR) de incorporar los principios de protección de datos a los sistemas mediante medidas adecuadas y de tratar por defecto solo los datos necesarios para cada finalidad. Capítulo 8
Protocol Buffers: Formato binario compacto e independiente del lenguaje para datos estructurados, definido en archivos .proto en los que cada campo tiene un número permanente. Lo usan gRPC y muchos sistemas de mensajería. Capítulo 6
Proyección: Código que escucha cambios o eventos y mantiene actualizado un modelo de lectura; también se usa para designar el modelo de lectura que produce. Capítulo 7
Prueba de arquitectura: Una prueba automatizada que hace fallar la compilación cuando el código rompe una regla estructural, como una dependencia prohibida entre capas o módulos; entre las herramientas están ArchUnit e import-linter. Capítulo 5
Prueba de caracterización: Una prueba que registra lo que el código existente hace realmente, y no lo que debería hacer, para que los cambios puedan contrastarse con el comportamiento actual. El término procede de Michael Feathers. Capítulo 11
Prueba de carga: Prueba de rendimiento que aplica la carga esperada (o el pico previsto) durante un periodo para comprobar que se cumplen los objetivos de latencia y de errores. Capítulo 9
Prueba de concepto: Pequeña porción de código funcional, con un tiempo limitado, construida para comprobar si una idea, una tecnología o una opción de diseño funciona antes de comprometerse con ella. Capítulo 1
Prueba de estrés: Prueba de rendimiento que lleva la carga más allá del pico esperado para ver cómo falla el sistema y si se recupera. Capítulo 9
Prueba de extremo a extremo: Una prueba automatizada que maneja todo el sistema como lo haría un usuario, por ejemplo, tocando las pantallas de una app, para comprobar un recorrido completo. Capítulo 0
Prueba de integración: Una prueba automatizada que comprueba que varias partes funcionan correctamente juntas, como el código con una base de datos real o con la API de otro servicio. Capítulo 0
Prueba de picos (spike test): Prueba de rendimiento que aumenta la carga de golpe, por ejemplo diez veces en segundos, para comprobar el autoescalado, las colas y los mecanismos de protección. Capítulo 9
Prueba de punto de ruptura: Una prueba de rendimiento que aumenta la carga de forma constante hasta que el sistema se rompe, para encontrar su capacidad máxima y su primer cuello de botella. Capítulo 9
Prueba de resistencia (soak test): Prueba de rendimiento larga con carga normal, ejecutada durante horas o días, para revelar problemas lentos como fugas de memoria o colas que crecen; también se llama prueba de durabilidad (endurance test). Capítulo 9
Prueba unitaria: Prueba automatizada que comprueba una pequeña porción de código, como una función, de forma aislada, y que se ejecuta en milisegundos. Capítulo 0
Pruebas de contrato: Probar cada lado de una integración de forma aislada frente a una descripción compartida de sus interacciones, en lugar de desplegar ambos juntos para hacer pruebas de extremo a extremo. Capítulo 6
Publicación-suscripción (publish-subscribe): Patrón de mensajería en el que un publicador envía un mensaje a un topic y cada suscriptor recibe su propia copia, sin que el publicador sepa quiénes son. Capítulo 6
Puerto: Número de 0 a 65535 que identifica qué programa de un dispositivo debe recibir el tráfico de red, como el 443 para HTTPS. Capítulo 0
Puertos y adaptadores (arquitectura hexagonal): Estilo de Alistair Cockburn en el que una aplicación se comunica con el mundo exterior solo a través de puertos (interfaces que le pertenecen), y los adaptadores traducen entre cada puerto y una tecnología concreta. Capítulo 5
Pull request: Solicitud para fusionar una rama en la línea principal, en un servicio como GitHub, donde los compañeros revisan el cambio y se ejecutan comprobaciones automáticas antes de aceptarlo. Capítulo 0
Punto de aplicación de políticas (PEP): El componente situado en la ruta del tráfico, como un proxy, una pasarela o un sidecar, que permite o bloquea cada solicitud según una decisión de política. Capítulo 8
Punto de compromiso: Decisión arquitectónica que afecta a más de un atributo de calidad, mejorando uno y perjudicando otro. Capítulo 2
Punto de decisión de políticas (PDP): El componente que evalúa la política de acceso y responde permitir o denegar; un punto de aplicación de políticas (PEP) le consulta y luego aplica la respuesta. Capítulo 8
Punto de entrada (empaquetado de Python): Metadatos de un paquete de Python instalado que anuncian un objeto, como una clase de plugin, bajo un grupo con nombre para que otro código pueda descubrirlo en tiempo de ejecución. Capítulo 5
Punto de extensión: Un hueco con nombre que declara una aplicación anfitriona o un plugin para que otros plugins puedan aportarle comportamiento, como en la plataforma Eclipse. Capítulo 5
Punto de sensibilidad: Propiedad de uno o más componentes o conexiones que es crítica para lograr una respuesta de calidad concreta, como el número de saltos síncronos en la ruta de un pedido. Capítulo 11
Punto de vista: Especificación de cómo construir y leer un tipo de vista de arquitectura: a qué partes interesadas e inquietudes sirve y qué convenciones de modelado usa. Capítulo 1

Q

Quality Attribute Workshop (QAW): Método guiado del SEI en el que las partes interesadas generan ideas, consolidan, votan y refinan escenarios de atributos de calidad en las primeras fases de un proyecto. Capítulo 2
Quórum (R + W > N): En un almacén con N réplicas, una escritura espera W confirmaciones y una lectura R respuestas; si R + W > N, cada conjunto de lectura se solapa con cada conjunto de escritura en al menos una réplica. Capítulo 6

R

Radar tecnológico: Mapa de tecnologías y técnicas que se actualiza periódicamente, agrupadas en cuadrantes y situadas en anillos como Adopt, Trial, Assess y Hold (rebautizado Caution en ediciones recientes de Thoughtworks), popularizado por Thoughtworks. Capítulo 11
Radio de impacto (blast radius): Qué parte del sistema y cuántos usuarios pueden verse afectados por un fallo, un cambio o un experimento; los experimentos de caos lo mantienen deliberadamente pequeño. Capítulo 9
Raíz de composición: El único lugar, normalmente el código de arranque del programa, donde se crean los adaptadores concretos y se conectan a la aplicación. Capítulo 5
RAM (memoria): Memoria de acceso aleatorio (random-access memory): almacenamiento rápido y temporal que guarda los programas y datos en uso en ese momento. Su contenido se pierde cuando se corta la corriente o termina el programa. Capítulo 0
Rama: Una línea de desarrollo separada en el control de versiones, que se usa para trabajar en un cambio sin afectar a la línea principal hasta que esté listo para fusionarse. Capítulo 0
Re-ranking (reordenación): Segunda etapa de recuperación en la que un modelo más preciso pero más lento vuelve a puntuar los mejores candidatos de la primera etapa y se queda con los pocos mejores. Capítulo 12
ReAct: Reasoning and acting (razonar y actuar; Yao y colaboradores, 2022): patrón en el que un modelo intercala pasos de razonamiento con acciones y usa cada observación para decidir el siguiente paso. Capítulo 12
Recuperación ante desastres (DR): Los planes, las copias y los procedimientos que restablecen un servicio y sus datos tras un fallo grave, como la pérdida de todo un centro de datos o de una región. Capítulo 10
Red de distribución de contenidos (CDN): Una red de servidores en muchas ubicaciones que guarda copias de contenido como imágenes, scripts y vídeo cerca de los usuarios, para que se cargue más rápido y el servidor de origen trabaje menos. Capítulo 0
Red teaming: Pruebas adversariales deliberadas en las que personas o herramientas intentan que un sistema se comporte mal, filtre datos o cause daños, para encontrar las debilidades antes que los atacantes. Capítulo 12
Redundancia: Mantener más de una copia de un componente para que otra pueda tomar el relevo si una falla. Capítulo 2
Reescritura big-bang: Sustituir un sistema construyendo uno nuevo desde cero y cambiando a él de una sola vez; se considera ampliamente de alto riesgo porque el valor llega solo al final y es fácil perder comportamientos ocultos. Capítulo 11
Refactorización: Cambiar la estructura interna del código sin cambiar su comportamiento externo, para que sea más fácil de entender y modificar. Capítulo 1
Región: Zona geográfica, como Europa Occidental o el este de EE. UU., en la que un proveedor de nube opera un grupo separado de centros de datos. Las regiones están aisladas entre sí. Capítulo 0
Registro de decisiones de arquitectura (ADR): Un documento breve que registra una decisión significativa: su contexto, las opciones consideradas, la decisión, su estado y sus consecuencias. Capítulo 1
Registro de escritura anticipada (write-ahead log, WAL): Log de solo anexado en disco en el que una base de datos registra cada cambio antes de aplicarlo, para que el trabajo confirmado sobreviva a una caída; las réplicas suelen alimentarse de él. Capítulo 7
Registro de esquemas: Servicio que almacena todas las versiones de cada esquema de mensaje y rechaza las versiones nuevas que rompen la regla de compatibilidad acordada. Capítulo 7
Registro de plug-ins: La parte de un sistema central que registra qué plug-ins están disponibles, sus nombres, versiones y contratos, para que el núcleo pueda encontrarlos sin nombrarlos en el código. Capítulo 5
Registro de riesgos: Lista mantenida de los riesgos identificados con su probabilidad, impacto, responsable, mitigación y estado, para que se sigan hasta su cierre en lugar de olvidarse después de una reunión. Capítulo 11
Regla de dependencia: La regla de Robert C. Martin para la arquitectura limpia: las dependencias del código fuente apuntan solo hacia dentro, de modo que los anillos interiores nunca nombran nada declarado en los anillos exteriores. Capítulo 5
Reglamento de Ciberresiliencia (Cyber Resilience Act, CRA): El Reglamento (UE) 2024/2847, que establece requisitos de ciberseguridad, gestión de vulnerabilidades y obligaciones de notificación para los productos de hardware y software que se venden en la UE. Capítulo 8
Reglamento de IA de la UE (EU AI Act): El Reglamento (UE) 2024/1689, la ley de la Unión Europea sobre inteligencia artificial basada en el riesgo, modificada en 2026 por el Reglamento (UE) 2026/1744. Capítulo 12
Relación: Conexión entre elementos, como un módulo que usa otro, un servicio que llama a otro o un servicio desplegado en un servidor. Capítulo 1
Rendimiento (throughput): La cantidad de trabajo que un sistema completa por unidad de tiempo, como 1200 solicitudes por segundo o 40 000 pedidos por hora. Capítulo 2
Repatriación desde la nube: Sacar cargas de trabajo de una nube pública y devolverlas a hardware propio o en colocation, normalmente porque una carga estable hace que la propiedad resulte más barata. Capítulo 10
Réplica de lectura: Copia de una base de datos que recibe los cambios del primario y atiende consultas de lectura, lo que reduce la carga del primario a costa de datos ligeramente desactualizados. Capítulo 5
Replicación: Mantener copias de los mismos datos en varias máquinas para lograr disponibilidad, capacidad de lectura y menor latencia cerca de los usuarios. Capítulo 7
Replicación líder-seguidor: Esquema de replicación en el que un nodo (el líder o primario) acepta todas las escrituras y transmite sus cambios a los seguidores (réplicas), que pueden atender lecturas. Capítulo 7
Replicación multilíder: Esquema en el que varios nodos aceptan escrituras y se replican entre sí, lo que exige una forma de detectar y resolver escrituras en conflicto. Capítulo 7
Replicación sin líder: Esquema al estilo de Dynamo en el que los clientes escriben y leen directamente en varias réplicas y usan quórums en lugar de un único líder. Capítulo 7
Repositorio: Objeto que carga y guarda agregados completos y que, para el dominio, parece una colección, ocultando cómo y dónde se almacenan. Capítulo 5
Repositorio de artefactos: Un almacén de resultados compilados y versionados, como imágenes de contenedor y paquetes, desde el que todos los entornos despliegan el mismo archivo. Capítulo 10
Requisito: Enunciado de algo que un sistema debe hacer, o de una cualidad que debe tener, acordado con las personas que lo necesitan. Capítulo 0
Requisito arquitectónicamente significativo (ASR): Un requisito que tiene un efecto medible en la arquitectura de un sistema: si cambiara, la estructura tendría que cambiar. La mayoría de los ASR son atributos de calidad o restricciones. Capítulo 2
Requisito funcional: Una declaración de lo que un sistema debe hacer: un comportamiento, un cálculo o una información que debe proporcionar, como "un cliente puede cancelar un pedido antes de que se envíe". Capítulo 2
Requisito implícito: Una cualidad que todas las partes interesadas dan por supuesta pero que nadie pone por escrito, como "los pedidos nunca se pierden" o "el sistema sigue funcionando durante un cambio de hora". Capítulo 2
Requisito no funcional (NFR): Nombre muy usado pero impreciso para los requisitos de calidad y las restricciones. Muchos arquitectos lo evitan porque estos requisitos califican a las funciones en lugar de existir al margen de ellas. Capítulo 2
Residencia de datos: Un requisito de que ciertos datos se almacenen, y a veces se traten, solo en un país o una región determinados. Capítulo 2
Resiliencia: La capacidad más amplia de un sistema para absorber perturbaciones, mantener su servicio esencial (quizá de forma degradada) y volver después a la normalidad. Capítulo 2
Responsable del tratamiento (controller): La organización que decide por qué y cómo se tratan los datos personales y que tiene la responsabilidad principal de cumplir la legislación de protección de datos. Capítulo 8
Respuesta a incidentes: La gestión organizada de un incidente de seguridad: detectarlo y analizarlo, contenerlo, eliminar la causa, recuperarse y aprender de él. Capítulo 8
REST (Representational State Transfer): Estilo arquitectónico para API web, descrito por Roy Fielding en 2000, en el que los clientes actúan sobre recursos identificados por URL mediante los métodos HTTP estándar. Capítulo 0
Restricción: Una decisión de diseño que ya se ha tomado por ti, sin libertad o con muy poca libertad restante, como un lenguaje de programación obligatorio, una normativa, un plazo fijo o un presupuesto. Capítulo 2
Resumen de arquitectura en una página: Una sola página con el propósito del sistema, sus objetivos de calidad, su contexto, sus bloques de construcción principales, sus decisiones clave y sus riesgos, como puerta de entrada a una documentación más completa. Capítulo 4
Retardo de replicación (replication lag): El retardo entre una escritura en el líder y su aparición en un seguidor; hace que los usuarios lean datos desactualizados. Capítulo 7
Reversibilidad: Lo barato y seguro que resulta deshacer una decisión. Las decisiones muy reversibles pueden tomarse rápido; las irreversibles merecen más análisis. Capítulo 1
Revisión de código: El examen por parte de colegas de un cambio de código propuesto antes de fusionarlo, para encontrar defectos, compartir conocimiento y mantener la coherencia del diseño. Capítulo 0
Revisión de diseño (revisión de RFC): Una revisión escrita de un documento de diseño propuesto o de una solicitud de comentarios, en la que las personas afectadas comentan de forma asíncrona antes de que se apruebe el diseño y se registren sus decisiones. Capítulo 11
Revisión posterior al incidente: Reunión estructurada e informe escrito tras un incidente que reconstruyen lo que ocurrió, por qué tuvo sentido para las personas implicadas y qué va a cambiar; también se llama postmortem. Capítulo 9
Riesgo (en la evaluación de arquitectura): Decisión arquitectónica, o decisión que falta, que puede impedir que el sistema cumpla un requisito de calidad o un objetivo de negocio importante. Capítulo 11
Risk-storming: Técnica colaborativa de Simon Brown en la que las personas marcan en silencio los riesgos sobre diagramas de arquitectura con notas adhesivas, puntuados por probabilidad e impacto, y después convergen y acuerdan prioridades y mitigaciones. Capítulo 11
Roll forward (corrección hacia adelante): Recuperarse de un lanzamiento defectuoso desplegando una nueva corrección en lugar de volver a la versión anterior. Capítulo 10
Rollback: Devolver un sistema a un estado o una versión anterior que se sabe correcto después de que un cambio cause problemas. Capítulo 2
Runbook (manual de operaciones): Procedimiento escrito y probado para gestionar paso a paso una situación operativa o de seguridad concreta, que incluye cómo verificar y revertir cada paso. Capítulo 8

S

SaaS (software como servicio): Software completo que se usa por internet, normalmente desde un navegador o una app, con el proveedor operándolo todo. Capítulo 0
Saga: Transacción de negocio implementada como una secuencia de transacciones locales, cada una emparejada con una transacción compensatoria, de modo que o se completan todos los pasos o los pasos completados se deshacen semánticamente. Presentada por Garcia-Molina y Salem en 1987. Capítulo 6
Salida de datos (egress): Los datos que salen de la red de un proveedor de nube, o que pasan entre sus zonas o regiones, lo que normalmente se cobra por gigabyte. Capítulo 10
Salida estructurada: Salida del modelo restringida a un formato declarado, normalmente un JSON Schema, para que la aplicación pueda analizarla y validarla de forma fiable. Capítulo 12
Sandbox (entorno aislado): Entorno aislado con permisos, acceso a la red y recursos muy limitados, en el que puede ejecutarse de forma segura código no confiable, como el código escrito por un modelo. Capítulo 12
Scrum: Marco ágil en el que un equipo pequeño trabaja en ciclos fijos llamados sprints, de un mes o menos, con eventos, responsabilidades y artefactos definidos. Capítulo 0
SDK (kit de desarrollo de software): Biblioteca, normalmente proporcionada por el propietario de una API, que envuelve las llamadas HTTP de la API en funciones normales para un lenguaje de programación concreto. Capítulo 0
Secuencia principal: La recta A + I = 1 en un gráfico de abstracción frente a inestabilidad, donde se sitúan los componentes bien equilibrados. La distancia a ella es D = |A + I - 1|. Capítulo 3
Secure Software Development Framework (SSDF): NIST SP 800-218: conjunto de prácticas de desarrollo seguro agrupadas en preparar la organización, proteger el software, producir software bien protegido y responder a las vulnerabilidades. Capítulo 8
Seguir una solicitud: Explicar un sistema rastreando un único evento concreto, como un pedido, paso a paso a través de cada parte por la que pasa. Capítulo 4
Seguridad (safety): Ausencia de un riesgo inaceptable de daños a personas, bienes o el medio ambiente causados por el sistema, actúe o no alguien con mala intención. Capítulo 2
Seguridad perimetral: El modelo tradicional que protege una red interna de confianza con cortafuegos y VPN y trata como amigo todo lo que ya está dentro; a veces se le llama seguridad de castillo y foso. Capítulo 8
Seguridad psicológica: Creencia compartida dentro de un equipo de que es seguro asumir riesgos interpersonales, como admitir errores o cuestionar a un colega de mayor rango; estudiada por Amy Edmondson desde 1999. Capítulo 11
Seguro por defecto: Entregar un producto cuya configuración inicial es la segura, de modo que los usuarios tengan que elegir deliberadamente debilitar la protección en lugar de acordarse de activarla. Capítulo 8
Separación comando-consulta (CQS): Principio de Bertrand Meyer según el cual un método debe cambiar el estado (un comando) o devolver una respuesta (una consulta), pero no ambas cosas. Capítulo 7
Serializabilidad: La garantía de aislamiento más fuerte: las transacciones concurrentes producen el mismo resultado que si se hubieran ejecutado de una en una en algún orden. Capítulo 7
Serverless: Modelo de nube en el que el proveedor ejecuta tus funciones o flujos de trabajo bajo demanda y factura por uso, de modo que no gestionas servidores tú mismo. Capítulo 1
Serverless y FaaS (función como servicio): Modelo de nube en el que subes funciones individuales que solo se ejecutan cuando un evento las desencadena; el proveedor se encarga de todos los servidores y pagas por ejecución. Capítulo 0
Service (Kubernetes): Objeto de Kubernetes que da a un conjunto cambiante de pods un nombre estable y una dirección virtual, y reparte el tráfico entre ellos. Capítulo 10
Service mesh (malla de servicios): Capa de infraestructura formada por proxies de red, configurados de forma centralizada, que proporciona cifrado entre servicios, reintentos, timeouts, control del tráfico y telemetría. Capítulo 6
Servicio de dominio: En la arquitectura basada en servicios, un servicio desplegado por separado que abarca toda un área de negocio, como pedidos o pagos, desde la API hasta el acceso a los datos. Capítulo 6
Servicio de gestión de claves (KMS): Servicio gestionado que crea, almacena, rota y controla el uso de claves criptográficas, y realiza operaciones con ellas para que las aplicaciones nunca vean las claves maestras. Capítulo 8
Servicio de host abierto (open host service): Patrón del mapa de contextos en el que un contexto upstream ofrece un único protocolo o API bien definido y documentado para todos sus consumidores. Capítulo 5
Servicio de respaldo (backing service): Cualquier servicio que una aplicación usa a través de la red, como una base de datos, una cola, una caché o una API de correo electrónico, tratado como un recurso adjunto que la configuración puede intercambiar. Capítulo 10
Servicio gestionado: Servicio en la nube, como una base de datos, una cola o un servicio de almacenamiento, que el proveedor instala, opera, parchea y escala, de modo que los clientes lo usan sin tener que operarlo. Capítulo 0
Servicio sin estado: Instancia de servicio que no guarda datos entre solicitudes en su propia memoria ni en su disco, de modo que cualquier instancia puede atender cualquier solicitud y pueden añadirse o retirarse instancias libremente. Capítulo 9
Servidor: Computadora, o programa que se ejecuta en ella, que espera solicitudes de otras computadoras (clientes) y las responde. Capítulo 0
Sesgo algorítmico: Resultados sistemáticamente peores de un sistema automatizado para algunos grupos de personas, causados por los datos, el diseño o el contexto de uso. Capítulo 12
Sesgo cognitivo: Un error sistemático de razonamiento, como el anclaje o la falacia del costo hundido, que lleva a las personas a juzgar las opciones de forma injusta. Capítulo 1
Sesgo de automatización: La tendencia de las personas a aceptar las recomendaciones de un sistema automatizado sin examinarlas lo suficiente, incluso cuando son erróneas. Capítulo 12
Sesión persistente (sticky session, afinidad de sesión): Ajuste del balanceador de carga que envía todas las solicitudes de un cliente a la misma instancia, normalmente para que puedan encontrarse los datos de sesión guardados en la memoria de esa instancia. Capítulo 9
Seudonimización: Tratar datos personales de forma que ya no puedan vincularse a una persona sin información adicional guardada por separado; según el RGPD (GDPR), los datos seudonimizados siguen siendo datos personales. Capítulo 8
Shift left: Adelantar las actividades de seguridad (o de pruebas) en el ciclo de vida del desarrollo, hacia los requisitos, el diseño y la codificación, donde corregir los problemas es más barato que en producción. Capítulo 8
Showback: Informar a cada equipo o producto de los costos que se le atribuyen, sin cargarlos realmente a su presupuesto. Capítulo 10
Shuffle sharding: Asignar a cada cliente una combinación pequeña y elegida al azar de recursos, de modo que dos clientes rara vez compartan todos los suyos y un cliente problemático afecte a pocos más. Capítulo 10
SIEM: Security information and event management (gestión de información y eventos de seguridad): sistema que recopila logs de seguridad de muchas fuentes, los correlaciona y genera alertas cuando coinciden con reglas de detección. Capítulo 8
Sigstore: Proyecto de código abierto para firmar y verificar artefactos de software con certificados de corta duración vinculados a una identidad y un registro público de transparencia, lo que evita las claves de firma de larga duración. Capítulo 8
Sistema central (core system): En una arquitectura de microkernel, la parte mínima de la aplicación que necesita toda instalación: el flujo de trabajo principal, los servicios compartidos y los puntos donde se conectan los plugins. Capítulo 5
Sistema de gestión de bases de datos (DBMS): El software que almacena una base de datos y controla el acceso a ella: responde consultas, hace cumplir reglas, atiende a muchos usuarios a la vez y se recupera tras las caídas. PostgreSQL y MySQL son ejemplos. Capítulo 0
Sistema de IA de alto riesgo: Según el Reglamento de IA de la UE, un sistema de IA que es un componente de seguridad de un producto regulado (anexo I) o que se usa en un ámbito sensible enumerado en el anexo III, como el empleo o el crédito. Capítulo 12
Sistema de registro (system of record): La fuente autoritativa de un dato, cuyo valor prevalece cuando las copias no coinciden, como el libro mayor central de un banco para los saldos de las cuentas. Capítulo 7
Sistema de software (C4): En el modelo C4, el nivel de abstracción más alto: algo que aporta valor a sus usuarios y que normalmente pertenece a un equipo u organización. Capítulo 4
Sistema distribuido: Un conjunto de programas que se ejecutan en distintas computadoras y cooperan enviándose mensajes a través de una red, de modo que los usuarios ven un único servicio. Capítulo 6
Sistema heredado (legacy): Sistema existente que sigue aportando valor pero que se ha vuelto difícil, arriesgado o caro de cambiar, a menudo por su antigüedad, la falta de pruebas, la escasez de conocimientos o una tecnología sin soporte. Capítulo 11
Sistema operativo: El software que gestiona el hardware de una computadora y lo reparte entre los programas: tiempo de CPU, memoria, archivos, red y seguridad. Algunos ejemplos son Linux, Windows, macOS, Android e iOS. Capítulo 0
SLSA: Supply-chain Levels for Software Artifacts: marco de niveles crecientes de garantía de que un artefacto se construyó a partir del código fuente esperado mediante una compilación confiable y resistente a la manipulación. Capítulo 8
Snapshot (instantánea): Copia almacenada del estado de un agregado en una versión de evento conocida, que se usa para no tener que reproducir un flujo largo desde el principio; es una caché, no una fuente de verdad. Capítulo 7
Sobreajuste (overfitting): Cuando un modelo aprende las peculiaridades de sus datos de entrenamiento en lugar del patrón general, de modo que obtiene buenos resultados con los ejemplos que ha visto y malos con los nuevos. Capítulo 12
Software: Los programas junto con los datos y la configuración que necesitan; las instrucciones que le dicen al hardware qué hacer. Capítulo 0
Software Carbon Intensity (SCI): Especificación de la Green Software Foundation, publicada como ISO/IEC 21031:2024, que expresa las emisiones de carbono del software como una tasa: ((energía x intensidad de carbono de la red eléctrica) + emisiones incorporadas) por unidad funcional. Capítulo 2
Software Carbon Intensity (SCI): La especificación de la Green Software Foundation, publicada como ISO/IEC 21031:2024, que califica el software como ((E × I) + M) por R: energía multiplicada por la intensidad de carbono de la red eléctrica más las emisiones incorporadas, por unidad funcional. Capítulo 11
Solicitud de cobertura (hedged request): Enviar una segunda copia de una solicitud lenta a otra réplica tras un breve retraso y usar la respuesta que llegue primero, para reducir la latencia de cola. Capítulo 9
Solicitudes y límites de recursos (requests y limits): Ajustes de CPU y memoria por contenedor en Kubernetes: las solicitudes (requests) reservan capacidad y orientan la planificación; los límites (limits) acotan el uso, estrangulando la CPU y terminando los contenedores que superan la memoria. Capítulo 10
SOLID: Acrónimo mnemotécnico de cinco principios de diseño orientado a objetos reunidos por Robert C. Martin: responsabilidad única, abierto-cerrado, sustitución de Liskov, segregación de interfaces e inversión de dependencias. Capítulo 3
Sonda (liveness, readiness, startup): Comprobación periódica que Kubernetes hace sobre un contenedor: la de actividad (liveness) decide si reiniciarlo, la de preparación (readiness) si enviarle tráfico y la de arranque (startup) si ha terminado de arrancar. Capítulo 10
Sonda de actividad (liveness probe): Comprobación de salud que pregunta si un proceso está bloqueado sin posibilidad de recuperarse; si falla, el orquestador reinicia la instancia. Capítulo 9
Sonda de preparación (readiness probe): Comprobación de salud que pregunta si una instancia puede atender tráfico en este momento; si falla, la instancia se retira del balanceador de carga sin reiniciarla. Capítulo 9
Span: Una operación cronometrada dentro de una traza, como una llamada HTTP o una consulta a la base de datos, con un nombre, una hora de inicio, una duración, atributos y un enlace a su span padre. Capítulo 9
Spike (investigación acotada): Investigación o prototipo breve y con tiempo limitado construido para responder a una pregunta técnica o reducir un riesgo, que normalmente se desecha después. Capítulo 1
Split brain (cerebro dividido): Fallo en el que dos nodos creen ser el líder y ambos aceptan escrituras, de modo que sus datos divergen. Capítulo 7
SQL (Structured Query Language): El lenguaje estándar para definir, consultar y modificar datos en bases de datos relacionales. Describes el resultado que quieres y la base de datos averigua cómo obtenerlo. Capítulo 0
SQL distribuido (NewSQL): Bases de datos relacionales, como Spanner y CockroachDB, que conservan SQL y las transacciones ACID mientras particionan y replican los datos en muchos nodos o regiones. Capítulo 7
Staff engineer: Rol sénior de contribuidor individual, por encima de ingeniero sénior, que ejerce liderazgo técnico entre equipos sin dirigir personas; principal engineer suele ser el siguiente nivel. Capítulo 1
Staff-plus engineer: Contribuidor individual sénior (staff, principal o distinguished engineer) que ejerce liderazgo técnico entre equipos sin dirigir personas; término popularizado por Will Larson. Capítulo 11
Strangler fig (higuera estranguladora): Enfoque de modernización incremental, bautizado por Martin Fowler, en el que componentes nuevos asumen gradualmente el comportamiento de un sistema heredado detrás de una capa de interceptación hasta que el sistema antiguo puede apagarse. Capítulo 11
STRIDE: Acrónimo mnemotécnico de seis tipos de amenaza (suplantación de identidad o spoofing, manipulación o tampering, repudio, divulgación de información, denegación de servicio y elevación de privilegios), creado en Microsoft por Loren Kohnfelder y Praerit Garg en 1999. Capítulo 8
Structurizr: Las herramientas de Simon Brown para el modelo C4, en las que un modelo basado en texto genera muchos diagramas coherentes. Capítulo 4
Subcaracterística: Cualidad más específica dentro de una característica de un modelo de calidad; por ejemplo, la tolerancia a fallos y la capacidad de recuperación son subcaracterísticas de la fiabilidad en ISO/IEC 25010. Capítulo 2
Subdominio: Área diferenciada de la actividad de un negocio, como los menús, los pedidos, los pagos o el despacho. Los subdominios pertenecen al problema, exista o no software. Capítulo 5
Subdominio de soporte: Subdominio específico del negocio y necesario para él, pero que no es donde compite; merece un diseño sólido pero más sencillo. Capítulo 5
Subdominio genérico: Un subdominio cuyos problemas comparten muchas empresas y para el que existen buenas soluciones, como los pagos o la identidad; normalmente se compra o se construye de forma mínima. Capítulo 5
Subtipado conductual: La regla que hay detrás de la sustitución de Liskov: un subtipo no puede exigir más a quienes lo llaman (precondiciones más fuertes), prometer menos (postcondiciones más débiles) ni romper las invariantes del supertipo. Capítulo 3
Sumidero de arquitectura (architecture sinkhole): Un antipatrón de los sistemas en capas en el que las solicitudes atraviesan capas que solo las reenvían, lo que añade código y retraso sin añadir comportamiento. Capítulo 5
Superficie de ataque: La suma de los puntos por los que un atacante puede intentar introducir datos en un sistema, extraerlos o interactuar con él de otro modo: endpoints, puertos, archivos, colas, herramientas de administración y las personas y el código en los que confía. Capítulo 8
Supervisión humana: Mecanismos que permiten a las personas supervisar, aprobar, anular o detener las decisiones de un sistema de IA. Capítulo 12

T

Tabla de dimensiones: Una tabla de atributos descriptivos, como el nombre, el tipo de cocina y la ciudad de un restaurante, que se usa para filtrar y agrupar hechos. Capítulo 7
Tabla de hechos: La tabla central de un esquema en estrella, que contiene una fila por cada evento de negocio con una granularidad (grain) establecida, con medidas numéricas y claves hacia las dimensiones. Capítulo 7
Táctica: Decisión de diseño que influye en cómo responde un sistema a un estímulo de calidad, como usar caché para reducir la latencia o redundancia para sobrevivir a una caída. Las tácticas son los bloques de construcción de los patrones. Capítulo 2
TARA: Tiny Architectural Review Approach, el método ligero de Eoin Woods para revisar un sistema existente combinando el juicio experto con el análisis automatizado de su código y de sus datos de ejecución. Capítulo 11
Tasa de aciertos de caché: La fracción de consultas que la caché puede responder con su propio contenido; el resto son fallos de caché (misses) que van a la fuente más lenta. Capítulo 7
Tasa de consumo (burn rate): La rapidez con la que se gasta un presupuesto de errores en relación con el ritmo que lo agotaría exactamente al final de la ventana; una tasa de consumo de 1 lo gasta por completo en exactamente una ventana. Capítulo 9
Tasa de descuento: La tasa anual que se usa para convertir el dinero futuro a su valor actual, que refleja el costo del capital y el riesgo; normalmente la fija el departamento de finanzas. Capítulo 11
TCP: Transmission Control Protocol: entrega un flujo de datos fiable y ordenado entre dos programas, reenviando los paquetes perdidos. Tradicionalmente lo ha usado la mayor parte del tráfico web. Capítulo 0
Team Topologies: Enfoque para organizar los equipos de software con vistas a un flujo rápido, expuesto por Matthew Skelton y Manuel Pais en el libro del mismo nombre (2019; segunda edición 2025): cuatro tipos de equipo, tres modos de interacción y la carga cognitiva del equipo como principal restricción. Capítulo 11
Telemetría: Los datos que emite un sistema en ejecución sobre su propio comportamiento: logs, métricas, trazas, perfiles y eventos. Capítulo 9
Tema de riesgo: Grupo de riesgos relacionados que comparten una causa subyacente, vinculado a los impulsores de negocio a los que amenaza. Los temas de riesgo suelen ser el resultado más útil de una evaluación para los directivos. Capítulo 11
Temperatura: Ajuste de muestreo que agudiza (por debajo de 1) o aplana (por encima de 1) las probabilidades del siguiente token del modelo, lo que hace la salida más repetible o más variada. Capítulo 12
Teorema CAP: El resultado, conjeturado por Eric Brewer en 2000 y demostrado por Gilbert y Lynch en 2002, según el cual, durante una partición de red, un sistema replicado no puede ser a la vez linealizable y estar disponible para todas las solicitudes. Capítulo 6
Tiempo de respuesta: El tiempo total entre que un cliente envía una solicitud y recibe la respuesta: el tiempo de servicio más cualquier tiempo de espera en colas, más los retardos de red. Capítulo 2
Tiempo de servicio: El tiempo que un recurso dedica realmente a trabajar en una solicitud, sin contar el tiempo que la solicitud pasa esperando a ese recurso. Capítulo 2
Tiempo de vida (TTL): Cuánto tiempo puede usarse un elemento en caché antes de considerarse obsoleto y tener que actualizarse o revalidarse. Capítulo 7
Tiempo del evento: El momento en que un evento ocurrió realmente, a diferencia del tiempo de procesamiento, cuando un sistema lo observa. Capítulo 7
Tiempo hasta el primer token (TTFT): El retardo entre el envío de una solicitud a un modelo y la recepción del primer token de su respuesta. Capítulo 12
Tiempo medio de reparación (MTTR): El tiempo medio desde un fallo hasta que se restablece el servicio. Algunas organizaciones interpretan la R como recuperación (recover) o restablecimiento (restore); indica siempre qué puntos de inicio y fin se miden. Capítulo 2
Tiempo medio entre fallos (MTBF): El tiempo medio que transcurre entre un fallo de un componente o sistema reparable y el siguiente. Capítulo 2
Tiempo medio hasta el fallo (MTTF): El tiempo medio que un componente funciona correctamente antes de fallar. Capítulo 2
Timeout: El tiempo máximo que quien llama esperará a una operación antes de rendirse y tratarla como fallida; toda llamada remota necesita uno. Capítulo 9
Tipo de datos: El tipo de valor que es un dato, como un número entero, un número decimal, texto o verdadero/falso, que determina qué operaciones tienen sentido sobre él. Capítulo 0
Tipo de modelo (model kind): En ISO/IEC/IEEE 42010, las convenciones para un tipo de modelo, como un diagrama de secuencia UML o un diagrama de contenedores C4. Capítulo 4
TLS mutuo (mTLS): TLS en el que ambas partes presentan y verifican certificados, de modo que un servicio sabe qué servicio lo está llamando, además de que quien llama conoce al servidor. Capítulo 8
TLS y HTTPS: Transport Layer Security cifra los datos entre dos programas y, mediante certificados, demuestra la identidad del servidor. HTTPS es HTTP transportado sobre TLS. Capítulo 0
TOGAF: The Open Group Architecture Framework, un marco y método muy utilizado para la arquitectura empresarial, publicado por The Open Group; su versión actual es el TOGAF Standard, 10th Edition (2022). Capítulo 1
Token: La unidad de texto que un modelo de lenguaje lee y escribe: una palabra o un fragmento de palabra de un vocabulario fijo. Los límites, los precios y la velocidad se cuentan en tokens. Capítulo 12
Token bucket (cubeta de tokens): Algoritmo de limitación de tasa en el que se añaden tokens a una cubeta a un ritmo fijo hasta una capacidad máxima, y cada solicitud gasta un token; permite ráfagas de hasta esa capacidad y una tasa media constante. Capítulo 9
Token de acceso: Una credencial de corta duración, emitida después de que un usuario o una aplicación inicia sesión, que se envía con cada solicitud a la API para demostrar lo que el llamante puede hacer. Capítulo 0
Tokenización: Sustituir un valor sensible, como un número de tarjeta, por un token sin significado, mientras el valor real se guarda en una bóveda separada y muy protegida, a menudo gestionada por un proveedor de pagos. Capítulo 8
Tolerancia a fallos: La capacidad de un sistema de seguir prestando su servicio aunque una de sus partes haya fallado, normalmente mediante redundancia. Capítulo 2
Toma de decisiones por consentimiento: Una regla de decisión en la que se adopta una propuesta salvo que alguien plantee una objeción razonada de que causaría daño o haría retroceder al grupo; pregunta si las personas pueden convivir con una propuesta, no si la prefieren. Capítulo 11
Topología de intermediario (broker): Una topología dirigida por eventos sin coordinador central: los procesadores reaccionan a los eventos y publican nuevos eventos, de modo que el flujo de trabajo surge de sus reacciones. Capítulo 6
Topología de mediador: Topología dirigida por eventos en la que un mediador recibe un evento inicial y dirige el flujo de trabajo enviando comandos a los procesadores en un orden definido. Capítulo 6
Tormenta de reintentos: Aumento brusco de carga que se produce cuando muchos clientes, a menudo en varias capas, reintentan a la vez solicitudes fallidas, lo que mantiene sobrecargado un servicio que ya lo está. Capítulo 9
Tráfico sombra (shadow traffic, dark launch): Copiar solicitudes reales a una versión nueva cuyas respuestas se comparan o se descartan pero nunca se devuelven a los usuarios, para probarla con carga real sin afectar a los usuarios. Capítulo 10
Transacción: Grupo de operaciones de base de datos tratadas como una unidad: o todas surten efecto (commit) o no lo hace ninguna (rollback). Capítulo 0
Transacción compensatoria: Una nueva transacción que contrarresta semánticamente el efecto de otra anterior ya confirmada, como anular una autorización de tarjeta. A diferencia de un rollback, puede que la original ya se haya visto. Capítulo 6
Transferencia de estado transportada por eventos: Eventos que transportan datos suficientes para que los receptores mantengan su propia copia, de modo que no necesitan llamar al publicador. Capítulo 6
Transformer: El diseño de red neuronal presentado por Vaswani y colaboradores en 2017, basado en la autoatención, que subyace a los modelos de lenguaje grandes actuales y a la mayoría de los modelos de embeddings. Capítulo 12
Trazado distribuido: Registrar el recorrido y los tiempos de una solicitud a medida que atraviesa muchos servicios, para poder encontrar el paso lento o que falla. Capítulo 9
Tríada CIA: Los tres objetivos clásicos de la seguridad de la información: confidencialidad (solo las partes autorizadas pueden leer), integridad (sin cambios no autorizados) y disponibilidad (utilizable cuando se necesita). Capítulo 2
Tríada letal (lethal trifecta): Nombre que Simon Willison dio (2025) a la peligrosa combinación de acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse con el exterior. Capítulo 12
Tubería (pipe): Canal unidireccional que transporta datos de un filtro al siguiente, normalmente con un búfer entre ellos. Capítulo 5
Tuberías y filtros: Estilo en el que los datos fluyen por una cadena de pasos de procesamiento independientes (filtros) conectados por canales unidireccionales (tuberías). Capítulo 5

U

UDP: User Datagram Protocol: envía paquetes individuales sin garantía de entrega ni de orden. Es más rápido y sencillo que TCP; se usa en videollamadas, juegos y DNS. Capítulo 0
Último momento responsable: El punto en el que retrasar más una decisión eliminaría una opción importante; decidir entonces aprovecha la mayor cantidad de información sin causar daño. Capítulo 1
Unidad de despliegue: Lo que se compila, se lanza y se inicia como una sola pieza: por ejemplo, un ejecutable, una imagen de contenedor o un archivo web. Capítulo 5
Upcasting: Convertir un evento almacenado con una versión antigua del esquema a la versión actual en el momento de leerlo, para que el código de la aplicación solo tenga que manejar una forma. Capítulo 7
Usuario virtual: Usuario simulado en una herramienta de pruebas de carga que ejecuta un script de solicitudes, normalmente en bucle. Capítulo 9
UTF-8: La forma dominante de codificar texto como bytes. Puede representar cualquier carácter Unicode, usando un byte para las letras básicas del inglés y hasta cuatro bytes para los demás. Capítulo 0
Utilización: La fracción de tiempo que un recurso está ocupado, que suele escribirse ρ (rho). Un servidor que atiende 40 solicitudes por segundo, cada una de las cuales necesita 20 ms de trabajo, tiene una utilización del 80%. Capítulo 2

V

Valor actual neto (NPV): La suma de los flujos de caja futuros de una inversión, cada uno descontado a su valor actual, menos el costo inicial; un NPV positivo significa que la inversión rinde más que la tasa de descuento. Capítulo 11
Valor mágico: Número o cadena literal cuyo significado no se indica en el código, como un estado 3 que significa 'enviado'. Crea connascence de significado entre todo lo que lo usa. Capítulo 3
Ventana de contexto: El número máximo de tokens que un modelo puede tener en cuenta en una llamada, incluidas las instrucciones, el historial, los documentos aportados y su propia respuesta. Capítulo 12
Ventana móvil: Periodo de medición que avanza de forma continua, como los últimos 28 días, a diferencia de un mes natural que se reinicia el día uno. Capítulo 9
Versionado de API: Publicar los cambios de una API bajo un nuevo identificador de versión, como /v2/, manteniendo la versión anterior en funcionamiento durante un tiempo para que los clientes puedan migrar a su ritmo. Capítulo 0
Versionado semántico: Convención de numeración de versiones, MAJOR.MINOR.PATCH, en la que el número mayor cambia con los cambios incompatibles, el menor con las adiciones compatibles con versiones anteriores y el de parche con las correcciones. Capítulo 5
Vías de comunicación: Los posibles vínculos uno a uno entre los miembros de un grupo. Un grupo de n personas tiene n(n-1)/2, por lo que el número crece aproximadamente con el cuadrado del tamaño del grupo. Capítulo 3
Violación de datos personales: Según el artículo 4(12) del RGPD (GDPR), una violación de la seguridad que ocasiona la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o el acceso no autorizados a ellos. Capítulo 8
Vista: Representación de una o más estructuras de un sistema, dirigida a inquietudes concretas de partes interesadas concretas, como un diagrama de despliegue para el personal de operaciones. Capítulo 1
Vista de asignación: Una vista que relaciona el software con elementos externos a él: la infraestructura (despliegue), los archivos y las compilaciones (implementación) o los equipos (asignación de trabajo). Capítulo 4
Vista de componentes y conectores: Una vista de lo que existe en tiempo de ejecución, como servicios, clientes, bases de datos y colas, y de los conectores (llamadas, mensajes, datos compartidos) entre ellos. Capítulo 4
Vista de módulos: Vista de las unidades de implementación (paquetes, bibliotecas, capas) y sus dependencias, tal como existen en tiempo de desarrollo. Capítulo 4

W

Warm standby (espera semiactiva): Estrategia de recuperación ante desastres que mantiene en funcionamiento, en una segunda región, una copia reducida pero plenamente operativa del sistema, lista para recibir tráfico y escalar. Capítulo 10
WCAG: Las Pautas de Accesibilidad para el Contenido Web (Web Content Accessibility Guidelines) del W3C. La versión 2.2 (2023) fija criterios de conformidad comprobables en los niveles A, AA y AAA; el nivel AA es la referencia legal habitual. Capítulo 2
Webhook: Solicitud HTTP que un proveedor envía a una URL registrada por su cliente cuando ocurre un evento, como un pago que se completa con éxito. Invierte la dirección habitual de una llamada a una API. Capítulo 0
Write skew (sesgo de escritura): Anomalía en la que dos transacciones leen datos que se solapan, cada una decide que un cambio es seguro y actualizan filas distintas, de modo que juntas incumplen una regla que cada una había comprobado. Capítulo 7

X

X como servicio (X-as-a-Service): Modo de interacción en el que un equipo consume algo que proporciona otro equipo, a través de una interfaz clara y documentada y con poca colaboración en el día a día. Capítulo 11
XA: La interfaz estándar de X/Open (1991) entre un gestor de transacciones y gestores de recursos como bases de datos e intermediarios de mensajes, usada para ejecutar una confirmación en dos fases entre ellos. Capítulo 6

Y

YAGNI: You aren't gonna need it (no lo vas a necesitar): una práctica de Extreme Programming que consiste en no construir capacidades para necesidades solo supuestas, porque cuestan esfuerzo ahora y complejidad después. Capítulo 3

Z

Zero trust (confianza cero): Modelo de seguridad que no concede ninguna confianza implícita basada en la ubicación en la red: cada solicitud se autentica, se autoriza y se cifra, por recurso y por sesión (NIST SP 800-207). Capítulo 8
Zona de disponibilidad: Uno de varios grupos de centros de datos físicamente separados dentro de una región de la nube, cada uno con alimentación eléctrica, refrigeración y red independientes, lo bastante cerca entre sí para tener conexiones rápidas. Capítulo 0