Cel nauki: rozróżnić diagnostyczny log aplikacji od dowodu wykonania operacji biznesowej i wybrać architekturę śladu audytowego.

Scenariusz edukacyjny

Fikcyjny system obsługuje zmianę rachunku do wypłaty. Użytkownik widzi potwierdzenie, ale po incydencie zespół ma tylko log HTTP 200. Nie wiadomo, kto zatwierdził zmianę, jaki był stan przed i po, ani czy wypłata użyła nowego rachunku. Kod odpowiedzi nie dowodzi wykonania ani autoryzacji operacji.

Trzy warianty

  1. Log aplikacyjny: tani i przydatny do diagnostyki, ale rotacja, redakcja pól i brak gwarancji kompletności osłabiają jego wartość dowodową.
  2. Zdarzenie audytowe w tej samej transakcji: zapis faktu biznesowego wraz ze zmianą stanu; zapewnia silniejszą spójność, lecz wymaga modelu danych i kontroli dostępu.
  3. Oddzielny strumień audytu: skaluje odbiór i retencję, ale asynchroniczna wysyłka bez outbox może zgubić zdarzenie. Nie wolno utożsamiać przyjęcia do kolejki z trwałym zapisem.

Decyzja architektoniczna

Dla operacji istotnych dowodowo wybierz niezmienny semantycznie rekord audytowy, zapisany atomowo ze zmianą stanu albo poprzez transactional outbox. Rejestruj identyfikator operacji, aktora i kontekst jego uwierzytelnienia, rodzaj działania, wynik, czas serwera, wersję obiektu i identyfikator korelacji. Ogranicz dane osobowe; wrażliwe wartości zastępuj identyfikatorami lub maskuj zgodnie z wymaganiami. Rozdziel uprawnienia do wykonywania operacji, odczytu audytu i zarządzania retencją. Kontroluj integralność, dostęp, synchronizację czasu i okres przechowywania; nie obiecuj pełnej niezmienności bez dowodów.

Pięć testów odbiorczych

  1. Po poprawnej zmianie stanu istnieje dokładnie jeden logiczny zapis audytu, mimo ponowień.
  2. Przy rollbacku nie pojawia się fałszywe zdarzenie „wykonano”.
  3. Awaria brokera nie gubi zdarzenia z transakcyjnego outbox; po wznowieniu następuje dostarczenie z deduplikacją.
  4. Osoba bez uprawnień nie może odczytać ani zmodyfikować historii, a próba jest monitorowana.
  5. Audyt pozwala odtworzyć kolejność decyzji i powiązać ją z operacją bez ujawniania nadmiarowych danych.

Pytanie do architekta: czy potrafisz wykazać nie tylko to, że API zwróciło sukces, lecz także kto i kiedy zmienił stan oraz jak potwierdzono trwałość zapisu?

Źródła pierwotne