Crater-scale runs

[jleni]

How should Kache behave at larger scales, including Crater-scale runs, polyglot projects, real-world edge cases, and blob inclusion?

[jleni]

scaling up does not change kache's job, it just shows which part to tune. kache is really two systems, and keeping them separate is what lets it scale while staying correct.

• A strict action cache: a key fully describes a compile. If kache cannot capture every input, it runs the compiler directly instead of risking a wrong result.
• An adaptive storage system: admission, eviction, tiering, dedup. Its worst case is a miss or some wasted disk, never a bad build.

That split means the scaling work happens on the storage side, where it is safe to be aggressive, and the correctness guarantees never move.

Crater-scale runs

Huge runs where almost nothing repeats are a stress test for overhead, not for reuse, so they exercise the storage system. kache is built to stay correct and bounded here:

• Admission control so one-shot artifacts do not flood the store.
• Incremental garbage collection instead of whole-store scans.
• Negative caching of remote misses to keep the backend calm.
• Sharded indexes for lookup speed at high cardinality.

The point: even when the hit rate is naturally low, the cache stays correct, predictable, and bounded.

Polyglot projects

This is already a strength today, not a future plan:

• Rust and C/C++ share one cache and one content-addressed store right now.
• Hybrid projects benefit immediately: a -sys crate and its native C dependency are both cached.
• One store, separate per-language keys, so the languages dedup their bytes together while each stays correctly keyed.

Because cross-language edges key on real artifact content, a changed C header correctly invalidates the Rust crate that depends on it. The languages share storage without ever crossing wires.

Real-world edge cases

kache's rule is simple: never guess. When a build does something it cannot fully capture, it caches nothing and just runs the compiler, so a tricky build is slow at worst, never wrong. In practice:

• Cached safely: sources, headers, include_ targets, env vars read via env!, generated files reported by the compiler, compiler identity.
• Skipped on purpose: timestamped or random codegen and similar, where caching honestly would not hit anyway.
• Refused by design: build scripts or macros that read the network or ambient files, unless you declare those inputs explicitly.

This is also why kache is safe to share across a whole CI fleet: it would rather miss than serve a stale result.

Blob inclusion

Large embedded inputs (include_bytes!, include_str!, generated assets, vendored binaries) are tracked correctly without bloating the store:

• Keyed by content plus a stable path, so swapping or editing an asset changes the key.
• Hashes are memoized by file identity, so a big asset is not re-read every build.
• Compiled outputs live in the store; large source assets are not copied in wholesale.

The throughline

Correctness came first, with solid Rust and C/C++ hybrid support, on purpose. That foundation is exactly what makes the scaling work safe: the aggressive, heuristic parts (admission, tiering, smarter prefetch) all live on the storage side and can grow freely without ever touching the correctness guarantees.