Stochează și interoghează istoricul tranzacțiilor pentru sute de milioane de conturi

Question

IT Interview Practice · Accepted Answer

**Partiționează registrul (ledger) după cont și timp, ține datele recente hot și cele vechi cold, și tratează rândurile ca un ledger append-only imutabil — astfel încât istoricul unui singur cont să fie o felie mică, indexată, niciodată un scan de miliarde de rânduri.** Pattern-ul de acces este mereu "un cont, un interval de date", deci partiționează ca să se potrivească cu el.

## Arhitectură

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

## Cum funcționează

- **Partiționează după cont + timp.** Hash-uiește id-ul contului în N bucket-uri, apoi fă range-partition după lună. O interogare pentru un cont/lună lovește exact o partiție — DB-ul face pruning la rest. Asta delimitează fiecare citire indiferent de dimensiunea totală.
- **Ledger imutabil.** Nu face niciodată `UPDATE` la o tranzacție; corecțiile sunt rânduri noi de storno. Asta dă un audit trail, replicare sigură și permite caching agresiv (rândurile nu se schimbă niciodată).
- **Tiering hot/cold.** Ține ultimele ~3 luni pe SSD/Postgres rapid pentru citiri cu latență mică; rulează partițiile mai vechi către **S3/Parquet** (interogate prin Athena/Trino) sau Glacier. 95% dintre interogări lovesc date recente, deci majoritatea stocării poate fi ieftină.
- **Paginare keyset.** Paginează cu `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — nu `OFFSET`. Offset-ul scanează și aruncă rândurile sărite; keyset-ul caută direct în index, O(1) per pagină.

## Perspectiva de interviu

Intervievatorul sondează **alegerea cheii de partiție** și **paginarea**. Răspunsurile bune spun "partiționează după cont"; cele excelente explică **de ce keyset bate OFFSET** la pagini adânci, de ce **ledger-ul este imutabil** (auditabilitate, fără contenție de lock) și cum **tiering-ul** taie costul. O capcană este o singură tabelă gigantică cu un index compus — funcționează până când indexul nu mai încape în RAM și fiecare citire devine legată de disc.

## Compromisuri și eșecuri

- **Cheia de partiție este greu de schimbat.** Alege cont+timp din start; re-partiționarea a sute de milioane de rânduri mai târziu este un proiect de migrare.
- **Interogările cross-account suferă.** "Volumul total pe toate conturile" acum se distribuie (fans out) peste partiții — împinge-le către un rollup OLAP în schimb.
- **Citirile cold sunt lente.** Aducerea unui extras de acum 3 ani din Glacier durează minute; setează așteptările utilizatorului sau fă pre-warm la cerere.
- **Partiții fierbinți.** Un cont-balenă sau luna curentă pot fi un hotspot; fă sub-partition sau pune în cache.
- **Când nu:** milioane de rânduri (nu sute de milioane) încap într-o singură tabelă Postgres indexată — nu construi tiering de care nu vei avea nevoie. Apelează la asta la scara la care indexul unei singure tabele nu mai încape în memorie.

Arhitectură

Cum funcționează

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe