8. Proyecto: la tabla de capacidad de Enlace

Descripción

Este es el capstone del módulo: el momento en que dejas de calcular un número a la vez y produces, de cero y tú solo, la tabla de capacidad completa de Enlace. Partiendo únicamente de la escala —los números-ancla del enunciado— vas a derivar los cuatro números de capacidad (QPS, almacenamiento, ancho de banda, memoria), con sus variantes de promedio y pico, con índices y réplicas donde toca, cada cuenta ejecutada en Python, un sanity check por fila, y una nota de supuestos. El entregable es lo que llevarías a una pizarra de diseño o a una entrevista: una tabla defendible que resume, en cinco filas, la capacidad de todo el sistema.

No hay tema nuevo aquí. Todo lo que necesitas lo aprendiste en las lecciones 2 a 7: las herramientas (potencias de 10, segundos por día, unidades), las cuatro cuentas (una por lección), y la disciplina de redondeo y verificación de la lección 7. Este proyecto es el ensamblaje: juntar las piezas en un solo artefacto coherente, con el rigor de que cada número se calcula (no se cita), se redondea con criterio, se cruza con un sanity check, y viene con sus supuestos declarados. Al terminar tendrás la tabla de capacidad de Enlace y —más importante— el método para producir la de cualquier sistema a partir de su escala.

Conexión con el módulo: esta lección cierra el módulo juntando todo. Cada fila de la tabla es una lección: QPS (3), almacenamiento (4), ancho de banda (5), memoria (6); y la disciplina que la vuelve confiable es la lección 7. La tabla que armes aquí es la que Enlace lleva consigo el resto de la guía: en el módulo 3 justificará el modelo de datos y por qué 7 caracteres base62 alcanzan; en el módulo 4, la caché (el working set de 333 MB y el hit ratio); en el módulo 5, la decisión de réplicas y sharding (los 6/27 TB y las 12,000 lecturas/s de pico); en los módulos 6 y 7, el balanceo y los tradeoffs. La frontera del módulo se mantiene hasta el final: aquí estimamos, no diseñamos. La tabla produce los números que las decisiones de diseño usarán; no toma esas decisiones.

El plano de cargas antes de construir

Antes de que un ingeniero estructural levante un edificio, produce una tabla de cargas: cuánto peso soporta cada columna, cuánta fuerza de viento aguanta la fachada, cuánta gente cabe por piso según el código. No es el edificio —no tiene ni una pared dibujada todavía— pero es lo que decide si el edificio es siquiera posible y de qué tamaño deben ser sus vigas. Un plano hecho sin esa tabla es una fantasía bonita que se cae; la tabla de cargas es lo que convierte el dibujo en algo que se puede construir y defender ante el inspector.

La tabla de capacidad es exactamente eso para un sistema. No es el diseño —no tiene cajas ni flechas todavía— pero es lo que dice si el sistema cabe en un servidor o en cien, si la red aguanta, si vale la pena una caché, si hay que repartir la base de datos. Un diseño hecho sin tabla de capacidad es sobreingeniería o subdimensionamiento disfrazados de arquitectura; la tabla es lo que ancla cada decisión posterior a un número que puedes justificar. Por eso este proyecto va al final del módulo de estimación y antes de los módulos de diseño: produces el plano de cargas primero, y con él en la mano, los módulos 3 a 7 dibujan el edificio con criterio.

Y como el ingeniero ante el inspector, la prueba de que tu tabla sirve es que aguanta preguntas. "¿Por qué caché?" → "porque son 4,000 lecturas/s creciendo y el working set cabe en 333 MB de RAM". "¿Por qué no sharding?" → "porque 6 TB caben en un servidor; el QPS lo resuelve la caché". Cada respuesta es una fila de la tabla. Eso es lo que vas a construir.

El encargo

Te dan la escala de Enlace y nada más. Produce la tabla de capacidad completa.

La escala (los números-ancla, idénticos a toda la guía):

• 100 millones de URLs nuevas por mes.
• Ratio lectura:escritura = 100:1.
• Retención: 5 años. URL larga promedio: ~500 bytes; registro completo: ~1 KB.
• Factor de pico a asumir: 3x (dentro del rango 2–3x para servicios web).

Lo que debes entregar:

1. La tabla de capacidad, con estas cinco filas, cada número calculado (no citado):
   • QPS — escritura y lectura, promedio y pico.
   • Almacenamiento — crudo a 5 años, con índices, y aprovisionado con réplicas.
   • Ancho de banda — escritura y lectura, promedio y pico; egress mensual.
   • Memoria — el working set (20% caliente) y su relación con el total en disco.
   • Derivados — servidores para el pico y concurrencia (Ley de Little).
2. Una nota de supuestos: cada supuesto que sostiene la tabla (mes de 30 días, factor de pico 3x, índice +50%, réplica ×3, entrada de caché 500 B, etc.).
3. Un sanity check por fila: la marca esperada y una referencia que valida el número.

Intenta hacerlo tú antes de mirar la solución. Abre python3, teclea las cuentas, redondea a una cifra significativa, y arma la tabla. La solución completa —con el script ejecutado— está abajo.

Guía: el orden de ensamblaje

Los números se encadenan, así que hay un orden natural que evita recalcular. Síguelo:

1. QPS primero, porque casi todo lo demás depende de él. Escritura (100M/mes ÷ segundos/mes), luego lectura (× ratio), luego pico (× factor). Redondea aquí: los números redondeados (40, 4,000) son los que alimentan las filas siguientes.
2. Almacenamiento, que no depende del QPS sino del enunciado directo (registros × retención × tamaño), más los factores de índice y réplica.
3. Ancho de banda, que reutiliza el QPS (QPS × payload) para escritura y lectura, promedio y pico, más el egress mensual.
4. Memoria, que reutiliza las URLs nuevas por día (derivadas del QPS de escritura) para el working set (20% × 500 B).
5. Derivados al final: servidores (QPS pico ÷ capacidad por servidor) y concurrencia (Ley de Little).

Con ese orden, cada fila usa números que ya calculaste, y no repites trabajo. Ahora, la solución.

Solución

# TABLA DE CAPACIDAD DE ENLACE — de la escala a los numeros, todo calculado.

# --- NUMEROS-ANCLA (el enunciado, lo unico dado) ---
urls_per_month   = 100_000_000     # 100M URLs nuevas/mes
read_write_ratio = 100             # lectura:escritura = 100:1
retention_years  = 5               # retencion
url_bytes        = 500             # URL larga promedio (payload y entrada de cache)
record_bytes     = 1_000           # registro completo ~1 KB (en disco)
peak             = 3               # factor de pico (rango 2-3x)
sec_month        = 30 * 24 * 3600  # 2,592,000 s/mes
sec_day          = 86_400          # s/dia

# --- FILA 1: QPS (se redondea aqui; las filas siguientes parten del redondeado) ---
qps_write = round(urls_per_month / sec_month, -1)      # 38.58 -> 40
qps_read  = round(qps_write * read_write_ratio, -3)    # 4000
print(f"[QPS]        escritura ~{qps_write:.0f}/s prom, ~{qps_write*peak:.0f}/s pico | "
      f"lectura ~{qps_read:.0f}/s prom, ~{qps_read*peak:.0f}/s pico")

# --- FILA 2: ALMACENAMIENTO (registros x retencion x tamanio, + indices + replicas) ---
records  = urls_per_month * 12 * retention_years
raw      = records * record_bytes
print(f"[STORAGE]    {records/1e9:.0f}e9 registros | crudo {raw/1e12:.0f}TB, "
      f"+idx {raw*1.5/1e12:.0f}TB, +repl x3 {raw*1.5*3/1e12:.0f}TB")

# --- FILA 3: ANCHO DE BANDA (QPS x payload) ---
write_bw     = qps_write * url_bytes
read_bw      = qps_read * url_bytes
egress_month = read_bw * sec_day * 30
print(f"[BANDWIDTH]  escritura {write_bw/1e3:.0f}KB/s prom, {write_bw*peak/1e3:.0f}KB/s pico | "
      f"lectura {read_bw/1e6:.0f}MB/s prom, {read_bw*peak/1e6:.0f}MB/s pico | egress {egress_month/1e12:.1f}TB/mes")

# --- FILA 4: MEMORIA (working set = 20% caliente de las URLs distintas/dia) ---
new_urls_day = urls_per_month / 30
working_set  = new_urls_day * 0.20 * url_bytes
print(f"[MEMORY]     WS = 20% x {new_urls_day/1e6:.1f}M URLs/dia x {url_bytes}B = {working_set/1e6:.0f}MB "
      f"({raw/working_set:,.0f}x menor que el disco)")

# --- DERIVADOS: servidores (pico / capacidad) y concurrencia (Ley de Little) ---
servers = qps_read * peak / 2000
conc    = qps_read * peak * 0.010      # 10 ms por peticion
nic     = 1e9 / 8 / 1e6                # NIC de 1 Gbps en MB/s
print(f"[DERIVED]    servidores ~{servers:.0f} (+1={servers+1:.0f}) | concurrencia ~{conc:.0f} | "
      f"pico lectura = {read_bw*peak/1e6/nic*100:.1f}% de NIC 1Gbps")

[QPS]        escritura ~40/s prom, ~120/s pico | lectura ~4000/s prom, ~12000/s pico
[STORAGE]    6e9 registros | crudo 6TB, +idx 9TB, +repl x3 27TB
[BANDWIDTH]  escritura 20KB/s prom, 60KB/s pico | lectura 2MB/s prom, 6MB/s pico | egress 5.2TB/mes
[MEMORY]     WS = 20% x 3.3M URLs/dia x 500B = 333MB (18,000x menor que el disco)
[DERIVED]    servidores ~6 (+1=7) | concurrencia ~120 | pico lectura = 4.8% de NIC 1Gbps

Errores comunes

Entregar cifras sin conclusiones (de tabla que no comunica). Qué pasa: alguien produce las cinco filas de números correctos pero se detiene ahí, sin la columna de "qué significa cada uno", y quien la lee tiene los datos pero no el diseño. Por qué pasa: calcular se siente como el trabajo, y traducir el número a una decisión parece un extra. Cómo detectarlo: si tu tabla es una lista de valores sin una conclusión por fila, entregaste la mitad. Cómo corregirlo: cada número termina en una decisión ("~4,000 lecturas/s → pide caché y réplicas"), nunca en sí mismo. La tabla útil no dice "el QPS de lectura es 4,000"; dice "es 4,000, así que caché". El número es el medio; la conclusión es el entregable.

No declarar los supuestos (de tabla que no se puede auditar). Qué pasa: la persona entrega "27 TB" sin decir que asume índices +50%, réplica ×3 y cero expiración, y cuando alguien pregunta "¿y si expiran a 2 años?" no puede responder porque no sabe qué asumió. Por qué pasa: los supuestos se toman por defecto y se olvidan una vez hecha la cuenta. Cómo detectarlo: si no puedes listar de memoria cada perilla que sostiene un número, no lo declaraste. Cómo corregirlo: acompaña la tabla con una nota de supuestos explícita —cada factor, cada redondeo, cada régimen asumido—. Una tabla con supuestos declarados es auditable y ajustable; una sin ellos es un número mágico que se cae con la primera repregunta.

Recalcular en vez de encadenar (de ignorar que los números se alimentan). Qué pasa: alguien vuelve al enunciado para cada fila —divide otra vez 100M entre los segundos, vuelve a estimar las URLs por día desde cero— en vez de reutilizar los números ya calculados, y en el camino introduce inconsistencias (usa 40/s para el ancho de banda pero 38.58/s para la memoria). Por qué pasa: no se ve el grafo de dependencias entre los números. Cómo detectarlo: si el mismo número aparece con dos valores distintos en filas distintas, no encadenaste; recalculaste con redondeos distintos. Cómo corregirlo: sigue el orden de ensamblaje (QPS → todo lo demás), fija el valor redondeado una vez, y aliméntalo a las filas que dependen de él. El ancho de banda y la memoria parten del mismo QPS redondeado que el QPS reporta; así la tabla es internamente consistente.

Ejercicios

Ejercicio 1 — Enlace crece 10×. El producto despega y ahora entran 1,000 millones de URLs/mes (10× la escala original), con todos los demás supuestos iguales. Recalcula la tabla y di, fila por fila, cuáles conclusiones de diseño cambian y cuáles no. En particular: ¿sigue sin necesitar sharding por espacio? ¿La red sigue sobrada?

Ejercicio 2 — La perilla de la expiración. El equipo decide que las URLs expiran a los 2 años en vez de guardarse 5. ¿Qué filas de la tabla cambian y cuáles no? Recalcula el almacenamiento en estado estable y di si esto altera la decisión de sharding.

Ejercicio 3 — Defiende el diseño con la tabla. Un compañero propone, para el Enlace original (100M/mes): "hay que shardear la base de datos en 10 nodos desde el día uno, meter una cola de mensajes para las escrituras, y poner una CDN global para el ancho de banda". Usando solo la tabla de capacidad, argumenta en tres o cuatro frases por qué cada una de esas tres piezas es sobreingeniería para la escala de Enlace, citando el número que la desmiente.

Resumen y siguiente paso

En este capstone produjiste, de cero y a partir de la sola escala, la tabla de capacidad completa de Enlace: QPS (~40/~4,000 promedio, ~120/~12,000 pico), almacenamiento (6 TB crudo · 9 con índices · 27 con réplicas), ancho de banda (~2 MB/s lectura, ~5.2 TB/mes de egress), memoria (working set ~333 MB, 18,000× menor que el disco) y derivados (~6–7 servidores, ~120 conexiones concurrentes). Cada número lo calculaste en Python, lo redondeaste a una cifra significativa, lo cruzaste con un sanity check, y lo acompañaste de una nota de supuestos que hace la tabla auditable. Y practicaste lo más importante: leer la tabla como una historia de diseño —escritura trivial, lectura pesada, disco manejable, red sobrada, caché rentable— y usarla para defender qué construir y qué no.

Antes de cerrar el módulo deberías poder: producir la tabla de capacidad de cualquier sistema a partir de su escala, siguiendo el orden de ensamblaje (QPS → todo lo demás); acompañarla de sus supuestos y de un sanity check por fila; recalcularla cuando cambia un supuesto (escala 10×, expiración) sabiendo qué filas se mueven; y usarla para desmontar sobreingeniería con el número que la desmiente.

Con esto cierras el módulo 2. Tienes las herramientas (potencias de 10, unidades), las cuatro cuentas de capacidad, la disciplina de redondeo y verificación, y la tabla que resume todo. Enlace deja de ser un enunciado vago y pasa a ser un sistema con números defendibles. El módulo 3 toma esos números y empieza a diseñar: el modelo de datos del registro Link, SQL contra NoSQL para este caso, y —el corazón— la generación del short_code: hash contra contador+base62 contra random, la función base62_encode/decode, y por qué 7 caracteres base62 alcanzan (62⁷ ≈ 3.5 × 10¹² códigos, de sobra para los 6 mil millones de registros que esta tabla proyectó). La estimación terminó; empieza el diseño, y lo empieza con los números que produjiste aquí en la mano.

Recursos

• The System Design Primer, "Back-of-the-envelope calculations" y el ejercicio del acortador de URLs (Design Pastebin.com / Bit.ly) — github.com/donnemartin/system-design-primer. Recorre una tabla de capacidad casi idéntica a la de Enlace, con la misma estructura de QPS, almacenamiento y ancho de banda. El mejor complemento gratuito para este capstone; en inglés.
• Martin Kleppmann, Designing Data-Intensive Applications, Capítulo 1 ("Reliability, Scalability, and Maintainability") — dataintensive.net. El marco conceptual para describir la carga de un sistema (throughput, percentiles, ratios) que sostiene toda la tabla de capacidad. El libro de cabecera de la guía; en inglés.
• Alex Xu, System Design Interview – An Insider's Guide, capítulo "Back-of-the-envelope estimation" y "Design a URL shortener" — resumen y figuras en bytebytego.com. Presenta la estimación de un acortador de URLs paso a paso, con el mismo espíritu de tabla de capacidad defendible que armamos aquí. En inglés.