¿Cómo haces la planificación de capacidad y las estimaciones a grosso modo para un sistema nuevo?

#Esto no es un examen de matemáticas — es un examen de criterio

La estimación a grosso modo aparece en casi toda entrevista de diseño de sistemas, y el malentendido más grande es pensar que te califican por la precisión aritmética. No es así. El entrevistador observa tres cosas: si expresas tus suposiciones de forma explícita en lugar de sacar números de la nada, si tus unidades se mantienen consistentes al encadenar cálculos, y si el número resultante realmente cambiaría una decisión de diseño (por ejemplo, "¿necesitamos sharding desde el día uno, o una sola instancia robusta de Postgres? aguanta dos años?").

Una buena estimación es redonda, defendible y rápida. Una mala estimación es precisa, sin explicación, y lenta — a nadie le sirve "14,237.8 solicitudes por segundo" cuando "más o menos 15K RPS, digamos 20K por seguridad" lleva a las mismas decisiones de diseño en un tercio del tiempo.

#El marco de trabajo

Recorre las capas en este orden, porque cada una alimenta a la siguiente:

1. Delimitar el alcance — ¿es un sistema de lectura intensiva o de escritura intensiva? ¿Cuál es el periodo de retención? ¿Cuál es un horizonte de crecimiento razonable (la mayoría de las entrevistas quieren de 1 a 3 años, no 10)?
2. Tráfico (QPS) — convertir un número de negocio (registros/día, publicaciones/día) en solicitudes por segundo, tanto para carga promedio como para carga pico.
3. Almacenamiento — tamaño por registro por cantidad de registros por periodo de retención por factor de replicación.
4. Ancho de banda — QPS por tamaño promedio del payload, por separado para entrada y salida.
5. Memoria / caché — qué fracción del tráfico puede absorber una caché, y qué tan grande debe ser esa caché.
6. Servidores — dado el throughput realista de una sola instancia, cuántas instancias exige la carga estimada.

#Ejemplo resuelto: un servicio acortador de URLs

Suposiciones (decláralas en voz alta primero):

Paso 1 — QPS de escritura. Un mes son aproximadamente 30 x 24 x 3600 ≈ 2.6 millones de segundos. 500,000,000 / 2,600,000 ≈ ~190 escrituras/seg en promedio. Aplicando el factor pico de 3x: ~570 escrituras/seg en pico.

Paso 2 — QPS de lectura. Con proporción lectura:escritura de 100:1: 190 x 100 = ~19,000 lecturas/seg en promedio, y aproximadamente ~57,000 lecturas/seg en pico.

Paso 3 — Almacenamiento. 500M registros/mes x 500 bytes ≈ 250 GB/mes de datos nuevos. En 5 años (60 meses): 250 GB x 60 ≈ 15 TB de datos crudos. Con replicación 3x por durabilidad: ~45 TB en total.

Paso 4 — Ancho de banda. Salida en pico: 57,000 lecturas/seg x (digamos) 1 KB de respuesta promedio (una redirección más encabezados) ≈ ~57 MB/seg de salida. Ese número vale la pena contrastarlo con el throughput típico de un nodo de borde de CDN — te dice casi de inmediato si esto cabe cómodamente detrás de una CDN o necesita capacidad dedicada.

Paso 5 — Tamaño de la caché. El acceso real a enlaces sigue una ley de potencias — una fracción pequeña de enlaces concentra la mayoría de las redirecciones. Si el 20% de códigos cortos más activos por día representa el 80% de las lecturas (la clásica división 80/20), cachear ese conjunto caliente en algo como Redis significa: con, digamos, 10 millones de enlaces activos por día, el 20% son 2 millones de entradas x ~100 bytes (solo el mapeo código a URL larga, no el registro completo) ≈ ~200 MB — trivialmente cacheable en memoria en un solo nodo, con margen de sobra para réplicas.

Paso 6 — Servidores. Si un servidor de aplicación maneja cómodamente unas 5,000 solicitudes/seg, la carga de lectura pico de ~57,000/seg necesita del orden de 12 instancias, antes de sumar margen para failover y despliegues progresivos — así que se redondea a 15-18.

#Atajos mentales útiles

• Un día tiene ~86,400 segundos — redondea a 100,000 para dividir mentalmente más rápido (introduce ~15% de error, aceptable a este nivel de precisión).
• Un mes son ~2.6 millones de segundos, un año son ~31.5 millones de segundos (~3.15 x 10^7) — vale la pena memorizarlos directamente.
• Potencias de dos para almacenamiento: 2^10 ≈ 10^3 (KB), 2^20 ≈ 10^6 (MB), 2^30 ≈ 10^9 (GB), 2^40 ≈ 10^12 (TB) — tratarlos como equivalentes es el atajo estándar y aceptado en estas entrevistas.
• 1 millón de solicitudes/día ≈ 12 solicitudes/seg en promedio — vale la pena memorizarlo, porque muchos enunciados arrancan con un número de usuarios activos diarios.

#Errores que cuestan más que un número equivocado

Otros errores comunes: olvidar la sobrecarga de metadatos/índices (una base de datos rara vez guarda solo tus bytes crudos — índices, WAL y logs de replicación agregan una sobrecarga real, a menudo de 20-50%), y sobre-indexar en precisión (gastar tres minutos multiplicando números de 4 dígitos a mano en lugar de redondear a una cifra significativa y avanzar hacia la decisión de diseño que el número debía informar).

🧠 Check your understanding
0/3 · 0/3 answered
1. ¿Qué es lo principal que evalúan los entrevistadores en un ejercicio de estimación a grosso modo?
Si el candidato conoce el precio exacto actual del almacenamiento en la nubeSi la respuesta numérica final coincide exactamente con un valor de referencia memorizadoSi las suposiciones se declaran explícitamente, las unidades se mantienen consistentes, y el resultado influiría en una decisión de diseño realSi el candidato puede multiplicar números grandes rápidamente sin calculadora
2. ¿Por qué olvidar la proporción pico:promedio del tráfico es un error serio de estimación?
Hace que el cálculo tome más tiempoNo tiene efecto real en el dimensionamiento de infraestructuraAprovisionar solo para la carga promedio significa que el sistema falla justo cuando más importan los picos de cargaEl tráfico pico siempre es exactamente el doble del promedio en todo sistema
3. Al estimar almacenamiento para un sistema duradero, ¿por qué debe aplicarse el factor de replicación sobre el tamaño de datos crudo?
El factor de replicación solo importa para cómputo, no para almacenamientoEl disco realmente aprovisionado debe cubrir cada réplica de los datos, no solo una copia lógica, así que el tamaño crudo subestima las necesidades reales de infraestructura por el múltiplo de replicaciónEl tamaño de datos crudo ya contempla todas las copias necesarias para durabilidadEl factor de replicación solo es relevante para sistemas de lectura intensiva