Sla transactiehistorie op en query het voor honderden miljoenen accounts

Question

IT Interview Practice · Accepted Answer

**Partitioneer het grootboek op account en tijd, houd recente data hot en oude data cold, en behandel rows als een append-only immutable grootboek — zodat de historie van één account een kleine, geïndexeerde slice is, nooit een scan van miljarden rows.** Het toegangspatroon is altijd "één account, een datumbereik", dus partitioneer om daarbij te passen.

## Architectuur

```text
Write ─▶ Grootboektabel (append-only, immutable)
          partitioneer op (account_hash, maand)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  laatste 3 mnd       ouder
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset-pagineer ──▶ API (account+bereik)
```

## Hoe het werkt

- **Partitioneer op account + tijd.** Hash het account-id in N buckets, range-partitioneer daarna op maand. Een query voor één account/maand raakt precies één partitie — de DB snoeit de rest. Dit begrenst elke read ongeacht de totale grootte.
- **Immutable grootboek.** Doe nooit `UPDATE` op een transactie; correcties zijn nieuwe tegenboekende rows. Dit geeft een audittrail, veilige replicatie, en laat je agressief cachen (rows veranderen nooit).
- **Hot/cold tiering.** Houd de laatste ~3 maanden op snelle SSD/Postgres voor lage-latency reads; rol oudere partities naar **S3/Parquet** (querybaar via Athena/Trino) of Glacier. 95% van de queries raakt recente data, dus het meeste opslag kan goedkoop zijn.
- **Keyset-paginatie.** Pagineer met `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — geen `OFFSET`. Offset scant en gooit overgeslagen rows weg; keyset seekt de index direct, O(1) per pagina.

## Interviewperspectief

De interviewer peilt **partition-key-keuze** en **paginatie**. Goede antwoorden zeggen "partitioneer op account"; uitstekende antwoorden leggen uit **waarom keyset OFFSET verslaat** bij diepe pagina's, waarom het **grootboek immutable is** (auditeerbaarheid, geen lock-contentie), en hoe **tiering** de kosten drukt. Een valkuil is één gigantische tabel met een composite index — het werkt tot de index niet meer in RAM past en elke read disk-gebonden wordt.

## Afwegingen & faalmodi

- **Partition key is moeilijk te wijzigen.** Kies account+tijd vooraf; honderden miljoenen rows later herpartitioneren is een migratieproject.
- **Cross-account queries lijden.** "Totaalvolume over alle accounts" waaiert nu uit over partities — duw die naar een OLAP-rollup.
- **Cold reads zijn traag.** Een 3 jaar oud afschrift uit Glacier halen duurt minuten; stel gebruikersverwachtingen of pre-warm op verzoek.
- **Hot partitions.** Een whale-account of de huidige maand kan een hotspot zijn; sub-partitioneer of cache het.
- **Wanneer niet:** miljoenen rows (niet honderden miljoenen) passen in één geïndexeerde Postgres-tabel — bouw geen tiering die je niet nodig hebt. Grijp hiernaar op de schaal waar de index van één tabel niet meer in geheugen past.

Architectuur

Hoe het werkt

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen