इसे append-only और immutable बनाएं, हर entry को पिछली से एक hash से chain करें ताकि tampering detectable हो, time से partition करें ताकि पुराना data सस्ते में age out हो, और sealed partitions को WORM object storage (write-once) में एक retention policy के साथ archive करें — live records पर कभी / की अनुमति न दें।
UPDATEDELETEservice ──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
एक audit log का पूरा मूल्य यह है कि आप उस पर बाद में भरोसा कर सकें, इसलिए schema को mutation forbid करना चाहिए। app को केवल INSERT grant करें — कोई UPDATE/DELETE नहीं — और इसे DB role स्तर पर लागू करें, केवल code में नहीं। इसके ऊपर, एक hash chain बनाएं: हर row hash = SHA256(prev_hash || this_row) स्टोर करती है। किसी भी historical row को बदलें और हर बाद का hash टूट जाता है, इसलिए tampering detectable है भले ही किसी के पास DB access हो। समय-समय पर latest hash को कहीं anchor करें जिसे आप नियंत्रित नहीं करते (एक notary, एक public ledger, एक signed email) ताकि एक admin भी जो पूरी chain फिर से लिखता है anchored मान से match न कर सके।
Multi-year logs बिना सीमा बढ़ते हैं, इसलिए time से partition करें (जैसे monthly range partitions)। फ़ायदे: queries partition से filter करती हैं, और पुराना data retire करना एक metadata DETACH/DROP PARTITION है — तुरंत, एक विशाल DELETE नहीं जो table फुलाता है। Sealed partitions WORM storage में move होते हैं — S3 Object Lock compliance mode में retention date तक deletion को भौतिक रूप से रोकता है, SOX/HIPAA जैसे नियमों को संतुष्ट करता है। हाल के महीने तेज़ queries के लिए Postgres में hot रखें; उससे पुराना सब object storage में cold है, मांग पर query किया जाता है।
परख यह है कि क्या आप समझते हैं "audit log" का मतलब immutability और provability है, केवल "एक timestamp वाली table" नहीं। अच्छा: append-only table। बढ़िया: append-only DB role द्वारा लागू, external anchoring वाली hash chain, retention के लिए time partitioning, compliance के लिए WORM। आम जाल: audit rows को उसी mutable app table में स्टोर करना (एक bug या एक malicious DBA चुपचाप history फिर से लिख सकता है) — auditors इसे अस्वीकार करेंगे।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें