Requirements

Functional Requirements:

• generar urls cortas
• guardar la url larga

Non-Functional Requirements:

• alta disponibilidad:
• baja latencia: <50ms
• escalabilidad: preparar el sistema para que sea escalable
• consistencia eventual: toleramos que la url nueva tarde algunos ms en propagarse

Capacity Estimation

Trafico:

• Escritura: 100M URLs/mes → ~40 writes/s
• Lectura: ratio 100:1 → ~4,000 reads/s (pico: ~8,000 reads/s)

Almacenamiento: - Por entrada: ~300 bytes (ID + URL + metadatos) - Mensual: 100M × 300 bytes = ~30 GB/mes - 3 años: ~1.08 TB

API Design

POST: /shorten

GET: /:id

GET: /urls

High-Level Design

Write Path:

1. Cliente envía URL larga a POST /shorten

2. Load Balancer distribuye a un App Server

3. App Server genera ID único (Base62) 4. Guarda {id, long_url, created_at} en BD

5. Almacena en Redis para acceso rápido

6. Devuelve la URL corta al cliente

Read Path:

1. Cliente solicita GET /{id}

2. Load Balancer → App Server

3. App Server busca en Redis

4. En miss, busca en BD y pobla cache 5. Responde con redirect 301 a la URL larga

Database Design

tablas:

• -- Tabla particionada por hashCREATE TABLE links ( id BIGSERIAL, url TEXT NOT NULL, shorten_url VARCHAR(7) UNIQUE NOT NULL, user_id BIGINT, created_at TIMESTAMP DEFAULT NOW()) PARTITION BY HASH (shorten_url);-- Crear 8 particionesCREATE TABLE links_p0 PARTITION OF links FOR VALUES WITH (MODULUS 8, REMAINDER 0);-- ... p1 a p7

Detailed Component Design

Cache Strategy: - Redis como capa de cache frente a la BD - Cache-aside pattern: buscar en Redis, si miss → BD → poblar Redis - TTL: 24 horas para URLs populares (evita bloat y refresca datos) - Política de evicción: LRU (más recientemente usados se quedan) - Enlinks virales: si un link recibe >1000 requests/min,se mantiene en cache con TTL extendido - Cache miss: se consulta BD por hash(short_code), se guarda en Redis, se responde redirect

ID Generation: - Base62 (a-z, A-Z, 0-9) → 7 chars = ~3.5 billones de combinaciones - Generación no secuencial para evitar enumeración - Si hay colisión por el índice UNIQUE, se reintenta con otro ID

Partitioning: - Hash(short_code) % N → cada redirect cae en 1 shard - Cache + replicas para mitigar hotspots