તમે વર્ષોની traceability માટે audit log કેવી રીતે ડિઝાઇન કરશો?

Question

IT Interview Practice · Accepted Answer

તેને **append-only અને immutable** બનાવો, દરેક entry ને પાછલી સાથે **hash** વડે chain કરો જેથી tampering detectable હોય, **time વડે partition** કરો જેથી જૂનું data સસ્તામાં age out થાય, અને sealed partitions ને retention policy સાથે **WORM object storage** (write-once) પર archive કરો — live records પર ક્યારેય `UPDATE`/`DELETE` ને મંજૂરી ન આપો.

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

audit log ની આખી value એ છે કે તમે **પછીથી તેના પર ભરોસો** કરી શકો, તેથી schema એ mutation ને પ્રતિબંધિત કરવું જ જોઈએ. app ને માત્ર `INSERT` grant કરો — `UPDATE`/`DELETE` નહીં — અને તેને માત્ર code માં નહીં, DB role level પર enforce કરો. તેની ઉપર, એક **hash chain** બનાવો: દરેક row `hash = SHA256(prev_hash || this_row)` સ્ટોર કરે છે. કોઈપણ historical row બદલો અને દરેક subsequent hash તૂટે છે, તેથી DB access ધરાવનાર દ્વારા પણ tampering *detectable* છે. સમયાંતરે latest hash ને તમે નિયંત્રિત ન કરો ત્યાં **anchor** કરો (એક notary, public ledger, signed email) જેથી આખી chain ફરી લખનાર admin પણ anchored value ને match ન કરી શકે.

## Time partitioning & retention

Multi-year logs bound વગર વધે છે, તેથી **time વડે partition** કરો (દા.ત. monthly range partitions). ફાયદા: queries partition વડે filter થાય, અને જૂનું data retire કરવું એ metadata `DETACH`/`DROP PARTITION` છે — instant, table ને bloat કરતું વિશાળ `DELETE` નહીં. Sealed partitions **WORM storage** પર move થાય છે — *compliance mode* માં S3 Object Lock retention date સુધી deletion ને physically અટકાવે છે, SOX/HIPAA જેવા regulations સંતોષે છે. ઝડપી queries માટે તાજેતરના months Postgres માં hot રાખો; બાકીનું બધું object storage માં cold, on demand queried.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Probe એ છે કે તમે સમજો છો કે "audit log" એટલે **immutability અને provability**, માત્ર "timestamp સાથે એક table" નહીં. Good: append-only table. Great: **DB role વડે enforced** append-only, external anchoring સાથે hash chain, retention માટે time partitioning, compliance માટે WORM. સામાન્ય trap: audit rows ને એ જ mutable app table માં સ્ટોર કરવા (bug કે malicious DBA ચૂપચાપ history ફરી લખી શકે) — auditors તેને નકારશે.

## Trade-offs અને failure modes

- **Hash chain writes ને serialise કરે છે** — દરેક entry ને પાછલો hash જોઈએ, તેથી naive design bottleneck કરે છે. entries batch કરો અથવા per-shard chain કરો અને સમયાંતરે cross-link કરો.
- **Storage હંમેશા વધે છે**; partitioning + સસ્તા object storage પર tiering વગર, cost અને query latency ફૂટે છે.
- **WORM compliance mode irreversible છે** — ખોટી retention setting data ને lock કરે (અથવા expire થવા દે) undo વગર; પહેલા governance mode માં test કરો.
- **Clock skew / out-of-order events** time-based reasoning corrupt કરે છે — event time અને ingest time બંને record કરો, અને ordering માટે ક્યારેય client clocks પર ભરોસો ન કરો.

Append-only & tamper-evidence

Time partitioning & retention

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો