Estimación Rápida (Back-of-the-Envelope)

La estimación rápida es una habilidad crítica para entrevistas de diseño de sistemas y decisiones de arquitectura del mundo real. Permite a los ingenieros determinar rápidamente si un diseño es factible, identificar cuellos de botella y tomar decisiones tecnológicas informadas sin construir prototipos. El objetivo no es precisión exacta sino razonamiento correcto del orden de magnitud.

Por Qué Importan las Estimaciones

Determina si se necesita un solo servidor o un sistema distribuido
Identifica qué componentes necesitan escalado horizontal
Ayuda a elegir entre diferentes tecnologías de almacenamiento
Valida o invalida decisiones arquitectónicas antes de implementar
Demuestra pensamiento estructurado en entrevistas

Números Comunes que Todo Ingeniero Debe Conocer

Estos son valores aproximados que sirven como bloques de construcción para estimaciones. Memoriza los órdenes de magnitud, no los números exactos.

Números de Latencia

Operación	Latencia	Notas
Referencia caché L1	~1 ns	Caché en CPU
Referencia caché L2	~4 ns	Caché en CPU
Referencia memoria principal (RAM)	~100 ns	Acceso DRAM
Lectura aleatoria SSD	~150 us	1000x más lento que RAM
Lectura aleatoria HDD	~10 ms	Tiempo de búsqueda mecánica
Ida y vuelta mismo datacenter	~0.5 ms	Red dentro del DC
Ida y vuelta intercontinental	~150 ms	Límite de velocidad de la luz
Redis GET	~0.5 ms	En memoria + red
Consulta simple PostgreSQL	~2-5 ms	Consulta indexada
Llamada API externa	~50-200 ms	Servicio de terceros

Números de Rendimiento

Sistema	Rendimiento	Notas
Servidor web individual (Node.js)	~10,000 RPS	Endpoints API simples
PostgreSQL	~10,000 consultas/s	Consultas indexadas simples
Redis	~100,000 ops/s	Instancia individual
Kafka (partición individual)	~10,000 msg/s	Rendimiento por partición
Kafka (clúster)	~1,000,000 msg/s	Con muchas particiones

Números de Almacenamiento y Tamaño de Datos

Dato	Tamaño
Carácter ASCII	1 byte
Carácter UTF-8 (promedio)	2 bytes
UUID	16 bytes
Tweet típico / mensaje corto	~250 bytes
Respuesta JSON API típica	~2 KB
Foto comprimida	~200 KB
1 minuto de audio MP3	~1 MB
1 minuto de video HD	~50 MB

Referencia Rápida de Potencias de 2

Potencia	Valor Exacto	Aproximado
2^10	1,024	~1 mil (1 KB)
2^20	1,048,576	~1 millón (1 MB)
2^30	1,073,741,824	~1 mil millones (1 GB)
2^40	1,099,511,627,776	~1 billón (1 TB)

Marco de Estimación

Sigue este enfoque sistemático para cualquier problema de estimación:

// Estimation framework as code
interface EstimationProblem {
  question: string;
  assumptions: Record<string, number>;
  calculate(): EstimationResult;
}

// Example: Estimate Twitter's storage needs for tweets
class TwitterStorageEstimation implements EstimationProblem {
  question = "How much storage does Twitter need for tweets per day?";

  assumptions = {
    dailyActiveUsers: 300_000_000,       // 300M DAU
    tweetsPerUserPerDay: 0.5,
    avgTweetSizeBytes: 250,
    metadataPerTweetBytes: 200,
    mediaAttachmentRate: 0.2,            // 20% of tweets have media
    avgMediaSizeBytes: 200_000,          // 200KB per image
  };

  calculate() {
    const a = this.assumptions;

    const totalTweetsPerDay = a.dailyActiveUsers * a.tweetsPerUserPerDay;
    // = 300M * 0.5 = 150M tweets/day

    const textStoragePerDay = totalTweetsPerDay * (a.avgTweetSizeBytes + a.metadataPerTweetBytes);
    // = 150M * 450 bytes = 67.5 GB/day

    const mediaStoragePerDay = totalTweetsPerDay * a.mediaAttachmentRate * a.avgMediaSizeBytes;
    // = 150M * 0.2 * 200KB = 6 TB/day

    const totalPerDay = textStoragePerDay + mediaStoragePerDay;
    // = ~6 TB/day (media dominates)

    const totalPerYear = totalPerDay * 365;
    // = ~2.2 PB/year

    return {
      tweetsPerDay: "150 million",
      textStoragePerDay: "~67.5 GB",
      mediaStoragePerDay: "~6 TB",
      totalPerDay: "~6 TB",
      totalPerYear: "~2.2 PB",
      conclusion: "Media storage dominates. Need distributed object storage like S3.",
    };
  }
}

Ejemplos Prácticos con Soluciones

Ejemplo 1: QPS para un Acortador de URLs

Pregunta: Estima el QPS para un acortador de URLs con 100 millones de URLs creadas por mes.

100M URLs/mes = 100M / (30 * 24 * 3600) = ~40 URLs/segundo (escrituras)
El ratio lectura:escritura para acortadores de URLs es típicamente 100:1
QPS de lectura = 40 * 100 = ~4,000 lecturas/segundo
Pico = 2-3x el promedio = ~10,000 lecturas/segundo
Conclusión: Una sola instancia de PostgreSQL puede manejar esto. Agregar caché Redis para URLs populares.

Ejemplo 2: Ancho de Banda para un Servicio de Streaming de Video

Pregunta: Estima el ancho de banda necesario para un servicio que transmite a 10 millones de usuarios concurrentes.

Bitrate promedio de video: 5 Mbps (1080p)
10M usuarios concurrentes * 5 Mbps = 50 Tbps
Esto es masivo; un solo centro de datos no puede servir esto
Conclusión: Se debe usar un CDN global con caché en el borde. La mayor parte del tráfico se sirve desde PoPs del CDN, no desde servidores origen.

Ejemplo 3: Tamaño de Base de Datos para una Plataforma de Redes Sociales

Pregunta: Estima el tamaño de base de datos para almacenar perfiles de usuario de 1 mil millones de usuarios.

Datos de perfil: nombre (50B), email (50B), bio (200B), configuración (100B), metadatos (100B) = ~500 bytes
1B usuarios * 500 bytes = 500 GB
Con índices (2x de overhead): ~1 TB
Conclusión: Cabe en un solo servidor de base de datos grande para almacenamiento, pero la carga de consultas requerirá sharding o réplicas de lectura.

Conversiones de Tiempo Útiles

Período	Segundos	Aproximación Rápida
1 día	86,400	~100,000 (10^5)
1 mes	2,592,000	~2.5 millones (2.5 * 10^6)
1 año	31,536,000	~30 millones (3 * 10^7)

Consejos para Entrevistas de Diseño de Sistemas

Declara tus suposiciones claramente. Los entrevistadores se preocupan más por tu proceso de razonamiento que por números exactos
Redondea agresivamente. Usa potencias de 10 y multiplicadores simples. 86,400 segundos/día se convierte en 100,000
Muestra tu trabajo. Escribe cada paso para que el entrevistador pueda seguir tu lógica
Verifica tu respuesta. Si calculas que un solo laptop puede manejar todo el tráfico de Google, algo está mal
Enfócate en los cuellos de botella. Usa las estimaciones para identificar qué componente necesita más atención