Uczyń go append-only i niezmiennym, powiąż każdy wpis z poprzednim hashem, aby manipulacja była wykrywalna, partycjonuj po czasie, aby stare dane tanio się przedawniały, i archiwizuj zapieczętowane partycje do magazynu WORM (write-once) z polityką retencji — nigdy nie pozwalaj na / na żywych rekordach.
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
Cała wartość audit logu polega na tym, że możesz mu ufać później, więc schemat musi zabraniać mutacji. Nadaj aplikacji tylko INSERT — bez UPDATE/DELETE — i egzekwuj to na poziomie roli DB, nie tylko w kodzie. Na tym zbuduj łańcuch hashy: każdy wiersz przechowuje hash = SHA256(prev_hash || this_row). Zmień dowolny historyczny wiersz, a każdy kolejny hash się złamie, więc manipulacja jest wykrywalna nawet przez kogoś z dostępem do DB. Okresowo zakotwicz (anchor) najnowszy hash gdzieś poza twoją kontrolą (notariusz, publiczny ledger, podpisany email), aby nawet admin przepisujący cały łańcuch nie mógł dopasować zakotwiczonej wartości.
Wieloletnie logi rosną bez ograniczeń, więc partycjonuj po czasie (np. miesięczne partycje zakresowe). Korzyści: zapytania filtrują po partycji, a wycofywanie starych danych to metadanowe DETACH/DROP PARTITION — natychmiastowe, a nie gigantyczny DELETE rozdmuchujący tabelę. Zapieczętowane partycje przenoszą się do magazynu WORM — S3 Object Lock w trybie compliance fizycznie uniemożliwia usunięcie do daty retencji, spełniając regulacje jak SOX/HIPAA. Trzymaj świeże miesiące na gorąco w Postgres dla szybkich zapytań; wszystko starsze na zimno w object storage, odpytywane na żądanie.
Sondą jest, czy rozumiesz, że „audit log" oznacza niezmienność i dowodliwość, a nie tylko „tabelę ze znacznikiem czasu". Dobrze: tabela append-only. Świetnie: append-only egzekwowane rolą DB, łańcuch hashy z zewnętrznym kotwiczeniem, partycjonowanie czasowe pod retencję, WORM pod zgodność. Częsta pułapka: przechowywanie wierszy audytu w tej samej mutowalnej tabeli aplikacji (błąd lub złośliwy DBA może cicho przepisać historię) — audytorzy to odrzucą.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj