Gem & forespørg transaktionshistorik for hundreder af millioner konti

Question

IT Interview Practice · Accepted Answer

**Partitionér ledgeren efter konto og tid, hold nylige data hot og gamle data cold, og behandl rows som en append-only immutable ledger — så en enkelt kontos historik er en lille, indekseret skive, aldrig en scan af milliarder af rows.** Access pattern'et er altid "én konto, et datointerval", så partitionér for at matche 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ådan virker det

- **Partitionér efter konto + tid.** Hash konto-id'et ind i N buckets, range-partitionér derefter efter måned. En forespørgsel for én konto/måned rammer nøjagtigt én partition — DB'en beskærer resten. Dette afgrænser hver read uanset total størrelse.
- **Immutable ledger.** `UPDATE` aldrig en transaction; korrektioner er nye modgående rows. Dette giver et audit trail, sikker replikering, og lader dig cache aggressivt (rows ændres aldrig).
- **Hot/cold tiering.** Hold de sidste ~3 måneder på hurtig SSD/Postgres til lav-latency-reads; roll ældre partitioner til **S3/Parquet** (forespurgt via Athena/Trino) eller Glacier. 95% af forespørgsler rammer nylige data, så det meste storage kan være billigt.
- **Keyset pagination.** Paginer med `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — ikke `OFFSET`. Offset scanner og kasserer oversprungne rows; keyset seeker index'et direkte, O(1) pr. side.

## Interview-perspektiv

Intervieweren undersøger **partition-key-valg** og **paginering**. Gode svar siger "partitionér efter konto"; fremragende svar forklarer, **hvorfor keyset slår OFFSET** ved dybe sider, hvorfor **ledgeren er immutable** (auditerbarhed, ingen lock-kontention), og hvordan **tiering** skærer omkostning. En fælde er en enkelt gigantisk tabel med et composite index — det virker, indtil index'et ikke længere passer i RAM, og hver read bliver disk-bundet.

## Trade-offs & fejl

- **Partition key er svær at ændre.** Vælg konto+tid på forhånd; at re-partitionere 100s af millioner rows senere er et migreringsprojekt.
- **Cross-account-forespørgsler lider.** "Total volumen over alle konti" fanner nu ud over partitioner — skub dem til en OLAP-rollup i stedet.
- **Cold reads er langsomme.** At hente et 3 år gammelt kontoudtog fra Glacier tager minutter; sæt brugerforventninger eller pre-warm on request.
- **Hot partitions.** En hval-konto eller den aktuelle måned kan være et hotspot; sub-partitionér eller cache det.
- **Hvornår ikke:** millioner af rows (ikke hundreder af millioner) passer i én indekseret Postgres-tabel — byg ikke tiering du ikke får brug for. Grib efter dette ved den skala, hvor en enkelt tabels index holder op med at passe i hukommelsen.

Arkitektur

Sådan virker det

Interview-perspektiv

Trade-offs & fejl

Relaterede spørgsmål