Lagre og spør transaksjonshistorikk for hundrevis av millioner kontoer

Question

IT Interview Practice · Accepted Answer

**Partisjoner hovedboken på konto og tid, hold nylig data hot og gammel data cold, og behandle rader som en append-only immutabel hovedbok — slik at én kontos historikk er en liten, indeksert skive, aldri en scan av milliarder av rader.** Aksessmønsteret er alltid "én konto, et datointervall", så partisjoner for å matche det.

## Arkitektur

```text
Write ─▶ Ledger-tabell (append-only, immutabel)
          partisjoner på (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  siste 3 mnd         eldre
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (konto+range)
```

## Slik fungerer det

- **Partisjoner på konto + tid.** Hash konto-id-en inn i N bøtter, deretter range-partisjoner på måned. En spørring for én konto/måned treffer nøyaktig én partisjon — DB-en beskjærer resten. Dette avgrenser hver lesning uansett total størrelse.
- **Immutabel hovedbok.** Aldri `UPDATE` en transaksjon; korrigeringer er nye reverserende rader. Dette gir et audit-spor, trygg replikering, og lar deg cache aggressivt (rader endres aldri).
- **Hot/cold tiering.** Hold de siste ~3 månedene på rask SSD/Postgres for lav-latency-lesninger; rull eldre partisjoner til **S3/Parquet** (spurt via Athena/Trino) eller Glacier. 95% av spørringer treffer nylig data, så mesteparten av lagringen kan være billig.
- **Keyset pagination.** Paginer med `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — ikke `OFFSET`. Offset skanner og forkaster hoppede rader; keyset seeker indeksen direkte, O(1) per side.

## Intervjuperspektiv

Intervjueren undersøker **valg av partisjonsnøkkel** og **pagination**. Gode svar sier "partisjoner på konto"; utmerkede svar forklarer **hvorfor keyset slår OFFSET** ved dype sider, hvorfor **hovedboken er immutabel** (auditerbarhet, ingen lock-contention), og hvordan **tiering** kutter kostnad. En felle er én enkelt gigantisk tabell med en composite index — det fungerer til indeksen ikke lenger får plass i RAM og hver lesning blir disk-bundet.

## Avveininger og feil

- **Partisjonsnøkkel er vanskelig å endre.** Velg konto+tid på forhånd; å re-partisjonere hundrevis av millioner rader senere er et migreringsprosjekt.
- **Cross-account-spørringer lider.** "Totalt volum over alle kontoer" fan-out-er nå over partisjoner — skyv de til en OLAP rollup i stedet.
- **Cold-lesninger er trege.** Å hente en 3 år gammel kontoutskrift fra Glacier tar minutter; sett brukerforventninger eller pre-warm ved forespørsel.
- **Hot partisjoner.** En whale-konto eller inneværende måned kan være en hotspot; sub-partisjoner eller cache den.
- **Når ikke:** millioner av rader (ikke hundrevis av millioner) får plass i én indeksert Postgres-tabell — ikke bygg tiering du ikke trenger. Grip til dette i skalaen der en enkelt tabells indeks slutter å få plass i minnet.

Arkitektur

Slik fungerer det

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål