Almacena y consulta el historial de transacciones de cientos de millones de cuentas

Question

IT Interview Practice · Accepted Answer

**Particiona el ledger por cuenta y tiempo, mantén los datos recientes calientes y los antiguos fríos, y trata las filas como un ledger append-only inmutable — para que el historial de una única cuenta sea una porción pequeña e indexada, nunca un scan de miles de millones de filas.** El patrón de acceso es siempre "una cuenta, un rango de fechas", así que particiona para coincidir con él.

## Arquitectura

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## Cómo funciona

- **Particiona por cuenta + tiempo.** Hashea el id de cuenta en N buckets, luego particiona por rango por mes. Una query de una cuenta/mes golpea exactamente una partición — la DB poda el resto. Esto acota cada lectura sin importar el tamaño total.
- **Ledger inmutable.** Nunca hagas `UPDATE` de una transacción; las correcciones son nuevas filas de reverso. Esto da un audit trail, replicación segura, y te deja cachear agresivamente (las filas nunca cambian).
- **Tiering caliente/frío.** Mantén los últimos ~3 meses en SSD/Postgres rápido para lecturas de baja latencia; mueve las particiones más antiguas a **S3/Parquet** (consultado vía Athena/Trino) o Glacier. El 95% de las queries golpean datos recientes, así que la mayor parte del almacenamiento puede ser barato.
- **Keyset pagination.** Pagina con `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — no `OFFSET`. Offset escanea y descarta las filas saltadas; keyset busca el índice directamente, O(1) por página.

## Perspectiva de la entrevista

El entrevistador sondea la **elección de la partition key** y la **paginación**. Las buenas respuestas dicen "particiona por cuenta"; las excelentes explican **por qué keyset le gana a OFFSET** en páginas profundas, por qué el **ledger es inmutable** (auditabilidad, sin contención de locks), y cómo el **tiering** reduce el coste. Una trampa es una única tabla gigante con un índice compuesto — funciona hasta que el índice ya no cabe en RAM y cada lectura se vuelve disk-bound.

## Compensaciones y modos de fallo

- **La partition key es difícil de cambiar.** Elige cuenta+tiempo por adelantado; re-particionar cientos de millones de filas después es un proyecto de migración.
- **Las queries cross-account sufren.** "Volumen total entre todas las cuentas" ahora hace fan-out entre particiones — empújalas a un rollup OLAP en su lugar.
- **Las lecturas frías son lentas.** Recuperar un estado de cuenta de hace 3 años desde Glacier tarda minutos; ajusta las expectativas del usuario o haz pre-warm bajo demanda.
- **Particiones calientes.** Una cuenta ballena o el mes actual pueden ser un hotspot; sub-particiona o cachéala.
- **Cuándo no:** millones de filas (no cientos de millones) caben en una única tabla de Postgres indexada — no construyas tiering que no necesitarás. Recurre a esto a la escala en que el índice de una única tabla deja de caber en memoria.

Arquitectura

Cómo funciona

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas