ਤੁਸੀਂ ਸਾਲਾਂ ਦੀ traceability ਲਈ ਇੱਕ audit log ਕਿਵੇਂ design ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਇਸਨੂੰ **append-only ਅਤੇ immutable** ਬਣਾਓ, ਹਰ entry ਨੂੰ ਪਿਛਲੀ ਨਾਲ ਇੱਕ **hash** ਨਾਲ chain ਕਰੋ ਤਾਂ ਜੋ tampering detectable ਹੋਵੇ, **time ਨਾਲ partition ਕਰੋ** ਤਾਂ ਜੋ ਪੁਰਾਣੀ data ਸਸਤੇ ਵਿੱਚ ਪੁਰਾਣੀ ਹੋ ਜਾਵੇ, ਅਤੇ 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 ਦੀ ਪੂਰੀ ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸ ਉੱਤੇ **ਭਰੋਸਾ** ਕਰ ਸਕੋ, ਇਸ ਲਈ schema ਨੂੰ mutation ਵਰਜਣੀ ਚਾਹੀਦੀ ਹੈ। app ਨੂੰ ਸਿਰਫ਼ `INSERT` grant ਕਰੋ — ਕੋਈ `UPDATE`/`DELETE` ਨਹੀਂ — ਅਤੇ ਇਸਨੂੰ DB role level ਉੱਤੇ ਲਾਗੂ ਕਰੋ, ਸਿਰਫ਼ code ਵਿੱਚ ਨਹੀਂ। ਇਸ ਦੇ ਉੱਪਰ, ਇੱਕ **hash chain** ਬਣਾਓ: ਹਰ row `hash = SHA256(prev_hash || this_row)` store ਕਰਦੀ ਹੈ। ਕਿਸੇ ਵੀ historical row ਨੂੰ ਬਦਲੋ ਅਤੇ ਹਰ ਅਗਲਾ hash ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ tampering DB access ਵਾਲੇ ਕਿਸੇ ਬੰਦੇ ਲਈ ਵੀ *detectable* ਹੈ। Periodically ਤਾਜ਼ਾ hash ਨੂੰ ਓਥੇ **anchor** ਕਰੋ ਜਿਸਨੂੰ ਤੁਸੀਂ control ਨਹੀਂ ਕਰਦੇ (ਇੱਕ notary, ਇੱਕ public ledger, ਇੱਕ signed email) ਤਾਂ ਜੋ ਇੱਕ admin ਜੋ ਪੂਰੀ chain ਦੁਬਾਰਾ ਲਿਖ ਦੇਵੇ ਉਹ ਵੀ anchored value ਨਾਲ match ਨਾ ਕਰ ਸਕੇ।

## Time partitioning ਅਤੇ retention

Multi-year logs ਬਿਨਾਂ ਸੀਮਾ ਦੇ ਵਧਦੇ ਹਨ, ਇਸ ਲਈ **time ਨਾਲ partition ਕਰੋ** (ਜਿਵੇਂ monthly range partitions)। ਫ਼ਾਇਦੇ: queries partition ਅਨੁਸਾਰ filter ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਪੁਰਾਣੀ data ਨੂੰ ਸੇਵਾਮੁਕਤ ਕਰਨਾ ਇੱਕ metadata `DETACH`/`DROP PARTITION` ਹੈ — ਤੁਰੰਤ, ਇੱਕ ਵਿਸ਼ਾਲ `DELETE` ਨਹੀਂ ਜੋ table ਨੂੰ bloat ਕਰੇ। Sealed partitions **WORM storage** ਵੱਲ ਚਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ — *compliance mode* ਵਿੱਚ S3 Object Lock retention date ਤੱਕ deletion ਨੂੰ ਭੌਤਿਕ ਤੌਰ ਉੱਤੇ ਰੋਕਦਾ ਹੈ, SOX/HIPAA ਵਰਗੇ regulations ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਹਾਲੀਆ ਮਹੀਨੇ Postgres ਵਿੱਚ fast queries ਲਈ hot ਰੱਖੋ; ਬਾਕੀ ਸਭ ਪੁਰਾਣਾ object storage ਵਿੱਚ cold, on demand query ਹੁੰਦਾ ਹੈ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਪਰਖ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ "audit log" ਦਾ ਮਤਲਬ **immutability ਅਤੇ provability** ਹੈ, ਸਿਰਫ਼ "ਇੱਕ timestamp ਵਾਲੀ table" ਨਹੀਂ। ਵਧੀਆ: append-only table। ਸ਼ਾਨਦਾਰ: **DB role ਦੁਆਰਾ ਲਾਗੂ** append-only, external anchoring ਵਾਲੀ hash chain, retention ਲਈ time partitioning, compliance ਲਈ WORM। ਆਮ ਫੰਦਾ: audit rows ਨੂੰ ਓਹੀ mutable app table ਵਿੱਚ store ਕਰਨਾ (ਇੱਕ bug ਜਾਂ ਇੱਕ malicious DBA ਚੁੱਪ-ਚੁਪੀਤੇ history ਦੁਬਾਰਾ ਲਿਖ ਸਕਦਾ ਹੈ) — auditors ਇਸਨੂੰ ਰੱਦ ਕਰ ਦੇਣਗੇ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **Hash chain writes ਨੂੰ serialise ਕਰਦੀ ਹੈ** — ਹਰ entry ਨੂੰ ਪਿਛਲੇ hash ਦੀ ਲੋੜ ਹੈ, ਇਸ ਲਈ ਇੱਕ naive design bottleneck ਕਰਦਾ ਹੈ। entries ਨੂੰ batch ਕਰੋ ਜਾਂ per-shard chain ਕਰੋ ਅਤੇ periodically 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

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ