Distributed Lock Service  ·  View 12 of 26  ·  4 · Data

Audit Data Flow

Grant, release, expiry and force-release history, derived from the log's own revisions rather than written twice.

Editable source SVG draw.io All views
Commit Lock log every revision Capture Audit tailer checkpoint revision Compaction gap alarm, never skip Store Audit store ClickHouse · 90 d Retain Grant archive Parquet · 1 y Force-release archive object lock · 7 y Use Advisory risk report Cost attribution Investigation lag > window Audit Data Flow — Derived From the Log, Not Dual-Written Data store Application we own Risk / gap Security / platform failure / alternate Idempotent on (cluster ID, revision): a tailer restart replays, it never double counts. v 1.0 · owner Platform Architecture · date 2026-09

Decisions

  • The tailer watches each cluster from its last checkpointed revision and inserts in batches keyed by cluster ID and revision. Replays are idempotent, so RPO is the checkpoint interval, well inside 60 seconds.
  • Expiries are captured because they are committed revocations in the log. An audit trail written by the arbiter would miss every expiry, which is the event investigators most need.
  • Force-release archives sit under MinIO object lock in retention mode for seven years. Grant history goes to Parquet for one year.

The one failure to design for

  • If the tailer lags past etcd's compaction window, the revisions it needs are gone. It alarms at half the window and never skips: a gap is recorded as a gap with its revision range, not papered over.

Assumptions

  • etcd compacts hourly, keeping one hour of revisions. The tailer's normal lag is seconds.
  • Denied acquisitions and rate-limit rejections go to logs and metrics, not the audit store. They are operational signals, not grants.