8. Proyecto: diseña Enlace de punta a punta

Descripción

Llegó el final del recorrido de vuelta, y con él el entregable que corona la guía entera: el diseño completo de Enlace, de punta a punta. En este proyecto no se agrega ninguna herramienta; se juntan las siete de los módulos anteriores en un solo artefacto defendible, recorriendo el marco de 4 pasos de corrido. Es exactamente lo que produces —y defiendes— en una entrevista de system design o en una revisión de arquitectura real: un diseño con requisitos, tabla de capacidad ejecutada, diagrama, y una lista de tradeoffs justificados con números.

La lección tiene tres partes. Primero, el enunciado del proyecto —lo que tienes que producir, con tus manos, antes de mirar la solución—. Segundo, la rúbrica —los criterios con los que se evalúa un buen diseño, para que sepas qué distingue una propuesta sólida de una que solo parece completa—. Y tercero, dentro de un <details>, la solución de referencia completa: el diseño de Enlace hecho, con su diagrama mermaid, su tabla de capacidad corrida en Python, y su lista de tradeoffs, para que compares tu diseño con uno defendible. No es la respuesta correcta —otro hit ratio objetivo, otro número de shards, otra política de TTL también se defienden—, pero es una propuesta sólida con cada decisión atada a un número. Al final, la guía cierra: el resumen de los ocho módulos como un arco, y hacia dónde seguir en el ecosistema.

Conexión con el módulo: este es el capstone del capstone. Usa el paso 1 (lección 2), el paso 2 (lección 3), el paso 3 (lección 4) y el paso 4 (lecciones 5, 6, 7) —todo a la vez— para producir el artefacto final. Es también el cierre de la guía: al terminarlo, habrás recorrido el mapa completo que el módulo 1 abrió, y tendrás en la mano la habilidad que la guía promete —tomar un enunciado vago y producir un diseño distribuido defendible con números—.

El examen práctico del oficio

Piénsalo así. Un piloto no obtiene su licencia respondiendo preguntas de opción múltiple sobre aerodinámica. La obtiene en el examen práctico: sube a la cabina, con el examinador al lado, y vuela de verdad —despega, navega, maneja una emergencia simulada, aterriza—. El examinador no le pregunta "¿qué es la sustentación?"; observa si sabe volar, si recorre el checklist en orden, si toma decisiones correctas bajo presión, si sabe justificar por qué viró cuando viró. Todo lo que el piloto estudió por separado —meteorología, motores, navegación, procedimientos— se pone a prueba junto, en una sola sesión, produciendo un vuelo real.

Fíjate en qué evalúa el examinador. No busca la maniobra "perfecta" —no existe—; busca criterio: ¿el piloto tomó decisiones razonables para las condiciones que tenía?, ¿puede explicar cada una?, ¿siguió el método sin saltarse pasos?, ¿anticipó los problemas en vez de reaccionar tarde? Dos pilotos pueden volar la misma ruta de formas distintas y ambos aprobar, porque lo que se evalúa no es que coincidan con una respuesta única, sino que cada decisión esté justificada y el método se respete.

Este proyecto es tu examen práctico de system design. No te preguntamos "¿qué es una caché?"; te pedimos que diseñes Enlace entero —requisitos, estimación, diagrama, profundizar, tradeoffs— produciendo un diseño real. Y como el examinador del piloto, la rúbrica no busca que coincidas con la solución de referencia palabra por palabra; busca criterio: que cada caja tenga su número, que recorras el marco en orden, que sepas defender cada tradeoff, que anticipes el día malo. Un diseño distinto al de referencia puede ser igual de bueno, si cada decisión está justificada. Eso es lo que hace de esto un examen del oficio y no de la memoria.

Conviene decirlo con todas las letras:

El proyecto final evalúa criterio, no coincidencia. Un buen diseño de Enlace no es el que copia la solución de referencia; es el que recorre el marco de 4 pasos en orden, justifica cada componente con un número, defiende cada tradeoff con su "gano/pago", y anticipa el día en que las cosas fallan. Como el examen del piloto: no hay un vuelo perfecto, hay decisiones justificadas.

El enunciado del proyecto

Eres el ingeniero a cargo de diseñar Enlace, un acortador de URLs, desde cero. El equipo te da el enunciado vago —"diseña un acortador de URLs que aguante escala"— y las suposiciones de partida (los números que en un problema real le sacarías al cliente con preguntas):

• 100 millones de URLs nuevas al mes.
• Ratio lectura:escritura = 100:1 (la gente visita mucho más de lo que crea).
• Retención 5 años; URL larga promedio ~500 bytes; registro completo ~1 KB.
• Latencia de resolve < 100 ms; disponibilidad 99.9%.

Tu entregable son los cuatro artefactos del marco de 4 pasos:

1. Requisitos (paso 1): funcionales, no funcionales con número, y tabla de alcance.
2. Tabla de capacidad (paso 2): QPS, almacenamiento, ancho de banda, memoria —ejecutada, no citada—.
3. Diseño de alto nivel (paso 3): el diagrama de la arquitectura distribuida, con cada caja justificada.
4. Profundizar + tradeoffs (paso 4): el camino de escritura y el de lectura, el escalado de datos y de cómputo, y la lista de tradeoffs con su "gano/pago" numérico.

Hazlo tú primero, con tus manos, recorriendo el marco en orden. Cuando termines, abre la solución de referencia y compara —no para ver si coincides, sino para ver si tu criterio se sostiene—.

La rúbrica

Así se evalúa un diseño de Enlace. No es una lista de componentes que deben aparecer; es una lista de cualidades que un buen diseño tiene. Úsala para revisar el tuyo.

Un diseño que cumple los siete criterios es defendible ante cualquier pregunta. Fíjate en que ninguno pide "usa esta tecnología"; todos piden justificación, disciplina y honestidad. Eso es lo que se evalúa en el oficio.

Solución de referencia

FUNCIONALES
  F1  shorten(long_url) -> short_code   (base62, 7 chars; enla.ce/<code>)
  F2  resolve(short_code) -> 302 Location: long_url
  F3  short_code inexistente -> 404

NO FUNCIONALES (con numero)
  escrituras   ~40/s        lecturas   ~4,000/s (100:1, LECTURA PESADA)
  almacenamiento ~6 TB (5 anos)         latencia   resolve < 100 ms
  disponibilidad 99.9% (<=8.76 h/ano)   consistencia eventual OK para resolve

ALCANCE v1
  DENTRO: shorten, resolve, 404, redireccion 302
  FUERA:  analitica de clics, URLs personalizadas, expiracion, auth, rate-limit

# Solucion de referencia: la tabla de capacidad de Enlace.
writes_per_month = 100_000_000
seconds_per_month = 30 * 24 * 3600
qps_write = writes_per_month / seconds_per_month
qps_read = qps_write * 100
records = writes_per_month * 12 * 5
storage_tb = records * 1024 / 1e12
code_space = 62 ** 7
read_bw_mb = qps_read * 500 / 1e6
working_set = (writes_per_month / 30) * 0.20
cache_mb = working_set * 500 / 1e6

print(f"escrituras/s   = {qps_write:6.1f}  (~40)")
print(f"lecturas/s     = {qps_read:6.0f}  (~4000)")
print(f"registros 5a   = {records:,}")
print(f"almacenamiento = {storage_tb:5.2f} TB  (~6 TB)")
print(f"62^7           = {code_space:,}  ({records/code_space:.2%} usado)")
print(f"ancho banda    = {read_bw_mb:.2f} MB/s lectura (red NO es cuello)")
print(f"working set    = {working_set:,.0f} entradas = {cache_mb:.0f} MB")

escrituras/s   =   38.6  (~40)
lecturas/s     =   3858  (~4000)
registros 5a   = 6,000,000,000
almacenamiento =  6.14 TB  (~6 TB)
62^7           = 3,521,614,606,208  (0.17% usado)
ancho banda    = 1.93 MB/s lectura (red NO es cuello)
working set    = 666,667 entradas = 333 MB

graph TD
    C[Cliente / Navegador] -->|HTTP| LB{{Balanceador<br/>round-robin + health checks}}
    LB --> S1[Servidor 1<br/>sin estado]
    LB --> S2[Servidor 2<br/>sin estado]
    LB --> S3[Servidor 3<br/>sin estado]
    S1 --> CACHE[(Cache Redis<br/>~333 MB, hit 0.90)]
    S2 --> CACHE
    S3 --> CACHE
    CACHE -.miss 10%.-> ROUTER[Router de shards<br/>consistent hashing + vnodes]
    S1 -->|escritura| ROUTER
    ROUTER --> P0[(Shard 0 PRIMARY)]
    ROUTER --> P1[(Shard 1 PRIMARY)]
    P0 -->|repl. log| R0[(replicas x2)]
    P1 -->|repl. log| R1[(replicas x2)]

El resumen de la guía: los ocho módulos como un arco

Con el diseño de Enlace terminado, cierra la guía entera. Recorriste ocho módulos, y cada uno resolvió una grieta que el anterior dejó al descubierto —las mismas cuatro grietas de la caja única del módulo 1—:

• Módulo 1 — Cómo abordar. Entender antes de dibujar; el marco de 4 pasos; Enlace en una sola caja, con sus grietas medidas.
• Módulo 2 — Estimación. La matemática de servilleta: ~40 escrituras/s, ~4,000 lecturas/s, 6 TB, 62⁷ —los números-ancla que gobernaron cada decisión—.
• Módulo 3 — Modelo de datos e IDs. El registro Link; el short_code con contador + base62; por qué 7 caracteres alcanzan.
• Módulo 4 — Caché. Cache-aside; hit ratio 0.90 → 5.90 ms; working set ~333 MB (regla 80/20).
• Módulo 5 — Escalar la BD. Réplicas (primary/replica, lag); sharding; consistent hashing (13.1% vs 88.9%).
• Módulo 6 — Balanceo y stateless. Balanceador con health checks sobre servidores sin estado; el estado vive fuera.
• Módulo 7 — Fiabilidad y consistencia. Redundancia; CAP/PACELC; eventual vs fuerte; SLA/SLO como número.
• Módulo 8 — Proyecto. Las siete piezas juntas en un diseño distribuido defendible.

La habilidad que sale de aquí es la que el módulo 1 prometió: tomar un enunciado vago —"diseña un acortador de URLs"— y producir un diseño defendible con números, diagrama y tradeoffs explícitos. Ya no te congelas ante la página en blanco; recorres el marco de 4 pasos, y cada paso te dice cuál es tu siguiente movimiento. Y —lo más transferible— el método no es de Enlace: es de cualquier sistema. Cambia los números del enunciado, y el mismo marco produce el diseño de un pastebin, un servicio de fotos, un contador de "me gusta". Enlace fue el caso; el marco es lo que te llevas.

Hacia dónde seguir: el ecosistema

Esta guía enseñó los fundamentos de diseño y escalado, y a propósito dejó fronteras con sus guías hermanas del ecosistema. Ahora que dominas los fundamentos, esas guías son el siguiente paso —cada una profundiza en un tema que aquí solo tocamos como límite—:

• architectural-styles-and-boundaries-guide — el debate que evitamos: monolito vs. microservicios, DDD, bounded contexts. Enlace fue un servicio sin entrar en cómo trazar los límites entre servicios. Si te preguntaste "¿debería partir Enlace en microservicios?", la respuesta está ahí.
• event-driven-architecture-guide — lo que difirió el alcance: colas de mensajes, event sourcing, CQRS, streaming. La analítica de clics de Enlace —esa que sacamos de la v1 porque disparaba las escrituras— se diseña aquí, con colas y procesamiento asíncrono.
• resilience-and-reliability-patterns-guide — lo que mencionamos sin profundizar: circuit breaker, bulkhead, retry con backoff, el failover a fondo (cómo se detecta un primary caído, se promueve una réplica y se evita el "split brain"), idempotencia. Cuando dijimos "la réplica toma el relevo", esta guía dice cómo.
• api-design-and-integration-guide — el contrato que dejamos mínimo: versionado, paginación, contratos REST/gRPC. El shorten/resolve de Enlace fue un contrato de dos operaciones; diseñar APIs de verdad, con su evolución y sus garantías, es el tema de esa guía.

La regla mecánica para elegir a dónde ir: si la pregunta es "¿monolito o microservicios?", es la de estilos; si es "¿cómo proceso eventos asíncronos?", la de eventos; si es "¿cómo evito que un fallo tumbe todo?", la de resiliencia; si es "¿cómo diseño y verso mi API?", la de APIs. Los fundamentos que aprendiste aquí —estimar, cachear, escalar, razonar tradeoffs— son el cimiento sobre el que todas ellas construyen.

Errores comunes

Entregar un diseño sin haberlo recorrido en orden. Qué pasa: alguien salta directo al diagrama (paso 3) y a los tradeoffs (paso 4) sin escribir los requisitos (paso 1) ni ejecutar la tabla (paso 2), y presenta un diseño que "se ve completo" pero cuya justificación no se sostiene —no puede decir por qué tres réplicas, ni por qué sharding por short_code, porque no hizo el paso 2—. Por qué pasa: el diagrama es lo visible y lo divertido; requisitos y estimación se sienten como trámite. Cómo detectarlo: si tu entregable no tiene los cuatro artefactos, o si el diagrama no puede señalar la tabla, saltaste pasos. Cómo corregirlo: recorre el marco en orden, aunque conozcas Enlace de memoria. El paso 1 justifica el paso 2, que justifica el 3, que justifica el 4. Un diseño sin esa cadena es un dibujo bonito sin cimiento.

Optimizar para coincidir con la solución de referencia. Qué pasa: alguien mira la solución de referencia y ajusta su diseño para que coincida —mismo hit ratio, mismo número de shards, mismas palabras— pensando que "coincidir" es "acertar". Pierde la oportunidad de ejercer criterio propio. Por qué pasa: se confunde el examen del oficio con un examen de memoria. Cómo detectarlo: si cambiaste tu diseño solo para parecerte a la referencia, sin una razón numérica, estás copiando. Cómo corregirlo: la rúbrica evalúa criterio, no coincidencia. Un hit ratio de 0.95 en vez de 0.90, o cuatro shards en vez de dos, es igual de válido si lo justificas con números. Como el piloto: dos vuelos distintos aprueban si cada decisión está fundada. Defiende tu diseño con tus números; no lo dobles para imitar el ajeno.

Cerrar el diseño en el caso feliz. Qué pasa: alguien entrega un diseño que funciona perfecto el día bueno —caché caliente, todos los nodos vivos, tráfico plano— y no dice una palabra de qué pasa cuando la caché se vacía, un nodo se cae, o llega un pico viral. El diseño se ve robusto y es frágil. Por qué pasa: el caso feliz es el que se piensa primero, y anticipar fallos es incómodo. Cómo detectarlo: si tu entregable no tiene una sección "el día malo", está incompleto. Cómo corregirlo: incluye siempre qué pasa a hit ratio 0 (el miss masivo: 3,858/s a la BD), qué pasa si cae un primary (failover, un shard afectado), qué pasa en el pico (×3). Un diseño que solo describe el día bueno es media propuesta —la otra media es demostrar que sobrevive el día malo—.

Ejercicios

Ejercicio 1 — Autoevalúa tu diseño con la rúbrica. Toma el diseño de Enlace que produjiste (o, si no lo hiciste, la solución de referencia) y pásale los siete criterios de la rúbrica, uno por uno. Para cada criterio, di si tu diseño lo cumple y con qué evidencia concreta (qué número, qué caja, qué sección). Identifica el criterio más débil de tu diseño y cómo lo reforzarías.

Ejercicio 2 — Adapta el diseño a un requisito nuevo. El equipo cambia un requisito: ahora la analítica de clics entra en la v1 (hay que contar cada visita). Sin rehacer todo el diseño, describe: (a) qué número de la tabla de capacidad cambia y cómo; (b) qué componente nuevo hace falta y por qué; (c) a qué guía hermana pertenece ese componente.

Ejercicio 3 — Defiende tu diseño ante tres preguntas de entrevista. Un entrevistador cuestiona tu diseño de Enlace. Responde a cada pregunta en un par de frases, con números: (a) "¿Por qué una caché y no simplemente más réplicas de base de datos?" (b) "¿Por qué 7 caracteres para el short_code?" (c) "¿No te preocupa la consistencia? ¿Qué pasa si dos usuarios leen el mismo link y las réplicas están desincronizadas?"

Resumen y siguiente paso

En este proyecto —el capstone de la guía— diseñaste Enlace de punta a punta, juntando las siete herramientas de los módulos anteriores en un solo entregable defendible. Produjiste los cuatro artefactos del marco de 4 pasos: los requisitos (con alcance que difiere la analítica), la tabla de capacidad ejecutada (~40, ~4,000, 6 TB, 62⁷, 333 MB), el diagrama de la arquitectura distribuida (balanceador → servidores sin estado → caché → primaries sharded con réplicas), y el profundizar con la lista de tradeoffs justificados. Y viste, con el examen práctico del piloto, que lo que se evalúa no es coincidir con la solución de referencia sino ejercer criterio: cada caja con su número, el marco en orden, cada tradeoff con su "gano/pago", y el día malo anticipado.

Cerraste la guía: los ocho módulos como un arco causal, la habilidad que sale de aquí (tomar un enunciado vago y producir un diseño con números, diagrama y tradeoffs), y el método transferible a cualquier sistema. Y viste hacia dónde seguir —las guías hermanas del ecosistema: estilos arquitectónicos, arquitectura dirigida por eventos, patrones de resiliencia, y diseño de APIs—, cada una profundizando en una frontera que aquí solo tocamos.

Antes de dar la guía por terminada deberías poder: recorrer el marco de 4 pasos de corrido para diseñar Enlace (o cualquier sistema) desde cero; producir los cuatro artefactos del entregable; autoevaluar un diseño con la rúbrica; y defender cada decisión ante preguntas, con números y con la naturaleza del problema.

El siguiente paso ya no está en esta guía: está en el ecosistema. Con los fundamentos de diseño y escalado dominados, elige la guía hermana que responda tu próxima pregunta —"¿monolito o microservicios?", "¿cómo proceso eventos?", "¿cómo hago esto resiliente?", "¿cómo diseño mi API?"— y sigue construyendo sobre el cimiento que acabas de terminar. Sabes abordar un problema abierto, estimarlo, modelarlo, cachearlo, escalarlo, distribuirlo, razonar sus tradeoffs, y diseñarlo entero. Eso es diseñar sistemas.

Recursos

• System Design Primer — "Design a URL shortener" (ejercicio completo) — el mismo caso de Enlace resuelto de punta a punta en el Primer (como pastebin/acortador), con requisitos, estimación, diseño y escalado. La segunda voz ideal para contrastar tu diseño de referencia con otro camino defendible.
• Designing Data-Intensive Applications, de Martin Kleppmann — sitio oficial — el libro de referencia del oficio, que te acompañará más allá de esta guía. Habiendo terminado el capstone, sus Capítulos 5 (Replication), 6 (Partitioning) y 9 (Consistency and Consensus) profundizan cada decisión que tomaste en Enlace, y son el puente natural hacia las guías hermanas.
• System Design Interview – An Insider's Guide, de Alex Xu — la colección canónica de diseños completos de sistemas (acortador, feed, chat, notificaciones), con la misma estructura de requisitos → estimación → diseño → profundizar de esta guía. El recurso para practicar el marco de 4 pasos sobre casos nuevos, ahora que lo dominas con Enlace.