Transaktionshistorie für hunderte Millionen Konten speichern & abfragen

Question

IT Interview Practice · Accepted Answer

**Partitioniere das Ledger nach Konto und Zeit, halte aktuelle Daten heiß und alte Daten kalt und behandle Rows als append-only, unveränderliches Ledger - sodass die Historie eines einzelnen Kontos eine kleine, indexierte Scheibe ist, niemals ein Scan über Milliarden Rows.** Das Zugriffsmuster ist immer "ein Konto, ein Datumsbereich", also partitioniere passend dazu.

## Architektur

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

## Wie es funktioniert

- **Partitioniere nach Konto + Zeit.** Hashe die Konto-ID in N Buckets, dann Range-Partition nach Monat. Eine Query für ein Konto/einen Monat trifft genau eine Partition - die DB beschneidet den Rest. Das begrenzt jeden Read unabhängig von der Gesamtgröße.
- **Unveränderliches Ledger.** `UPDATE` eine Transaktion nie; Korrekturen sind neue Storno-Rows. Das gibt einen Audit Trail, sichere Replikation und lässt dich aggressiv cachen (Rows ändern sich nie).
- **Hot/Cold-Tiering.** Halte die letzten ~3 Monate auf schneller SSD/Postgres für Reads mit niedriger Latency; rolle ältere Partitionen nach **S3/Parquet** (abgefragt über Athena/Trino) oder Glacier. 95% der Queries treffen aktuelle Daten, also kann der meiste Storage günstig sein.
- **Keyset Pagination.** Blättere mit `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` - nicht `OFFSET`. Offset scannt und verwirft übersprungene Rows; Keyset springt direkt in den Index, O(1) pro Seite.

## Interview-Perspektive

Der Interviewer sondiert die **Partition-Key-Wahl** und die **Pagination**. Gute Antworten sagen "nach Konto partitionieren"; hervorragende Antworten erklären, **warum Keyset OFFSET bei tiefen Seiten schlägt**, warum das **Ledger unveränderlich ist** (Auditierbarkeit, keine Lock-Contention) und wie **Tiering** Kosten senkt. Eine Falle ist eine einzelne riesige Tabelle mit einem zusammengesetzten Index - sie funktioniert, bis der Index nicht mehr in den RAM passt und jeder Read plattengebunden wird.

## Trade-offs & Fehler

- **Der Partition Key ist schwer zu ändern.** Wähle Konto+Zeit im Voraus; hunderte Millionen Rows später neu zu partitionieren ist ein Migrationsprojekt.
- **Cross-Account-Queries leiden.** "Gesamtvolumen über alle Konten" fächert nun über Partitionen aus - schiebe das stattdessen in einen OLAP-Rollup.
- **Cold Reads sind langsam.** Ein 3 Jahre altes Statement aus Glacier zu holen dauert Minuten; setze Nutzererwartungen oder wärme auf Anfrage vor.
- **Hot Partitions.** Ein Whale-Konto oder der aktuelle Monat kann ein Hotspot sein; sub-partitioniere oder cache es.
- **Wann nicht:** Millionen Rows (nicht hunderte Millionen) passen in eine indexierte Postgres-Tabelle - baue kein Tiering, das du nicht brauchst. Greife dazu bei dem Maßstab, wo der Index einer einzelnen Tabelle nicht mehr in den Speicher passt.

Architektur

Wie es funktioniert

Interview-Perspektive

Trade-offs & Fehler

Ähnliche Fragen