Arquitectura de Software • Edición Semanal #1

System Design: 50 Conceptos Clave de Arquitectura Explicados con Rigor

De la gestión de tráfico a la persistencia distribuida y la infraestructura de IA moderna. Sin rodeos ni abstracciones vacías.

Diagrama de arquitectura global de System Design: Client, Edge, Compute, Storage y AI
Ciclo completo de una petición: Client → Edge Network → Compute → Storage → Async Messaging & AI Infrastructure. ARQUITECTURA: LA PIZARRA TECH

En el día a día de la ingeniería de software existe una fricción silenciosa: durante entrevistas técnicas o sesiones de Architecture Review (revisiones de arquitectura del sistema), surgen con naturalidad términos como Idempotency (idempotencia), Backpressure (contrapresión de datos) o Consistent Hashing (dispersión consistente). Con frecuencia se asiente reconociendo el término, confiando en que el diálogo avance sin tener que detallar su funcionamiento interno en una pizarra.

El motivo no es la falta de destreza técnica, sino que estos conceptos suelen presentarse de forma abstracta, aislados del contexto operativo donde cobran sentido.

El objetivo de esta guía es recorrer los 50 pilares del System Design (diseño de sistemas escalables), analizando para cada uno: qué función cumple, qué problemática de producción resuelve y cuál es su trade-off técnico (el balance o compromiso entre beneficios y costes).

MÓDULO I

La Puerta de Entrada y Enrutamiento de Tráfico (Traffic Routing)

Describe cómo una solicitud viaja desde el dispositivo del usuario final hasta el perímetro de nuestra infraestructura.

01

Latency (Latencia)

Es el tiempo transcurrido (la demora o retraso) entre la emisión de una solicitud por el cliente y la recepción de su respuesta. Representa la velocidad percibida por el usuario y se compone de la suma del tránsito de red, el cómputo en el servidor y las consultas a base de datos. Reducir la latencia (Latency) implica auditar cuál de estos tramos concentra el cuello de botella.

Diagrama de arquitectura: Latency
02

Throughput (Caudal de Procesamiento)

Indica el volumen de trabajo o caudal que el sistema es capaz de despachar en una ventana temporal concreta (habitualmente medido en Requests Per Second o RPS, es decir, peticiones por segundo). Mientras que la latencia mide la velocidad de una operación individual, el Throughput mide la capacidad global de procesamiento concurrente. Diseñar para optimizar una métrica a menudo penaliza la otra.

Diagrama de arquitectura: Throughput
03

DNS (Domain Name System • Sistema de Nombres de Dominio)

Actúa como el directorio telefónico de Internet, traduciendo nombres de dominio alfanuméricos legibles por humanos a direcciones IP numéricas enrutables por máquinas. A nivel de arquitectura, permite balancear y desviar tráfico según la proximidad geográfica del usuario (Geo-routing o enrutamiento geográfico) o la disponibilidad del centro de datos, condicionado siempre por los tiempos de expiración del registro en caché (TTL o Time to Live).

Diagrama de arquitectura: DNS
04

CDN (Content Delivery Network • Red de Entrega de Contenido)

Red perimetral de servidores distribuidos geográficamente por todo el planeta (Edge servers o servidores en el borde) que conservan réplicas de datos estáticos (imágenes, scripts, ficheros CSS, vídeo) para servirlos desde el punto físico más cercano al cliente. Reduce drásticamente la latencia y alivia la carga de los servidores de origen. Exige estrategias rigurosas de Cache Invalidation (invalidación o purga de datos obsoletos en caché).

Diagrama de arquitectura: CDN
05

Reverse Proxy (Proxy Inverso)

Servidor intermediario que se sitúa frente a los servidores internos y atiende las solicitudes de los clientes en su nombre. Centraliza tareas clave como la terminación SSL/TLS (descifrado centralizado del tráfico seguro HTTPS), la compresión de respuestas y el blindaje de la topología interna, de modo que ningún usuario externo contacte directamente con las máquinas de aplicación privadas.

Diagrama de arquitectura: Reverse Proxy
06

Load Balancer (Balanceador de Carga)

Componente de infraestructura que reparte el tráfico entrante de forma inteligente entre múltiples servidores backend para evitar saturaciones individuales. Emplea algoritmos de distribución como Round Robin (reparto cíclico equitativo por turnos) o Least Connections (asignación al nodo con menos conexiones activas), y realiza comprobaciones periódicas de estado (Health Checks o sondeos de salud) para desviar automáticamente el tráfico de nodos degradados o caídos.

Diagrama de arquitectura: Load Balancer
07

API Gateway (Pasarela de Enlace de APIs)

Punto único de entrada perimetral para arquitecturas basadas en microservicios. Centraliza responsabilidades transversales que de otro modo tendrían que duplicarse en cada servicio: autenticación, autorización mediante tokens, Rate Limiting (control de tasa de peticiones), auditoría y enrutamiento contextual. Introduce un componente crítico que debe desplegarse en alta disponibilidad para evitar convertirse en un Single Point of Failure (SPOF, o punto único de fallo que derribaría todo el sistema si colapsa).

Diagrama de arquitectura: API Gateway
Diagrama de flujo de Traffic Routing: DNS, CDN, API Gateway, Load Balancer y Backends
Flujo de tráfico perimetral: Client → DNS Lookup → CDN Edge Hit/Miss → API Gateway → Load Balancer → Backend Servers. DIAGRAMA • MÓDULO I
MÓDULO II

Cómputo, Capacidad y Escalabilidad

Analiza cómo dotar de capacidad de proceso a la capa de cómputo para absorber incrementos de demanda sostenidos o imprevistos.

08

Scalability (Escalabilidad)

La cualidad que permite a una arquitectura absorber un volumen creciente de trabajo (más usuarios concurrentes, mayor volumen de datos o más solicitudes) sin degradar su rendimiento. Es una propiedad holística del sistema: la capacidad final viene dictada por el componente más restrictivo de la cadena (el principio del eslabón más débil o cuello de botella).

Diagrama de arquitectura: Scalability
09

Vertical Scaling (Escalado Vertical o Scale-Up)

Incremento de la potencia de una única máquina mediante la adición de más CPU, mayor memoria RAM o discos de mayor velocidad de entrada/salida (I/O). Resulta conceptualmente simple porque no exige rediseñar la aplicación ni lidiar con redes distribuidas complejas, pero choca con un límite físico de hardware y mantiene un Single Point of Failure (SPOF): si esa única máquina falla, se detiene todo el servicio.

Diagrama de arquitectura: Vertical Scaling
10

Horizontal Scaling (Escalado Horizontal o Scale-Out)

Aumento de la capacidad del sistema mediante el despliegue de múltiples servidores que operan en paralelo y cooperan entre sí. Permite un crecimiento virtualmente ilimitado y aporta tolerancia a fallos parciales, pero exige que los servidores de cómputo sean estrictamente Stateless (sin estado en memoria: ningún nodo almacena sesiones de usuario localmente, delegando el estado en una caché o base de datos compartida).

Diagrama de arquitectura: Horizontal Scaling
Comparativa de arquitectura: Vertical Scaling frente a Horizontal Scaling
Comparativa arquitectónica: Scale-Up (límite físico y SPOF) vs. Scale-Out (clúster homogéneo balanceado y tolerante a fallos). DIAGRAMA • MÓDULO II
MÓDULO III

Persistencia, Modelado y Estrategias de Caching (Caché)

Aborda cómo estructurar el almacenamiento de la información garantizando velocidad de lectura, consistencia y durabilidad transaccional.

11

Database (Base de Datos)

Subsistema dedicado al almacenamiento, organización y consulta estructurada de datos de manera persistente (duradera en disco), sobreviviendo al ciclo de ejecución y reinicios de los procesos de cómputo. Su elección inicial condiciona la evolución técnica y la velocidad de entrega global de una plataforma.

Diagrama de arquitectura: Database
12

SQL Database (Base de Datos Relacional)

Sistemas que estructuran la información en tablas compuestas de filas y columnas, vinculadas entre sí mediante Foreign Keys (claves foráneas). Aseguran el cumplimiento estricto de garantías ACID (transacciones seguras). Son óptimas para datos estructurados con requerimientos de integridad financiera o contractual, aunque su escalabilidad horizontal de escritura mediante Sharding (particionado) añade notable complejidad operativa.

Diagrama de arquitectura: SQL Database
13

NoSQL Database (Base de Datos No Relacional)

Categoría que agrupa almacenes documentales, Key-Value stores (almacenes clave-valor), Wide-Column stores (columnas anchas) o bases de datos de grafos. Sacrifican la rigidez del esquema relacional y las operaciones JOIN (cruce entre tablas) a cambio de una mayor facilidad de particionamiento horizontal y una velocidad extrema en patrones de acceso específicos.

Diagrama de arquitectura: NoSQL Database
14

ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad)

Conjunto de garantías transaccionales para operaciones donde cualquier fallo parcial resulta inaceptable:
• Atomicity (Atomicidad): Ocurre la transacción íntegra o no se consolida ningún cambio (filosofía All-or-nothing: todo o nada).
• Consistency (Consistencia): La base de datos pasa únicamente de un estado válido a otro, respetando esquemas, reglas y restricciones.
• Isolation (Aislamiento): Las transacciones concurrentes se ejecutan sin interferencias cruzadas entre sí.
• Durability (Durabilidad): Una vez ejecutado el Commit (confirmación), los datos sobreviven a fallos del servidor o cortes eléctricos.

Diagrama de arquitectura: ACID
15

Index (Índice de Base de Datos)

Estructura de datos secundaria (habitualmente árboles B+ o tablas hash) que el motor de base de datos mantiene para acelerar consultas selectivas, evitando el costoso Full Table Scan (escaneo secuencial registro por registro de toda la tabla). El trade-off (compromiso) fundamental es que aceleran las lecturas a costa de penalizar las escrituras (INSERT, UPDATE, DELETE), ya que cada modificación exige actualizar todos los índices vinculados.

Diagrama de arquitectura: Index
16

Replication (Replicación de Datos)

Mantenimiento de copias idénticas de los datos en múltiples servidores físicos. En topologías Leader-Follower (líder y seguidores), el nodo primario centraliza las escrituras y replica los cambios a los nodos secundarios para descargar el volumen de lecturas. El desfase temporal en esta sincronización se denomina Replication Lag (latencia de replicación) y puede provocar que lecturas secundarias devuelvan datos transitoriamente desactualizados.

Diagrama de arquitectura: Replication
17

Sharding (Particionamiento Horizontal)

Técnica que divide un conjunto masivo de datos a través de múltiples instancias de bases de datos independientes. La Shard Key (clave de particionado) define a qué servidor físico va a parar cada registro. Una mala elección de clave genera Hotspots (puntos calientes: un nodo saturado al 100% mientras los demás están desocupados). Además, las consultas que abarcan múltiples fragmentos (Cross-shard queries) resultan muy costosas en red.

Diagrama de arquitectura: Sharding
18

Cache (Memoria Caché)

Capa intermedia de almacenamiento en memoria ultrarrápida (habitualmente memoria RAM) interpuesta antes del almacenamiento persistente en disco. Reduce drásticamente la carga de la base de datos a costa de tener que gestionar el riesgo de Staleness (servir datos obsoletos que han cambiado en la fuente original).

Diagrama de arquitectura: Cache
19

Cache-Aside (Lectura Bajo Demanda)

Estrategia en la que la aplicación consulta primero la memoria caché: ante un acierto (Cache Hit), lee el registro directamente; ante un fallo (Cache Miss), consulta la base de datos persistente, almacena el resultado en la caché para consultas futuras y lo retorna al cliente. Es el patrón estándar más adoptado por su simplicidad y porque resiste fallos si la caché se cae.

Diagrama de arquitectura: Cache-Aside
20

Write-Through (Escritura Simultánea en Caché y Disco)

Patrón de caching donde toda modificación de datos se escribe de forma síncrona y simultánea tanto en la memoria caché como en la base de datos antes de confirmar el éxito de la operación al cliente. Asegura consistencia inmediata para lecturas posteriores, con la penalización de una mayor latencia en cada operación de escritura.

Diagrama de arquitectura: Write-Through
21

Write-Behind / Write-Back (Escritura en Caché con Volcado Asíncrono)

La mutación se consolida de inmediato en la memoria caché rápida y se delega la persistencia en disco a un proceso asíncrono en segundo plano. Aporta una velocidad de escritura extrema, pero asume el riesgo de pérdida irrecuperable de datos si la memoria colapsa o sufre un corte eléctrico antes del volcado a la base de datos.

Diagrama de arquitectura: Write-Behind
22

Consistent Hashing (Dispersión o Hashing Consistente)

Algoritmo de distribución de claves sobre un espacio matemático circular (Hash Ring o anillo hash) para clústeres distribuidos. Su gran ventaja es que al añadir o retirar servidores del clúster, únicamente se reubica una fracción mínima de las claves contiguas en lugar de reorganizar y mover el volumen completo de datos de todos los nodos.

Diagrama de arquitectura: Consistent Hashing
23

Consistent Hashing con Virtual Nodes (Nodos Virtuales)

Implementación avanzada donde cada máquina física se proyecta en múltiples puntos virtuales ficticios a lo largo del anillo de hashing. Evita concentraciones desbalanceadas de tráfico sobre un servidor concreto provocadas por la aleatoriedad de las funciones hash, garantizando una distribución de carga homogénea y equitativa.

Diagrama de arquitectura: Virtual Nodes
24

Object Storage (Almacenamiento de Objetos)

Arquitectura de almacenamiento plano diseñada para albergar volúmenes ilimitados de datos no estructurados (imágenes, vídeos, backups, ficheros binarios) identificados unívocamente mediante una clave o URL (como Amazon S3 o Cloudflare R2). Ofrece durabilidad extrema a bajo coste, pero carece de soporte para transacciones complejas o modificaciones atómicas parciales de un fichero.

Diagrama de arquitectura: Object Storage
25

Data Partitioning (Particionamiento de Datos)

Segmentación lógica o física de tablas extensas dentro de un mismo motor de persistencia (por ejemplo, separando registros por rangos de fecha mensuales). Permite aplicar Partition Pruning (poda de particiones: el motor examina únicamente los bloques de disco relevantes, ignorando el resto) y facilita el archivado masivo de históricos antiguos.

Diagrama de arquitectura: Data Partitioning
26

Event Sourcing (Persistencia Basada en Sucesos o Eventos)

Modelo arquitectónico en el que no se guarda el estado actual mutable de una entidad, sino la secuencia cronológica e inmutable de todos los sucesos de dominio que lo originaron. Permite una auditoría determinista total y reconstruir el estado en cualquier punto histórico del tiempo, aunque consultar el estado presente exige aplicar Snapshots (capturas periódicas del estado consolidado) para no reprocesar historiales masivos.

Diagrama de arquitectura: Event Sourcing
Diagrama de Persistencia, Cache-Aside y Sharding
Flujo de almacenamiento: Backend → Cache-Aside Check → DB Cluster con Leader-Follower Replication → Sharded Nodes. DIAGRAMA • MÓDULO III
MÓDULO IV

Coordinación y Consenso en Sistemas Distribuidos (Distributed Systems)

Explora las dinámicas y anomalías que surgen cuando varios servidores colaboran sin compartir memoria física y conectados por enlaces de red imperfectos.

27

Distributed System (Sistema Distribuido)

Conjunto de nodos de cómputo autónomos interconectados por una red física que colaboran para un fin común y se perciben como un único sistema. Su diseño asume que la red no es fiable, la latencia nunca es cero y cualquier componente puede fallar en cualquier momento (Partial Failure o fallo parcial de un subconjunto de máquinas).

Diagrama de arquitectura: Distributed System
28

CAP Theorem (Teorema CAP: Consistencia, Disponibilidad y Partición)

Principio formal que demuestra que un sistema de almacenamiento distribuido solo puede garantizar simultáneamente dos de tres propiedades: Consistency (Consistencia estricta), Availability (Disponibilidad) y Partition Tolerance (Tolerancia a particiones de red). Dado que las roturas o cortes de red (particiones) son físicamente inevitables en entornos reales, la decisión durante una partición es binaria: priorizar consistencia bloqueando operaciones (CP) o priorizar disponibilidad respondiendo con datos potencialmente obsoletos (AP).

Diagrama de arquitectura: CAP Theorem
29

Strong Consistency (Consistencia Fuerte o Inmediata)

Garantía por la cual cualquier lectura posterior a una escritura confirmada devuelve invariablemente el dato más reciente, sin importar qué nodo atienda la consulta. Exige bloqueos síncronos y coordinación distribuida en cada escritura, lo que eleva la latencia y compromete la disponibilidad si un enlace de red entre nodos se degrada.

Diagrama de arquitectura: Strong Consistency
30

Eventual Consistency (Consistencia Eventual)

Modelo relajado en el que las réplicas pueden discrepar transitoriamente tras una escritura, pero convergen de forma matemática al mismo estado tras un intervalo de propagación si cesan los cambios. Maximiza la disponibilidad y es óptimo para datos tolerantes a pequeños desfases (como contadores de visitas, reacciones o feeds sociales).

Diagrama de arquitectura: Eventual Consistency
31

Consensus (Consenso Distribuido)

Problema fundacional consistente en lograr que múltiples nodos independientes acuerden un valor o estado unívoco incluso ante la caída o retraso de parte de las máquinas. Algoritmos modernos como Raft o Paxos resuelven este dilema exigiendo validación por quórum (la aprobación de una mayoría absoluta estricta de nodos).

Diagrama de arquitectura: Consensus
32

Leader Election (Elección de Líder)

Proceso distribuido mediante el cual un clúster designa de forma automática una máquina responsable de secuenciar mutaciones o gobernar recursos exclusivos. Requiere mecanismos rigurosos de quórum para evitar situaciones de Split-Brain (cerebro dividido: anomalía donde un corte de red hace que dos máquinas se consideren líderes al mismo tiempo y acepten escrituras contradictorias).

Diagrama de arquitectura: Leader Election
33

Idempotency (Idempotencia)

Propiedad matemática según la cual la ejecución reiterada de una misma operación produce exactamente el mismo resultado y estado final que si se hubiese ejecutado una sola vez (como una petición HTTP GET o una asignación fija de estado). Es fundamental para que los reintentos automáticos tras fallos de red sean 100% seguros.

Diagrama de arquitectura: Idempotency
34

Idempotency Key (Clave de Idempotencia)

Identificador único generado por el cliente y transmitido en la cabecera de la solicitud (por ejemplo, Idempotency-Key: uuid-v4). El servidor guarda las respuestas de las claves ya procesadas: si recibe una solicitud duplicada provocada por un timeout (tiempo de espera agotado en la red), devuelve la respuesta previa sin volver a procesar el cargo financiero o la transacción.

Diagrama de arquitectura: Idempotency Key
35

Two-Phase Commit / 2PC (Compromiso en Dos Fases)

Protocolo síncrono para asegurar atomicidad transaccional a través de múltiples bases de datos mediante una fase de votación previa (Prepare Phase) y una de consolidación definitiva (Commit Phase). Su gran debilidad es que retiene bloqueos en todas las bases participantes; si el nodo coordinador cae en mitad del proceso, los sistemas quedan congelados indefinidamente.

Diagrama de arquitectura: Two-Phase Commit
36

Saga Pattern (Patrón Saga)

Alternativa asíncrona recomendada al 2PC para gestionar transacciones que abarcan múltiples microservicios independientes. Descompone la operación en una secuencia de transacciones locales atómicas encadenadas. Si un paso intermedio falla, el patrón ejecuta automáticamente Compensating Transactions (transacciones de compensación: acciones retroactivas que revierten o reembolsan los pasos previos de forma ordenada).

Diagrama de arquitectura: Saga Pattern
37

Clock Skew (Deriva o Desfase de Reloj)

Diferencia y deriva temporal acumulada entre los osciladores físicos de cuarzo de servidores independientes dentro de un clúster. Hace que sea imposible confiar en las marcas de tiempo físicas (Wall-clock time o la hora del sistema) para ordenar cronológicamente eventos concurrentes en entornos distribuidos.

Diagrama de arquitectura: Clock Skew
38

Vector Clock (Reloj Vectorial)

Mecanismo lógico basado en contadores matriciales mantenidos por cada servidor para rastrear relaciones de causalidad («qué ocurrió antes de qué») sin depender de relojes físicos de cuarzo, permitiendo detectar conflictos concurrentes en sistemas eventualmente consistentes.

Diagrama de arquitectura: Vector Clock
Diagrama de Saga Pattern con transacciones compensatorias
Orquestación de Saga Pattern: Paso 1 (Payment OK) → Paso 2 (Inventory falla) → Activación automática de Compensating Transaction (Reembolso). DIAGRAMA • MÓDULO IV
MÓDULO V

Asincronía, Streaming y Mensajería (Messaging)

Analiza los mecanismos que permiten a los componentes comunicarse sin acoplamientos rígidos y mantener canales de datos continuos.

39

Message Queue (Cola de Mensajería)

Componente de comunicación asíncrona punto a punto que almacena mensajes emitidos por un emisor (Producer o productor) hasta que el receptor (Consumer o consumidor) está listo para procesarlos. Desacopla temporalmente a ambos componentes, absorbiendo picos bruscos de tráfico y permitiendo escalados independientes.

Diagrama de arquitectura: Message Queue
40

Pub/Sub (Publish/Subscribe • Publicación y Suscripción)

Patrón de mensajería desacoplado donde los productores publican eventos sobre canales temáticos (Topics o tópicos). Múltiples consumidores independientes se suscriben a dicho canal para recibir copias simultáneas del mensaje (técnica de Fan-out o difusión múltiple), permitiendo que distintos servicios reaccionen al mismo hecho sin que el emisor conozca quién los escucha.

Diagrama de arquitectura: Pub/Sub
41

Dead-Letter Queue / DLQ (Cola de Mensajes Fallidos o Muertos)

Cola de contención especial donde se desvían de forma automática aquellos mensajes que superan el límite máximo de reintentos fallidos de procesamiento. Evita que un mensaje corrupto (Poison pill o píldora venenosa) colapse o bloquee indefinidamente el flujo de la cola de trabajo principal.

Diagrama de arquitectura: Dead-Letter Queue
42

Backpressure (Contrapresión o Control de Flujo)

Mecanismo de regulación donde un consumidor saturado notifica activamente al emisor para que disminuya su ritmo de transmisión de datos. Evita el desbordamiento de memorias intermedias (Buffers) y previene caídas catastróficas del sistema por agotamiento de memoria RAM (errores de tipo OutOfMemory).

Diagrama de arquitectura: Backpressure
43

WebSocket (Canal Bidireccional Persistente)

Protocolo de red que abre un canal continuo, bidireccional y Full-Duplex (comunicación simultánea en ambos sentidos) sobre una única conexión TCP. Permite el intercambio instantáneo de mensajes de latencia ultra baja entre cliente y servidor (chats en vivo, cotizaciones financieras en tiempo real o videojuegos multijugador). Requiere gestionar el estado de la conexión en memoria.

Diagrama de arquitectura: WebSocket
44

Server-Sent Events / SSE (Eventos Enviados desde el Servidor)

Estándar unidireccional sobre HTTP convencional donde el servidor envía un flujo continuo de datos en tiempo real hacia el navegador del cliente a través de una conexión abierta. Al ser unidireccional y contar con reconexión automática nativa, es mucho más sencillo y ligero de operar que los WebSockets para dashboards de métricas en directo o Streaming de respuestas token a token en modelos de inteligencia artificial (LLMs).

Diagrama de arquitectura: Server-Sent Events
Comparativa de arquitectura: WebSockets frente a Server-Sent Events SSE
Comparativa Streaming: WebSockets (Canal bidireccional continuo sobre TCP) vs. Server-Sent Events (Flujo unidireccional Server → Client sobre HTTP). DIAGRAMA • MÓDULO V
MÓDULO VI

Resiliencia Operativa e Infraestructura de Inteligencia Artificial (IA)

Cubre los patrones que protegen la estabilidad de los servicios bajo condiciones de estrés y los componentes fundacionales de la infraestructura moderna de Inteligencia Artificial.

45

Circuit Breaker (Disyuntor o Cortocircuito de Software)

Patrón de protección que monitoriza la tasa de fallos al invocar una dependencia o servicio externo. Opera en tres estados automáticos:
• Closed (Cerrado): Funcionamiento normal; las llamadas fluyen libremente.
• Open (Abierto): Si los fallos superan un umbral porcentual crítico, el circuito salta e interrumpe de inmediato las llamadas entrantes para no bloquear hilos de cómputo y conceder tiempo de recuperación al servicio degradado.
• Half-Open (Semiabierto): Tras un periodo de enfriamiento, deja pasar un contingente mínimo de peticiones de prueba para verificar si el servicio se ha recuperado antes de restablecer el tráfico total.

Diagrama de arquitectura: Circuit Breaker
46

Rate Limiting (Control de Tasa o Límite de Peticiones)

Mecanismo que limita el número de peticiones permitidas a un cliente, dirección IP o clave de API en un intervalo temporal definido. Se implementa habitualmente mediante algoritmos como Token Bucket (cubo de fichas) o ventanas de tiempo deslizantes, blindando a los servidores contra abusos, ataques DoS (denegación de servicio) y garantizando Fair Usage (reparto equitativo de recursos entre todos los usuarios).

Diagrama de arquitectura: Rate Limiting
47

Load Shedding (Descarte Selectivo de Carga)

Técnica defensiva por la cual un sistema al borde de la saturación crítica decide de forma proactiva rechazar peticiones no esenciales o de baja prioridad. Se sustenta en el principio de que una degradación parcial es preferible a un colapso absoluto: procesar con éxito el 80% del tráfico esencial es mejor que intentar atender el 100% y provocar una caída completa e inoperativa de la plataforma.

Diagrama de arquitectura: Load Shedding
48

Bloom Filter (Filtro de Bloom)

Estructura de datos probabilística ultracompacta en memoria utilizada para comprobar de forma instantánea si un elemento pertenece a un conjunto masivo de datos. Puede confirmar con certeza del 100% que un elemento no existe en el conjunto (ahorrando búsquedas lentas en disco), pero si indica que podría estar, existe un margen configurable y matemático de falsos positivos.

Diagrama de arquitectura: Bloom Filter
49

Embedding (Vector de Incrustación Semántica)

Representación matemática de información no estructurada (textos, imágenes o audio) convertida en un vector numérico de múltiples dimensiones continuas. La distancia geométrica entre dos vectores (medida habitualmente con Cosine Similarity o similitud de coseno) cuantifica con precisión su grado de afinidad o parecido semántico. Es la base técnica de los buscadores inteligentes y los sistemas de recomendación.

Diagrama de arquitectura: Embedding
50

RAG (Retrieval-Augmented Generation • Generación Aumentada por Recuperación)

Arquitectura de IA moderna que dota de memoria y contexto externo a un modelo de lenguaje (LLM o Large Language Model) antes de que elabore su respuesta:
• Ingestion & Retrieval (Ingesta y Búsqueda): La documentación interna se fragmenta en párrafos (Chunking), se transforma en Embeddings y se indexa en una Vector Database (base de datos vectorial). Ante la duda de un usuario, el sistema busca los fragmentos con mayor coincidencia de significado.
• Generation (Generación): Dichos fragmentos relevantes se añaden al prompt (instrucción inicial) del modelo, permitiéndole responder basándose en datos privados, verificables y actualizados al minuto, sin incurrir en el costoso proceso de reentrenar la IA.

Diagrama de arquitectura: RAG
Diagrama de arquitectura RAG y base de datos vectorial
Arquitectura RAG: Fase de Ingestión (Docs → Chunks → Vector DB) y Fase de Consulta en tiempo real con contexto inyectado al LLM. DIAGRAMA • MÓDULO VI

Síntesis Técnica

Dominar el System Design (diseño de sistemas) no consiste en memorizar definiciones, sino en evaluar con precisión los trade-offs (balance entre pros y contras) de cada decisión arquitectónica:

  • Traffic & Routing (Tráfico y Enrutamiento): Asumir que la latencia física de red siempre existe y que el sistema global solo escalará hasta donde su cuello de botella más estricto lo permita.
  • Data & Storage (Datos y Almacenamiento): Introducir Caching y Sharding resuelve el rendimiento de acceso, pero traslada la complejidad a la invalidación y a la consistencia de los datos.
  • Distributed Coordination (Coordinación Distribuida): En entornos distribuidos, la tolerancia a particiones de red (Partition Tolerance) es innegociable; la arquitectura debe determinar deliberadamente si prioriza la consistencia (Consistency) o la disponibilidad (Availability) según el impacto del negocio.
  • Resilience & AI (Resiliencia e IA): Los sistemas contemporáneos tratan los mecanismos de contención (Circuit Breakers, Rate Limiting) y las canalizaciones semánticas (Embeddings, bases de datos vectoriales, RAG) como componentes esenciales de primer orden en producción.
D

Daniel

Autor y editor en La Pizarra Tech. Diseñando y explicando cada semana los fundamentos de la arquitectura de software, sistemas distribuidos e infraestructura moderna con rigor y claridad.