Si projektoni një audit log për vite gjurmueshmërie?

Question

IT Interview Practice · Accepted Answer

Bëjeni **append-only dhe të pandryshueshëm**, zinxhironi çdo hyrje me atë të mëparshmen me një **hash** që manipulimi të jetë i zbulueshëm, **partition sipas kohës** që të dhënat e vjetra të dalin lirë, dhe arkivoni partitions e vulosur te **WORM object storage** (write-once) me një retention policy — kurrë mos lejoni `UPDATE`/`DELETE` në regjistrat live.

```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 & tamper-evidence

E gjithë vlera e një audit log është që mund t'i **besoni më vonë**, kështu që skema duhet të ndalojë mutacionin. Jepni aplikacionit vetëm `INSERT` — pa `UPDATE`/`DELETE` — dhe zbatojeni në nivelin e DB role, jo vetëm në kod. Mbi këtë, ndërtoni një **hash chain**: çdo rresht ruan `hash = SHA256(prev_hash || this_row)`. Ndryshoni çdo rresht historik dhe çdo hash pasues thyhet, kështu që manipulimi është *i zbulueshëm* edhe nga dikush me akses DB. Periodikisht **anchor**-oni hash-in e fundit diku që nuk e kontrolloni (një notar, një ledger publik, një email i nënshkruar) që edhe një admin që rishkruan gjithë zinxhirin të mos përputhet me vlerën e anchor-uar.

## Partition sipas kohës & retention

Logs shumëvjeçarë rriten pa kufi, kështu që **partition sipas kohës** (p.sh. range partitions mujore). Përfitimet: query-t filtrojnë sipas partition, dhe tërheqja e të dhënave të vjetra është një metadata `DETACH`/`DROP PARTITION` — e menjëhershme, jo një `DELETE` gjigant që fryn tabelën. Partitions e vulosur lëvizin te **WORM storage** — S3 Object Lock në *compliance mode* fizikisht parandalon fshirjen deri në datën e retention, duke plotësuar rregullore si SOX/HIPAA. Mbani muajt e fundit të nxehtë në Postgres për query të shpejta; gjithçka më e vjetër është e ftohtë në object storage, e interroguar sipas kërkesës.

## Këndvështrimi i intervistës

Hetimi është nëse e kuptoni se "audit log" do të thotë **pandryshueshmëri dhe provueshmëri**, jo thjesht "një tabelë me një timestamp". Mirë: append-only table. E shkëlqyer: append-only *e zbatuar nga DB role*, hash chain me anchoring të jashtëm, partition sipas kohës për retention, WORM për compliance. Kurthi i zakonshëm: ruajtja e rreshtave të audit-it në të njëjtën tabelë të ndryshueshme aplikacioni (një bug ose një DBA keqdashës mund të rishkruajë heshturazi historinë) — auditorët do ta refuzojnë.

## Kompromiset & mënyrat e dështimit

- **Hash chain serializon shkrimet** — çdo hyrje ka nevojë për hash-in e mëparshëm, kështu që një dizajn naiv bëhet bottleneck. Batch-oni hyrjet ose zinxhironi për çdo shard dhe cross-link periodikisht.
- **Magazinimi rritet përgjithmonë**; pa partitioning + tiering te object storage i lirë, kosto dhe latency query shpërthejnë.
- **WORM compliance mode është i pakthyeshëm** — një cilësim i gabuar retention bllokon të dhënat (ose i lejon të skadojnë) pa undo; testoni në governance mode së pari.
- **Clock skew / event-e jashtë renditjes** korruptojnë arsyetimin e bazuar në kohë — regjistroni si event time ashtu edhe ingest time, dhe kurrë mos u besoni orëve të klientit për renditje.

Append-only & tamper-evidence

Partition sipas kohës & retention

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme