SYSTEM Cited by 3 sources
Bazel¶
Bazel (Google-originated, OSS) is a hermetic, content-addressed, multi-language build system designed for large monorepos. Key properties: declarative build graph; content-hash-based caching (concepts/content-addressed-caching); remote build execution (concepts/remote-build-execution); hermetic builds (concepts/hermetic-build) for reproducibility.
Stub page — expand on future Bazel-internals sources.
As a service-definition authoring surface¶
Beyond its primary role as a build system, Bazel's configuration language is a reasonable authoring surface for service definitions — Figma (2024) uses a per-service Bazel configuration file as the single source of truth from which CI generates Kubernetes YAMLs (see patterns/single-source-service-definition).
Seen in¶
- sources/2024-08-08-figma-migrated-onto-k8s-in-less-than-12-months — Bazel config as the single authoring surface for EKS service definitions; CI generates YAMLs from it.
- sources/2024-12-16-canva-faster-ci-builds — Bazel remote-cache adopted for local C++ builds (>2 min savings on cache hits); remote-build-execution context.
- sources/2025-11-06-slack-build-better-software-to-build-software-better — Slack's Quip/Canvas team adopts Bazel and reports that just adopting Bazel gave them nothing: their pre-existing build had cycles, non-hermetic action nodes, and cache keys with hundreds of transitively-inherited parameters, producing a zero cache hit rate. The real wins came from (1) rewriting Python build- orchestration into Starlark to sever the backend↔frontend coupling and (2) refactoring the frontend bundler to one-bundle-per-action so Bazel could schedule parallelism across the full graph. End result: 60 min → 10 min cached, ~6× speed-up. Canonical articulation that "Bazel's magic is contingent on the declared graph actually being a DAG of hermetic, idempotent actions."