Cache Architecture

GloriousFlywheel uses a multi-layer caching strategy for Nix derivations and Bazel actions. This page describes the intended architecture and current internal contract; where older implementation names existed, the current authority is the nix-cache service family on honey.

Architecture Diagram

Components

Data Flow

Nix Cache Push

1. nix build produces derivation in /nix/store
2. attic watch-store daemon streams new paths to Attic (incremental)
3. At build end, attic push sends final closure (belt-and-suspenders)
4. Attic chunks and compresses NARs
5. Chunks are stored in the S3-compatible storage plane, metadata in PostgreSQL

Bazel Cache Push/Pull

1. Bazel clients talk to grpc://bazel-cache.nix-cache.svc.cluster.local:9092 from shared runner lanes.
2. bazel-remote keeps a pod-local /data hot cache for fast repeated reads.
3. Misses and uploads are persisted through the bazel-cache bucket on the OpenEBS-backed attic-rustfs-openebs RustFS service.
4. The public fuzzy-dev HTTP cache hostname is not part of the current contract.

Nix Cache Pull

1. nix build checks substituters in order
2. Attic responds to /nix-cache-info and narinfo queries
3. Matching paths served from the S3-compatible storage plane via Attic API
4. Nix validates against trusted public keys

Bazel Cache

1. just cache-contract-strict proves the shared cache attachment contract
2. just bazel-build-cached passes the real endpoint to Bazel and checks remote cache for action results
3. Cache hits: download minimal outputs (--remote_download_minimal)
4. Cache misses: build locally, upload results async (--experimental_remote_cache_async)
5. Storage: the Bazel cache service’s configured backing store with bounded retention

Retention & Cleanup

Network Endpoints