Simpan & query histori transaksi untuk ratusan juta akun

Question

IT Interview Practice · Accepted Answer

**Partisi ledger berdasarkan akun dan waktu, jaga data terbaru panas dan data lama dingin, dan perlakukan baris sebagai append-only immutable ledger — sehingga histori satu akun adalah irisan kecil terindeks, tidak pernah scan miliaran baris.** Pola akses selalu "satu akun, satu rentang tanggal", jadi partisi agar cocok dengannya.

## Arsitektur

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

## Cara kerjanya

- **Partisi berdasarkan akun + waktu.** Hash account id ke N bucket, lalu range-partition berdasarkan bulan. Query untuk satu akun/bulan mengenai tepat satu partisi — DB memangkas sisanya. Ini membatasi setiap baca terlepas dari ukuran total.
- **Immutable ledger.** Jangan pernah `UPDATE` sebuah transaksi; koreksi adalah baris pembalik (reversing) yang baru. Ini memberi audit trail, replikasi aman, dan memungkinkan Anda mem-cache secara agresif (baris tidak pernah berubah).
- **Tiering panas/dingin.** Jaga ~3 bulan terakhir di SSD/Postgres cepat untuk baca latensi rendah; gulingkan partisi lebih tua ke **S3/Parquet** (di-query via Athena/Trino) atau Glacier. 95% query mengenai data terbaru, jadi sebagian besar storage bisa murah.
- **Keyset pagination.** Page dengan `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — bukan `OFFSET`. Offset men-scan dan membuang baris yang dilewati; keyset menelusuri index langsung, O(1) per halaman.

## Perspektif wawancara

Pewawancara menyelidiki **pemilihan partition key** dan **pagination**. Jawaban baik berkata "partisi berdasarkan akun"; jawaban hebat menjelaskan **mengapa keyset mengalahkan OFFSET** pada halaman dalam, mengapa **ledger immutable** (auditabilitas, tanpa lock contention), dan bagaimana **tiering** memangkas biaya. Jebakannya adalah satu tabel raksasa dengan composite index — ia bekerja sampai index tidak lagi muat di RAM dan setiap baca menjadi disk-bound.

## Trade-off & kegagalan

- **Partition key sulit diubah.** Pilih akun+waktu di awal; re-partisi ratusan juta baris kemudian adalah proyek migrasi.
- **Query lintas-akun menderita.** "Total volume di semua akun" kini fan-out antar partisi — dorong itu ke rollup OLAP.
- **Baca dingin lambat.** Mengambil statement 3 tahun dari Glacier butuh menit; atur ekspektasi pengguna atau pre-warm saat request.
- **Partisi panas.** Akun kakap atau bulan berjalan bisa menjadi hotspot; sub-partisi atau cache.
- **Kapan tidak perlu:** jutaan baris (bukan ratusan juta) muat dalam satu tabel Postgres terindeks — jangan bangun tiering yang tak Anda butuhkan. Raih ini pada skala di mana index satu tabel berhenti muat di memori.

Arsitektur

Cara kerjanya

Perspektif wawancara

Trade-off & kegagalan

Pertanyaan terkait