Entrevista de diseño de sistemas: ¿Cómo diseñarías una red de entrega de contenido (CDN) global?

Problema y escenarios aplicables

Diseña una red de entrega de contenido (CDN) pull multi-tenant con 50 puntos de presencia (PoPs). En el pico, recibe 2 millones de solicitudes GET y HEAD por segundo, y la respuesta GET promedio almacenable en caché es de 256 KiB. Los orígenes de los clientes pueden aceptar de forma segura 20.000 búsquedas (fetches) por segundo en total. La CDN sirve activos con hash de contenido, imágenes, segmentos de video y documentos mutables en URLs estables.

El objetivo es un tiempo hasta el primer byte (TTFB) p99 inferior a 50 milisegundos para una respuesta en caché bajo condiciones normales, 99,99% de disponibilidad de solicitudes y la aplicación de cada purga en el 99% de los PoPs saludables en 60 segundos. La propagación completa y los PoPs rezagados deben permanecer observables. Estos valores son supuestos de entrevista, no afirmaciones sobre ningún proveedor en particular.

Este diseño se aplica cuando los usuarios están distribuidos geográficamente, la distancia al origen domina la latencia, los objetos repetidos se pueden reutilizar y el ancho de banda o cómputo del origen es limitado. Un servicio interno privado con una sola región y poca reutilización podría necesitar en su lugar un proxy inverso regional. El alcance de la entrevista construye los mecanismos centrales de la CDN; contratar una CDN administrada sigue siendo una opción de producción válida después de comparar los requisitos, el límite de seguridad, el costo operativo y el modelo de fallos del proveedor.

Qué está evaluando el entrevistador

La primera señal es si el candidato separa el plano de control del plano de datos. La incorporación de inquilinos, la configuración del origen, los certificados, las reglas de caché y los comandos de purga necesitan flujos de trabajo de gestión durables. El servicio de solicitudes debe continuar a partir de la última configuración válida conocida (last-known-good) cuando esa ruta de gestión no esté disponible.

La segunda señal es la corrección del límite de la caché. Una clave de caché que omite una dimensión de representación puede filtrar o corromper respuestas entre diferentes idiomas, codificaciones, dispositivos o inquilinos. Una clave que incluye cada cookie y encabezado fragmenta la caché hasta que casi todas las solicitudes resultan en un miss. La respuesta debe definir qué solicitudes son elegibles, qué dimensiones varían la representación y qué respuestas privadas eluden el almacenamiento compartido.

La tercera señal es la protección del origen. Con 50 PoPs, un solo objeto recién popularizado puede generar 50 rellenos fríos (cold fills) simultáneos incluso antes de los reintentos. La coalescencia de solicitudes en cada nivel, los escudos regionales (regional shields), la concurrencia limitada al origen y los presupuestos de reintentos resuelven diferentes partes de esa ruta. Ningún modo de fallo puede convertir silenciosamente 2 millones de solicitudes por segundo en el borde en tráfico directo al origen.

La cuarta señal es la corrección de la invalidación. Una purga que solo elimina los bytes actuales puede entrar en una condición de carrera con un relleno más antiguo y permitir que reaparezca contenido desactualizado. Las respuestas sólidas utilizan una generación ordenada o tombstone, hacen que la entrega sea idempotente y miden tanto el SLO de propagación común como la cola larga (long tail).

Finalmente, el candidato debe cuantificar el rendimiento, establecer contratos explícitos de consistencia y obsolescencia, cubrir los límites de fallo y seguridad, y proponer pruebas que demuestren el comportamiento visible para el usuario. Una lista de productos de proveedores no constituye esa prueba.

Preguntas de clarificación antes de responder

• ¿La CDN es dueña de los objetos de origen? No. Es una CDN pull; los orígenes de los clientes siguen siendo la fuente autoritativa.
• ¿Qué métodos se pueden almacenar en caché? Comenzar con GET y HEAD. Los métodos no seguros pasan directamente y este diseño base nunca los coloca en una caché compartida.
• ¿Qué contenido es privado? Las solicitudes con autorización o cookies específicas del usuario eluden la caché compartida a menos que el inquilino proporcione una política de particionamiento explícita y revisada.
• ¿Qué tan actualizado debe estar el contenido mutable? Cada ruta define un TTL y cualquier ventana de obsolescencia acotada. Una purga apunta a cambios urgentes; no es un sustituto de una verificación de autorización o revocación.
• ¿Cada parámetro de consulta es significativo? No. El inquilino incluye en una lista permitida (allowlist) los parámetros que cambian la representación y puede descartar parámetros de seguimiento conocidos tras la canonización.
• ¿Se requieren rangos de bytes (byte ranges)? Sí, para medios de gran tamaño. La clave y los metadatos deben distinguir los objetos completos de los rangos validados, y el origen debe proporcionar validadores estables o URLs versionadas.
• ¿Cómo se elige un PoP cercano? DNS y/o anycast enrutan al usuario a un PoP alcanzable. La selección de ruta BGP no garantiza proximidad geográfica, por lo que el estado de salud y la latencia medida siguen siendo necesarios.
• ¿Qué sucede cuando falla el plano de control? El tráfico existente continúa con una configuración firmada de última versión válida conocida; los cambios no seguros fallan de forma cerrada (fail closed) y se encolan para su posterior aplicación.
• ¿Se pueden servir datos obsoletos durante una interrupción del origen? Solo para rutas con una concesión explícita de stale-if-error y una edad máxima acotada.
• ¿Qué significa que una purga se haya completado? El objetivo de 60 segundos cubre el 99% de los PoPs saludables; el sistema registra por separado cada acuse de recibo, rezagado, reintento y resultado de sondeo.

Marco de respuesta en 30 segundos

“Divido los planos de control y de datos. DNS y anycast dirigen hacia un PoP saludable; el borde selecciona una configuración de inquilino firmada, canoniza una clave basada en listas permitidas y consulta la RAM y luego el SSD. Los misses se fusionan (coalescen) en el borde y en el escudo regional antes de una búsqueda presupuestada al origen; el servicio obsoleto sigue límites explícitos. Los activos inmutables utilizan URLs versionadas. Las URLs mutables usan una generación de purga ordenada y un tombstone, y los rellenos comparan las generaciones antes de la publicación para que los bytes antiguos no puedan reaparecer. Verifico las tasas de aciertos por solicitud y por bytes, la carga en el origen, el TTFB p99 de aciertos, la edad de obsolescencia, el retraso de purga y el comportamiento ante interrupciones”.

Análisis detallado paso a paso

Paso 1: Cuantificar el tráfico y el presupuesto del origen

Utilizando el tamaño promedio de GET como un límite de planificación para la mezcla de tráfico pico, el ancho de banda de respuesta antes de la sobrecarga de protocolo es:

2,000,000 requests/s × 256 KiB × 8 = 4.19 Tb/s

Si ese pico se mantuviera durante un día, representaría alrededor de 45,3 PB de bytes de respuesta en el borde. A través de 50 PoPs, el promedio simple es de 40.000 solicitudes/s y 10,5 GB/s por PoP, pero el tráfico real está sesgado geográfica y temporalmente. La planificación de capacidad utiliza por ende picos medidos por PoP, margen de maniobra (headroom), percentiles de tamaño de objeto y redistribución por fallos; el promedio es solo una línea base.

El límite del origen es el 1% del pico de solicitudes del borde:

20,000 / 2,000,000 = 1%

Eso no significa que el objetivo de tasa de aciertos del borde por sí solo deba ser del 99%. Los aciertos en el escudo, las rutas no almacenables en caché, los rellenos, la revalidación y los reintentos consumen el mismo presupuesto del origen. El programador (scheduler) orientado al origen necesita límites de concurrencia y de tasa de solicitudes por inquilino, por origen y globales.

Paso 2: Separar los planos de control y de datos

El plano de control almacena inquilinos, dominios, identidades de origen, certificados, políticas de caché, reglas de canonización, límites de obsolescencia, claves de URLs firmadas y versiones de configuración. Un cambio validado se registra de forma duradera, se compila en una instantánea firmada y se distribuye a través de un flujo versionado. Los PoPs confirman las versiones aplicadas. Las claves privadas de los certificados utilizan un límite dedicado de gestión de secretos y claves y se mantienen fuera del almacenamiento de configuración ordinario.

El plano de datos maneja TLS, búsqueda de inquilinos, aplicación de políticas, normalización de solicitudes, almacenamiento en caché, acceso al origen y registros. Nunca llama sincrónicamente a la base de datos del plano de control en un acierto de caché. Los PoPs retienen una instantánea firmada de la última versión válida conocida durante una interrupción del plano de control. Una configuración obsoleta tiene un tiempo de vida acotado; los certificados expirados, los inquilinos revocados y las políticas de seguridad ambiguas fallan de forma cerrada tras ese período.

Paso 3: Enrutar el tráfico y aislar a los inquilinos

El DNS puede devolver nombres regionales o direcciones anycast; una red anycast puede anunciar la misma dirección desde múltiples PoPs. El enrutamiento elige una ruta de red alcanzable y, a continuación, el estado de salud del servicio elimina un PoP defectuoso y lo desvía hacia otra ubicación. El diseño rastrea cambios de ruta, carga por failover y latencia porque la noción de “más cercano” es un resultado observado, no una garantía de BGP.

En el borde, SNI y el encabezado Host normalizado se asignan a un inquilino antes de cualquier búsqueda en caché. El ID de inquilino es un primer componente implícito de cada espacio de nombres de caché. Los orígenes aceptan únicamente tráfico autenticado de la CDN a través de mTLS, solicitudes firmadas, conectividad privada o un secreto rotativo, y no deben permanecer accesibles públicamente eludiendo la CDN. Las direcciones de origen y las redirecciones se colocan en listas permitidas para evitar SSRF.

Paso 4: Definir la elegibilidad de caché y la clave

La línea base admite respuestas exitosas de GET y HEAD solo cuando la política de ruta y los campos HTTP permiten la reutilización compartida. private, no-store, autorización, cookies específicas de usuario, Set-Cookie y valores no admitidos de Vary normalmente eluden el almacenamiento. Las respuestas negativas solo pueden almacenarse en caché durante un TTL corto y específico para el estado, de modo que un fallo transitorio no se convierta en una interrupción prolongada.

Una clave conceptual es:

tenant_id | canonical_scheme_host | normalized_path | selected_query |
encoding_variant | approved_vary_dimensions | object_generation

La canonización ocurre una vez antes de la política, la búsqueda, el registro, el relleno y la purga. Solo los parámetros de consulta y los encabezados que realmente cambian los bytes entran en la clave. Agregar Accept-Language es correcto cuando el origen varía según el idioma; agregar cookies arbitrarias o User-Agent puede disparar la cardinalidad. El valor de Vary de una respuesta debe coincidir con las dimensiones permitidas de la ruta, o la respuesta eludirá la caché.

La frescura sigue la política del inquilino y la semántica HTTP: las entradas frescas se devuelven directamente; las entradas obsoletas se revalidan con ETag o Last-Modified; stale-while-revalidate y stale-if-error se utilizan únicamente dentro de límites explícitos. no-cache significa revalidar antes de reutilizar, mientras que no-store significa no almacenar. La política de caché no debe debilitar una directiva de privacidad más estricta proveniente del origen.

Paso 5: Construir las rutas de relleno en RAM, SSD, escudo y origen

Cada PoP mantiene metadatos calientes y objetos pequeños en RAM y una caché SSD más grande controlada por admisión. La admisión y el desalojo consideran la tasa de solicitudes, el tamaño en bytes, la recencia y el costo de búsqueda para que un solo barrido de objetos fríos y grandes no desaloje el conjunto de trabajo útil. El origen sigue siendo autoritativo; perder una caché de borde es un evento de rendimiento, no una pérdida de datos.

En un miss, una tabla singleflight fusiona (coalesce) a los solicitantes para la clave exacta. Un solicitante consulta un escudo regional; los seguidores esperan durante un tiempo acotado o utilizan una entrada obsoleta permitida. El escudo repite la búsqueda y coalescencia a través de muchos PoPs. Solo su relleno elegido entra en el programador del origen. Este segundo límite de coalescencia evita que un objeto frío genere una búsqueda independiente al origen por cada PoP.

Cada relleno tiene un tiempo límite (deadline), tamaño máximo, validación de tipo de contenido, suma de verificación (checksum), presupuesto de bytes por inquilino y presupuesto de reintentos. Un reintento utiliza retroceso exponencial con jitter, pero sigue consumiendo el presupuesto del origen. El hedging se limita a lecturas idempotentes y no puede duplicar el trabajo del origen sin un límite estricto. Los objetos grandes se transmiten (stream) al cliente mientras se escribe una entrada de caché temporal; la entrada se vuelve visible solo después de que la longitud esperada, el validador y la suma de verificación estén completos.

Paso 6: Hacer seguras las condiciones de carrera entre purga y relleno

Los nombres de archivo direccionados por contenido son el valor predeterminado para activos inmutables: publicar nuevos bytes crea una nueva URL, y las URLs antiguas pueden expirar de forma natural. Las URLs mutables necesitan una API de purga explícita que admita un objeto exacto, un prefijo o etiqueta aprobada y una purga de emergencia con alcance de inquilino. Las purgas amplias tienen límites de tasa y requieren una autorización más estricta porque pueden crear una tormenta global de misses.

El coordinador de purgas confirma {tenant, selector, generation, issued_at} en un registro ordenado y duradero antes de enviar el acuse de recibo. Los PoPs aplican el evento de forma idempotente, avanzan la generación mínima del selector, eliminan los bytes coincidentes y retienen un tombstone el tiempo suficiente para cubrir rellenos antiguos y eventos retrasados. Reportan la generación aplicada. La distribución jerárquica (fan-out), los reintentos y los repetidores regionales evitan que un PoP lento bloquee la ruta común.

Antes de publicar un objeto rellenado, la caché compara la generación capturada al inicio de la búsqueda con la generación mínima actual. Si una purga avanzó durante la búsqueda, esos bytes se descartan o se vuelven a buscar bajo la nueva generación. Esta comparación evita que una respuesta antigua que llega después de una eliminación resucite contenido obsoleto. La misma regla se aplica en las capas de borde y de escudo.

La API reporta los estados aceptado, propagado al 99% y completado o expirado por separado. Las sondas sintéticas solicitan la clave purgada de las regiones y validan encabezados de versión o hashes de contenido. La revocación de seguridad sigue perteneciendo a una verificación autoritativa en línea o a un tiempo de vida de token delimitado por separado; un SLO de purga de caché de 60 segundos no es una revocación instantánea.

Paso 7: Manejar sobrecargas y fallos explícitamente

• Fallo de PoP: retirar o dejar de anunciar la ruta, drenar hacia PoPs saludables y reservar capacidad para el tráfico redistribuido.
• Pérdida de SSD: reconstruir gradualmente mediante control de admisión; no precalentar (warm) todos los objetos ni eludir el escudo.
• Fallo del escudo: elegir un escudo secundario; si se permite el respaldo directo al origen, mantener los mismos presupuestos de origen.
• Tiempo de espera o 5xx del origen: servir contenido obsoleto acotado solo donde la política lo permita; de lo contrario, devolver un error explícito y evitar la amplificación de reintentos.
• Interrupción del plano de control: continuar sirviendo a partir de la última configuración firmada válida conocida; encolar cambios seguros y rechazar mutaciones sensibles a la seguridad que no puedan verificarse.
• Retraso en el flujo de purga: reintentar de forma idempotente, exponer PoPs rezagados y eludir o revalidar la clave afectada cuando se conoce una generación crítica pero los bytes no son confiables.
• Aumento repentino de objetos calientes (hot-object surge): coalescer rellenos, replicar el objeto a través de procesos de caché, proteger un proceso individual de saturación de NIC o bloqueos (locks), y limitar la tasa de inquilinos abusivos.

Paso 8: Asegurar y verificar el sistema completo

Terminar TLS con certificados en el ámbito de cada inquilino y proteger la identidad del origen. Aplicar límites de tamaño de solicitud, conteo de encabezados, conteo de rangos y tamaño de respuesta. Normalizar rutas ambiguas y campos HTTP una sola vez para evitar el contrabando de solicitudes (request smuggling) y desacuerdos en la clave de caché. Particionar cuotas, claves, registros, derechos de purga y espacios de nombres de caché por inquilino. Las URLs o cookies firmadas se verifican antes de la búsqueda, y su política no debe convertir accidentalmente una respuesta privada en un objeto público.

Observar por separado las tasas de aciertos por solicitud y por bytes, el TTFB de acierto, la latencia de miss, la tasa de aciertos del escudo, el QPS y ancho de banda del origen, los seguidores coalescidos, la cardinalidad de la clave de caché, los bytes desalojados, la edad de obsolescencia, el retraso de purga por PoP, la versión de configuración, la tasa de errores y la carga por failover. Los registros graban un resumen (digest) de clave seguro para la privacidad, inquilino, PoP, tipo de resultado, edad, generación, nivel ascendente (upstream tier) e ID de seguimiento (trace ID).

La validación incluye un arranque en frío de un objeto caliente desde los 50 PoPs, una purga compitiendo contra un relleno intencionalmente lento, eventos de purga duplicados y fuera de orden, un Vary envenenado, elusión de autorización y cookies, rellenos de rangos parciales, un reinicio de SSD, pérdida de escudo, limitación (throttling) del origen, retirada de PoP y una interrupción del plano de control. Las verificaciones de aceptación incluyen un TTFB p99 en caché inferior a 50 milisegundos en condiciones normales, disponibilidad de solicitudes del 99,99%, búsquedas al origen iguales o inferiores a 20.000 por segundo, y 99% de PoPs saludables aplicando una purga dentro de 60 segundos sin resurrección de contenido obsoleto.

Respuesta de muestra de alta calidad

“Comenzaría con el límite de capacidad. Dos millones de solicitudes por segundo a 256 KiB representan aproximadamente 4,19 Tb/s de tráfico de respuesta pico. Los orígenes pueden aceptar solo el 1% del volumen de solicitudes del borde, por lo que la protección del origen es un invariante estricto, no una optimización opcional.

Separo un plano de control duradero del plano de datos de servicio. La configuración de inquilinos, certificados, identidades de origen, reglas de caché y purgas están versionados y auditados. Los PoPs sirven con la última configuración firmada válida conocida en lugar de consultar esa base de datos en cada solicitud. DNS y anycast enrutan a los usuarios a un PoP saludable; SNI y Host identifican al inquilino antes de una búsqueda en caché con espacio de nombres.

La clave contiene el inquilino, la URL canónica, únicamente las dimensiones de consulta y encabezado que cambian la representación, y una generación. Las respuestas privadas, autorizadas, con no-store y no seguras eluden la caché compartida. Un acierto proviene de RAM o SSD. Un miss se coalesce en el borde, se envía a un escudo regional, se vuelve a coalescer y se admite a través de presupuestos por origen y globales. Las rutas frescas, revalidadas y de obsolescencia acotada son distintas.

Los activos inmutables usan URLs versionadas. La purga de una URL mutable primero confirma una generación incremental en un registro duradero. Cada nivel mantiene la generación mínima permitida y un tombstone. Un relleno verifica esa generación antes de la publicación, de modo que los bytes buscados antes de una purga no puedan llegar después y restaurar contenido obsoleto. Expongo los estados de propagación al 99% y completado en lugar de ocultar los rezagados.

Demostraría el diseño con tasas de aciertos por solicitud y por bytes, QPS del origen, TTFB p99 de acierto, edad de obsolescencia, retraso de purga y versiones de configuración. Luego inyectaría un miss frío de objeto caliente, una carrera entre purga y relleno, fallos de PoP y de escudo, limitación del origen, eventos de purga fuera de orden, envenenamiento de clave de caché y una interrupción del plano de control, manteniendo los cuatro SLOs establecidos como criterios de aceptación”.

Errores comunes

• Afirmar que el PoP geográficamente más cercano está garantizado → BGP selecciona rutas de red, no distancia en línea recta → mide la latencia y la salud, y diseña la retirada de rutas y el failover.
• Incluir cada encabezado de solicitud en la clave → la cardinalidad se dispara y la mayor parte del tráfico resulta en un miss → incluye en la lista permitida solo las dimensiones que cambian la representación y rechaza valores no admitidos de Vary.
• Omitir la identidad del inquilino del espacio de nombres → URLs idénticas pueden cruzar límites de inquilinos → deriva el inquilino antes de la búsqueda y conviértelo en un prefijo de clave implícito.
• Eliminar bytes en una purga sin una generación → un relleno en tránsito más antiguo puede republicarlos → avanza un tombstone y compara generaciones antes de la inserción en caché.
• Agregar solo un bloqueo en el borde → 50 PoPs aún pueden emitir 50 rellenos hacia el origen → coalesce nuevamente en un escudo y retén presupuestos globales para el origen.
• Reintentar cada solicitud de origen fallida → los reintentos amplifican la interrupción → utiliza plazos límite, presupuestos acotados, jitter y comportamiento de obsolescencia o error específico de la ruta.
• Usar purga para la revocación instantánea de seguridad → la propagación tiene una cola medible → utiliza una verificación autoritativa o un tiempo de vida de credenciales acotado para decisiones de seguridad.
• Reportar solo la tasa de aciertos por solicitud → muchos aciertos pequeños pueden ocultar misses grandes y costosos → rastrea también la tasa de aciertos por bytes, el ancho de banda del origen, las distribuciones de tamaño y el costo de búsqueda.

Análisis de seguimiento

Pregunta de seguimiento 1: ¿Cómo admitirías objetos de video grandes y solicitudes de rango?

Prefiere URLs de segmentos inmutables y almacena en caché segmentos completos donde sea práctico. Valida Content-Range, la longitud del objeto, el validador y la generación antes de combinar rangos. Limita el conteo de rangos y la amplificación, y nunca permitas que dos representaciones compartan una clave de objeto parcial. Para objetos muy grandes, alinea los fragmentos (chunks) a una cuadrícula controlada para que las solicitudes superpuestas puedan reutilizar bytes sin crear fragmentos arbitrarios.

Pregunta de seguimiento 2: ¿Cómo evitarías un ataque de envenenamiento de clave de caché?

Canoniza la URL y los campos HTTP una sola vez, rechaza codificaciones ambiguas e incluye cada entrada aprobada que cambie los bytes del origen. No reenvíes un encabezado no incluido en la clave que el origen use para la selección de representación. Prueba encabezados conflictivos, campos duplicados, codificaciones de ruta, orden de parámetros de consulta y normalización de host en el borde y el origen para que ambos lados interpreten la solicitud de manera idéntica.

Pregunta de seguimiento 3: ¿Debería el HTML personalizado almacenarse en caché en el borde alguna vez?

Solo con un contrato explícito de producto y seguridad. Las opciones más seguras almacenan en caché un shell público y obtienen los datos privados por separado. Si se debe almacenar en caché el HTML completo, particiona por una identidad o cohorte verificada y acotada, evita la reutilización compartida, define el comportamiento al cerrar sesión y prueba el aislamiento entre usuarios. Una cookie de sesión arbitraria en una clave de caché pública es tanto riesgosa como destructiva para la tasa de aciertos.

Pregunta de seguimiento 4: ¿Cómo elegirías entre un único escudo global y escudos regionales?

Un solo escudo maximiza la consolidación de misses, pero puede agregar distancia y concentrar fallos. Los escudos regionales reducen la latencia y el radio de impacto, pero pueden buscar el mismo objeto en el origen varias veces. Elige según la ubicación del origen, la capacidad de almacenamiento en caché, la demanda regional, la latencia aceptable y el presupuesto del origen; luego prueba el failover del escudo y documenta dónde la topología seleccionada deja de ser adecuada.

Pregunta de seguimiento 5: ¿Cómo desplegarías una nueva política de claves de caché?

Compílala como una nueva versión de configuración, calcula en la sombra (shadow-compute) las claves antiguas y nuevas, y compara la cardinalidad, la tasa de aciertos, la clasificación de privacidad y la carga del origen sin servir tráfico desde la nueva clave. Despliega por inquilino y por PoP, mantén una versión de reversión (rollback) y precalienta solo los objetos calientes comprobados. Un cambio de clave crea un evento de caché fría, por lo que debe someterse a los mismos presupuestos de origen que los rellenos ordinarios.

Pregunta de seguimiento 6: ¿Se requiere multi-CDN para una disponibilidad del 99,99%?

No automáticamente. Un solo proveedor puede cumplir con el objetivo si el modelo de fallos medido, la redundancia de PoP, la retirada de rutas, el diseño del origen y las operaciones lo respaldan. Multi-CDN reduce algunos riesgos del proveedor, pero introduce consistencia de DNS o de direccionamiento, configuración duplicada, coordinación de purgas, normalización de registros, manejo de certificados y el problema de un escudo de origen común. Adóptalo solo después de probar que el plano de control agregado realmente mejora el objetivo de disponibilidad establecido.