Kepiye sampeyan ngrancang audit log kanggo pelacakan pirang-pirang taun?

Question

IT Interview Practice · Accepted Answer

Gawe **append-only lan ora bisa diowahi (immutable)**, rangkai saben entri karo sadurunge nganggo **hash** supaya rusak (tampering) bisa dideteksi, **partisi miturut wektu** supaya data lawas tuwa kanthi murah, lan arsip partisi sing wis disegel menyang **WORM object storage** (tulis-sepisan) kanthi kebijakan retensi — aja tau ngidini `UPDATE`/`DELETE` marang cathetan langsung.

```text
service ──emit event──▶ append-only writer
                             │  hash = H(prev_hash || payload)
                             ▼
                     audit_2026_07 (hot partition)  ◀── query by actor/time
                             │ month sealed
                             ▼
                     WORM object store (S3 Object Lock)  ── retention: 7y
                             │
                     periodic anchor: publish latest hash externally
```

## Append-only & bukti-tamper

Sakabehing nilai audit log yaiku sampeyan bisa **percaya mengko**, mula skema kudu nglarang mutasi. Wenehi app `INSERT` thok — ora ana `UPDATE`/`DELETE` — lan tegakake ing level role DB, dudu mung ing kode. Ing ndhuwure kuwi, bangun **hash chain**: saben row nyimpen `hash = SHA256(prev_hash || this_row)`. Owahi sembarang row historis lan saben hash sabanjure rusak, mula tampering *bisa dideteksi* sanajan dening wong sing duwe akses DB. Kanthi periodik **anchor** hash pungkasan menyang panggonan sing sampeyan ora kontrol (notaris, ledger umum, email sing ditandatangani) supaya sanajan admin sing nulis ulang kabeh chain ora bisa cocogake nilai sing di-anchor.

## Partisi wektu & retensi

Log pirang-pirang taun tuwuh tanpa wates, mula **partisi miturut wektu** (contone range partisi saben wulan). Manfaate: query nyaring miturut partisi, lan mensiunake data lawas yaiku metadata `DETACH`/`DROP PARTITION` — sanalika, dudu `DELETE` gedhe sing mbengkakake tabel. Partisi sing wis disegel pindhah menyang **WORM storage** — S3 Object Lock ing *compliance mode* kanthi fisik nyegah pambusakan nganti tanggal retensi, nyukupi regulasi kaya SOX/HIPAA. Jaga wulan anyar tetep panas ing Postgres kanggo query cepet; kabeh sing luwih lawas adhem ing object storage, di-query on demand.

## Sudut pandang wawancara

Sing diselidiki yaiku apa sampeyan ngerti yen "audit log" tegese **immutabilitas lan bisa dibuktekake**, dudu mung "tabel kanthi timestamp". Apik: tabel append-only. Apik banget: append-only *sing ditegakake role DB*, hash chain kanthi anchoring eksternal, partisi wektu kanggo retensi, WORM kanggo kepatuhan. Jebakan umum: nyimpen row audit ing tabel app sing padha lan bisa diowahi (bug utawa DBA jahat bisa nulis ulang sejarah kanthi sepi) — auditor bakal nolak.

## Trade-off & mode kegagalan

- **Hash chain nyerialake tulisan** — saben entri butuh hash sadurunge, mula rancangan naif bakal bottleneck. Batch entri utawa rangkai saben-shard lan kanthi periodik silang-tautan.
- **Panyimpenan tuwuh salawase**; tanpa partisi + tiering menyang object storage murah, biaya lan latency query njeblug.
- **WORM compliance mode ora bisa dibalik** — setelan retensi sing salah ngunci data (utawa nglilani kadaluwarsa) tanpa undo; uji ing governance mode dhisik.
- **Clock skew / event ora urut** ngrusak penalaran berbasis-wektu — cathet wektu event lan wektu ingesti loro-lorone, lan aja tau percaya jam klien kanggo urutan.

Append-only & bukti-tamper

Partisi wektu & retensi

Sudut pandang wawancara

Trade-off & mode kegagalan

Pitakon sing gegandhengan