Basekick-Labs / Basekick-Labs/arc

Decision (non-action): audit logs intentionally stay per-node

Open
#455 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
677
Forks
53
Avg merge
9h 14m
Merged PRs (30d)
164

Description

Tracking decision, not work. Phase A ([#451](https://github.com/Basekick-Labs/arc/pull/451)) shipped cluster auth replication for `api_tokens`. RBAC follows in Phase A.1. SSO/OIDC/LDAP in Phase B.

**Audit logs are intentionally NOT in this roadmap.**

## Reasoning

1. **Volume.** Audit log entries fire on every authenticated API call. A multi-tenant Enterprise cluster sees thousands of audit rows per second. Replicating each one through Raft would dominate the Raft log size and saturate the apply pipeline.
2. **No consensus requirement.** Each node knows what it served. Cross-node consistency on "did this token successfully query measurement X on node Y at time T" doesn't make any operational decision flow correctly. Operators investigating an incident grep all nodes' audit logs, they don't query a single replicated table.
3. **Existing aggregation path.** Operators already ship audit logs to centralized log aggregation (Loki, Datadog, CloudWatch, etc.) via stdout/stderr. That's where cross-node correlation belongs.

## What would change this decision

A customer reports that they need a single SQL queryable audit table across the cluster AND can't satisfy that requirement via external log aggregation. None reported as of 2026-05-23.

## Filed as

A tracking issue for discoverability — anyone considering "should we replicate audit logs?" finds this and the reasoning, rather than re-discovering the trade-off.

Related: [Phase A memory note](memory/project_cluster_auth_phase_a.md).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.