Lagra & fråga transaktionshistorik för hundratals miljoner konton

Question

IT Interview Practice · Accepted Answer

**Partitionera huvudboken på konto och tid, håll färsk data het och gammal data kall, och behandla rader som en append-only oföränderlig huvudbok — så att ett enskilt kontos historik är ett litet, indexerat snitt, aldrig en scan av miljarder rader.** Åtkomstmönstret är alltid "ett konto, ett datumintervall", så partitionera för att matcha det.

## Arkitektur

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

## Så här fungerar det

- **Partitionera på konto + tid.** Hasha konto-id:t till N buckets, range-partitionera sedan på månad. En fråga för ett konto/månad träffar exakt en partition — DB:n beskär resten. Detta begränsar varje läsning oavsett total storlek.
- **Oföränderlig huvudbok.** `UPDATE` aldrig en transaktion; korrigeringar är nya reverserande rader. Detta ger ett revisionsspår, säker replikering, och låter dig cacha aggressivt (rader ändras aldrig).
- **Het/kall nivåindelning.** Håll de senaste ~3 månaderna på snabb SSD/Postgres för låglatensläsningar; rulla äldre partitioner till **S3/Parquet** (frågas via Athena/Trino) eller Glacier. 95% av frågorna träffar färsk data, så merparten av lagringen kan vara billig.
- **Keyset-paginering.** Sida med `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — inte `OFFSET`. Offset scannar och kastar överhoppade rader; keyset söker indexet direkt, O(1) per sida.

## Intervjuperspektiv

Intervjuaren undersöker **val av partitionsnyckel** och **paginering**. Bra svar säger "partitionera på konto"; utmärkta svar förklarar **varför keyset slår OFFSET** vid djupa sidor, varför **huvudboken är oföränderlig** (revisionsbarhet, ingen låscontention), och hur **nivåindelning** minskar kostnad. En fälla är en enda gigantisk tabell med ett sammansatt index — det fungerar tills indexet inte längre får plats i RAM och varje läsning blir diskbunden.

## Avvägningar & fel

- **Partitionsnyckeln är svår att ändra.** Välj konto+tid i förväg; att partitionera om hundratals miljoner rader senare är ett migrationsprojekt.
- **Cross-account-frågor lider.** "Total volym över alla konton" fan-outar nu över partitioner — skjut de till en OLAP-rollup istället.
- **Kalla läsningar är långsamma.** Att hämta ett 3 år gammalt kontoutdrag från Glacier tar minuter; sätt användarförväntningar eller förvärm på begäran.
- **Heta partitioner.** Ett val-konto eller den aktuella månaden kan vara en hotspot; sub-partitionera eller cacha den.
- **När inte:** miljontals rader (inte hundratals miljoner) får plats i en indexerad Postgres-tabell — bygg inte nivåindelning du inte behöver. Grip efter detta vid den skala där en enda tabells index slutar få plats i minnet.

Arkitektur

Så här fungerar det

Intervjuperspektiv

Avvägningar & fel

Relaterade frågor