Basekick-Labs / Basekick-Labs/arc
Decision (non-action): audit logs intentionally stay per-node
- 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
Assessment
This issue has not been assessed yet.