¿Cómo almacenas 100M de eventos de log por día?

Question

IT Interview Practice · Accepted Answer

Construye un **pipeline append-only: agents → Kafka → almacenamiento por niveles (caliente en ClickHouse/ELK, frío en object storage)** con una política de retención que indexe los datos recientes y archive el resto de forma barata. 100M de eventos/día son ~1.200/seg de media (picos mucho más altos) y decenas-a-cientos de GB diarios — optimizas para escrituras baratas y coste de query acotado, no para semántica OLTP.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Pipeline de append

Los logs son write-once, nunca se actualizan — así que la ruta de ingesta es un **append**. Agents como **Fluent Bit / Vector** envían las líneas a **Kafka**, que bufferiza los bursts y desacopla los productores del almacenamiento. Si ClickHouse está caído por mantenimiento, los eventos se encolan en Kafka y hacen replay — no tiras logs. Escribe por lotes (miles de filas por insert) porque los inserts fila-a-fila destruyen el throughput en los columnar stores.

## Store caliente: indexa para búsqueda

Los logs recientes necesitan búsqueda rápida ("errores en la última hora para el servicio X"). **ClickHouse** (columnar, comprime 10x, escanea miles de millones de filas/seg) o el **stack ELK** (índice invertido de Elasticsearch) sirven esto. Particiona por día/servicio para que las queries poden a unas pocas particiones. Este nivel es caro por GB, así que mantenlo pequeño — solo los últimos 7–30 días.

## Store frío: object storage + tiering

Los logs más antiguos se mueven a **S3 como Parquet** — barato, duradero, consultable bajo demanda vía Athena/Trino. Una **política de lifecycle** transiciona S3 → Glacier → eliminación en tu límite de retención (p. ej. 1 año). Este *tiering* es la palanca de coste central: el almacenamiento caliente puede costar 50x el del archival.

## Perspectiva de la entrevista

Los entrevistadores sondean la **compensación índice-vs-coste**: indexar todo da gran búsqueda pero revienta el presupuesto; no indexar nada es barato pero no consultable. Bueno: "usa ELK." Excelente: haces tiering — indexa la porción caliente reciente, archiva el resto en frío — y nombras Kafka como el buffer que hace la ingesta resiliente a las caídas aguas abajo.

**Trampa común:** poner todos los logs en Elasticsearch para siempre. Es la opción más cara y su cluster se derrumba ante la cardinalidad/retención que no planificaste.

## Compensaciones y modos de fallo

- **Retención vs coste:** más retención = crecimiento lineal de almacenamiento; haz tiering agresivo.
- **Backpressure de Kafka:** si los consumers van con lag, el disco se llena — dimensiona la retención y monitorea el lag.
- **Explosión de cardinalidad:** los campos de alta cardinalidad (user_id) inflan los índices de ES; muestréalos o descártalos.
- **Coste de query sobre datos fríos:** Athena cobra por TB escaneado — particiona el Parquet por fecha/servicio para que los scans queden acotados.
- **Duplicados at-least-once:** haz dedup sobre un event id si los conteos exactos importan.

Pipeline de append

Store caliente: indexa para búsqueda

Store frío: object storage + tiering

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas