Memorizza e interroga la cronologia delle transazioni per centinaia di milioni di conti

Question

IT Interview Practice · Accepted Answer

**Partiziona il ledger per conto e tempo, mantieni caldi i dati recenti e freddi quelli vecchi, e tratta le righe come un ledger append-only immutabile — così che la cronologia di un singolo conto sia una fetta piccola e indicizzata, mai uno scan di miliardi di righe.** Il pattern di accesso è sempre "un conto, un intervallo di date", quindi partiziona per assecondarlo.

## Architettura

```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)
```

## Come funziona

- **Partiziona per conto + tempo.** Fai hash dell'account id in N bucket, poi range-partition per mese. Una query per un conto/mese colpisce esattamente una partizione — il DB fa pruning del resto. Questo limita ogni lettura indipendentemente dalla dimensione totale.
- **Ledger immutabile.** Non fare mai `UPDATE` di una transazione; le correzioni sono nuove righe di storno. Questo dà un audit trail, replica sicura e ti permette di fare caching aggressivo (le righe non cambiano mai).
- **Tiering caldo/freddo.** Mantieni gli ultimi ~3 mesi su SSD/Postgres veloce per letture a bassa latenza; sposta le partizioni più vecchie su **S3/Parquet** (interrogate via Athena/Trino) o Glacier. Il 95% delle query colpisce i dati recenti, quindi la maggior parte dello storage può essere economico.
- **Keyset pagination.** Pagina con `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — non `OFFSET`. L'offset fa scan e scarta le righe saltate; il keyset cerca direttamente nell'index, O(1) per pagina.

## Prospettiva del colloquio

L'intervistatore sonda la **scelta della partition key** e la **paginazione**. Le buone risposte dicono "partiziona per conto"; le eccellenti spiegano **perché il keyset batte l'OFFSET** sulle pagine profonde, perché il **ledger è immutabile** (auditabilità, nessuna contesa sui lock), e come il **tiering** riduce il costo. Una trappola è un'unica tabella gigante con un index composito — funziona finché l'index non entra più in RAM e ogni lettura diventa disk-bound.

## Compromessi e modalità di guasto

- **La partition key è difficile da cambiare.** Scegli conto+tempo fin dall'inizio; ripartizionare centinaia di milioni di righe dopo è un progetto di migrazione.
- **Le query cross-account soffrono.** "Volume totale su tutti i conti" ora fa fan-out tra le partizioni — spingi quelle verso un rollup OLAP.
- **Le letture fredde sono lente.** Recuperare un estratto conto di 3 anni fa da Glacier richiede minuti; imposta le aspettative dell'utente o fai pre-warming su richiesta.
- **Partizioni calde.** Un conto whale o il mese corrente può essere un hotspot; sub-partiziona o mettilo in cache.
- **Quando non farlo:** milioni di righe (non centinaia di milioni) entrano in una singola tabella Postgres indicizzata — non costruire un tiering che non ti servirà. Ricorri a questo alla scala in cui l'index di una singola tabella smette di entrare in memoria.

Architettura

Come funziona

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate