Stocker et interroger l'historique des transactions pour des centaines de millions de comptes

Question

IT Interview Practice · Accepted Answer

**Partitionnez le grand livre par compte et par temps, gardez les données récentes hot et les anciennes cold, et traitez les lignes comme un grand livre append-only immuable — pour que l'historique d'un seul compte soit une petite tranche indexée, jamais un scan de milliards de lignes.** Le pattern d'accès est toujours « un compte, une plage de dates », donc partitionnez pour y correspondre.

## Architecture

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

## Comment ça fonctionne

- **Partitionner par compte + temps.** Hashez l'account id en N buckets, puis range-partitionnez par mois. Une requête pour un compte/mois touche exactement une partition — la DB élague le reste. Cela borne chaque lecture quelle que soit la taille totale.
- **Grand livre immuable.** Ne faites jamais `UPDATE` sur une transaction ; les corrections sont de nouvelles lignes de contre-passation. Cela donne une piste d'audit, une réplication sûre, et permet de cacher agressivement (les lignes ne changent jamais).
- **Tiering hot/cold.** Gardez les ~3 derniers mois sur SSD/Postgres rapide pour des lectures à faible latence ; faites rouler les partitions plus anciennes vers **S3/Parquet** (interrogé via Athena/Trino) ou Glacier. 95% des requêtes touchent les données récentes, donc la majeure partie du stockage peut être bon marché.
- **Pagination keyset.** Paginez avec `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — pas `OFFSET`. Offset scanne et jette les lignes sautées ; keyset seek directement l'index, O(1) par page.

## Perspective d'entretien

L'examinateur sonde le **choix de la partition key** et la **pagination**. Les bonnes réponses disent « partitionnez par compte » ; les excellentes expliquent **pourquoi keyset bat OFFSET** aux pages profondes, pourquoi le **grand livre est immuable** (auditabilité, pas de contention de verrous), et comment le **tiering** réduit les coûts. Un piège est une seule table géante avec un index composite — cela fonctionne jusqu'à ce que l'index ne tienne plus en RAM et que chaque lecture devienne disk-bound.

## Compromis et pannes

- **La partition key est difficile à changer.** Choisissez compte+temps dès le départ ; re-partitionner des centaines de millions de lignes plus tard est un projet de migration.
- **Les requêtes cross-account souffrent.** « Volume total sur tous les comptes » fait maintenant un fan-out sur les partitions — poussez celles-ci vers un rollup OLAP à la place.
- **Les lectures cold sont lentes.** Récupérer un relevé de 3 ans depuis Glacier prend des minutes ; ajustez les attentes des utilisateurs ou préchauffez à la demande.
- **Partitions chaudes.** Un compte baleine ou le mois courant peut être un hotspot ; sous-partitionnez ou cachez-le.
- **Quand ne pas le faire :** des millions de lignes (pas des centaines de millions) tiennent dans une seule table Postgres indexée — ne construisez pas un tiering dont vous n'aurez pas besoin. Recourez-y à l'échelle où l'index d'une seule table cesse de tenir en mémoire.

Architecture

Comment ça fonctionne

Perspective d'entretien

Compromis et pannes

Questions connexes