Arkitekturmønstre i Audit Log

Mønstre for å ta imot, lagre og hente autentiserings- og autorisasjonshendelser.

Audit Log skiller asynkron innlasting fra lagring og lesing av sikkerhetshendelser.

Købasert innlasting

Azure Functions leser hendelser fra køer og sender dem videre til Audit Log API-et. Produsentene trenger dermed ikke vente på databaselagringen.

Fordeler: løs kobling, utjevning av trafikktopper og mulighet for nye forsøk. Ulemper: hendelser blir etter hvert konsistente, kan komme flere ganger og krever overvåking av feilkøer.

• AuthorizationEventsProcessor behandler autorisasjonshendelser.
• AuditLogClient videresender hendelser til API-et.

Separate hendelsesstrømmer over felles lag

Autentiserings- og autorisasjonshendelser har egne modeller, tjenester, repositories og controllere, men følger samme lagdeling.

Fordeler: domeneforskjeller blir eksplisitte og flytene kan utvikles separat. Ulemper: parallelle lag kan gi duplisert kode og ulik oppførsel.

• AuthenticationEventService håndterer autentiseringshendelser.
• AuthorizationEventRepository lagrer autorisasjonshendelser.

Tidsbasert databasepartisjonering

En bakgrunnstjeneste oppretter partisjoner, mens et eget repository kapsler inn databaseoperasjonene. Store hendelsestabeller deles etter tid.

Fordeler: mer forutsigbare spørringer og enklere livssyklusstyring. Ulemper: manglende partisjoner kan stoppe skriving, og opprydding må samordnes med krav til bevaring.

• PartitionCreationHostedService sørger for kommende partisjoner.
• PartitionManagerRepository utfører partisjonsoperasjonene.

Repository som lagringsgrense

Kjernetjenestene avhenger av repositorygrensesnitt og kjenner ikke PostgreSQL-detaljene.

Fordeler: forretningsflyten kan prøves uten database. Ulemper: et generisk lag kan skjule kostbare spørringer og databasespesifikk oppførsel.

• IAuthorizationEventRepository definerer lagringsgrensen.