Nyimpen & query riwayat transaksi kanggo atusan yuta akun

Question

IT Interview Practice · Accepted Answer

**Partisi ledger miturut akun lan wektu, jaga data anyar tetep panas lan data lawas adhem, lan anggep row minangka ledger append-only sing ora bisa diowahi — supaya riwayat siji akun dadi irisan cilik sing diindeks, ora tau scan milyaran row.** Pola akses tansah "siji akun, sawijining rentang tanggal", mula partisi supaya cocog karo kuwi.

## 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 kerjane

- **Partisi miturut akun + wektu.** Hash id akun dadi N bucket, banjur range-partisi miturut wulan. Query kanggo siji akun/wulan ndemek pas siji partisi — DB nyunati sisane. Iki mbatesi saben pamaca ora preduli total ukurane.
- **Ledger sing ora bisa diowahi (immutable).** Aja tau `UPDATE` transaksi; koreksi yaiku row pembalik anyar. Iki menehi jejak audit, replikasi aman, lan ngidini sampeyan cache kanthi agresif (row ora tau owah).
- **Tiering panas/adhem.** Jaga ~3 wulan pungkasan ing SSD/Postgres cepet kanggo pamaca latency endhek; puter partisi luwih lawas menyang **S3/Parquet** (di-query liwat Athena/Trino) utawa Glacier. 95% query ndemek data anyar, mula umume panyimpenan bisa murah.
- **Keyset pagination.** Kaca nganggo `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — dudu `OFFSET`. Offset nge-scan lan mbuwang row sing dilewati; keyset nyleweki indeks langsung, O(1) saben kaca.

## Sudut pandang wawancara

Pewawancara nyoba **pilihan partition-key** lan **pagination**. Jawaban apik ngucap "partisi miturut akun"; jawaban apik banget nerangake **kenapa keyset ngalahake OFFSET** ing kaca jero, kenapa **ledger ora bisa diowahi** (bisa diaudit, ora ana contention lock), lan kepiye **tiering** ngurangi biaya. Jebakane yaiku siji tabel gedhe kanthi composite index — iki mlaku nganti indekse ora muat maneh ing RAM lan saben pamaca dadi kaiket disk.

## Trade-off & kegagalan

- **Partition key angel diowahi.** Pilih akun+wektu ing ngarep; nge-partisi maneh atusan yuta row mengko iku proyek migrasi.
- **Query antar-akun rekasa.** "Total volume ing kabeh akun" saiki nyebar ing pirang-pirang partisi — dorong kuwi menyang OLAP rollup malah.
- **Pamaca adhem alon.** Njupuk laporan umur 3 taun saka Glacier butuh pirang-pirang menit; setel ekspektasi pangguna utawa pre-warm nalika dijaluk.
- **Hot partition.** Akun kakap utawa wulan saiki bisa dadi hotspot; sub-partisi utawa cache.
- **Nalika ora usah:** jutaan row (dudu atusan yuta) muat ing siji tabel Postgres sing diindeks — aja mbangun tiering sing ora bakal sampeyan butuhake. Njangkau iki ing skala nalika indeks siji tabel wis ora muat ing memori.

Arsitektur

Cara kerjane

Sudut pandang wawancara

Trade-off & kegagalan

Pitakon sing gegandhengan