Architecture

BuildFetch Cluster(s) Topology

BuildFetch uses a Leader -> Many Follower clusters topology where one Leader coordinates many follower clusters across BuildFetch Cloud, Custom Cloud deployments, or On-premise Kubernetes installs.

Note: for Custom Deployments there is no need for multiple Kubernetes clusters!

BuildFetch supports deployments with Leader and Follower running in a single Kubernetes cluster.

             ╔═══════════════ BuildFetch Cluster US West A ══╗
             ║  ╔══ CAS [1] ══════════════════════════════╗  ║
╔════════╗   ║  ║  ╔══════════════╗   ╔═════════════════╗ ║  ║
║ Gradle  ──▶   ║  ║  NVMe Cache   ──▶  SSD Persistence ║ ║  ║
║  Builds ◀──   ║  ║ (µs latency)  ◀──   (ms latency)   ║ ║  ║
╚════════╝   ║  ║  ╚══════════════╝   ╚═════════════════╝ ║  ║
             ║  ╚═════════════════ | ↑ ═══════════════════╝  ║
             ║                   Active                      ║
             ║                 Replication                   ║
             ║  ╔══ CAS [N] ══════ ↓ | ═══════════════════╗  ║
╔════════╗   ║  ║  ╔══════════════╗   ╔═════════════════╗ ║  ║
║ Bazel   ──▶   ║  ║  NVMe Cache   ──▶  SSD Persistence ║ ║  ║
║  Builds ◀──   ║  ║ (µs latency)  ◀──   (ms latency)   ║ ║  ║
╚════════╝   ║  ║  ╚══════════════╝   ╚═════════════════╝ ║  ║
             ║  ╚═════════════════════════════════════════╝  ║
             ╚═══════════════════════════════════════════════╝

Each BuildFetch Follower cluster synchronizes state with the Leader through eventually consistent, event-driven, and periodic pull-based synchronization.

Each Follower cluster consists of CAS shards with active replication.

Fault Tolerance

Follower clusters run in different geographical regions and sync project configurations with the Leader cluster. This topology is designed to be resilient to errors in individual clusters, so a failure in one Follower cluster does not imply a failure in another Follower cluster. BuildFetch Cache API requests can continue even when the website or API layer is unavailable.

See Systems Status for real-time external uptime monitoring.

Networking

BuildFetch clusters use bus-bar networking with round-robin DNS so many Kubernetes worker nodes can accept external traffic directly. The goal is fewer hops, better throughput, and more even network utilization as clusters grow.

BuildFetch clusters support HTTP/3. Some client software, including Gradle and Bazel, may fall back to HTTP/2 or HTTP/1 when required.

When Leader and Follower(s) are running across public internet, they communicate over secure mTLS interconnect.

Storage

Follower cluster CAS shards use NVMe (microsecond latency) drives for ephemeral storage and SSD (millisecond latency) for persistent storage. BuildFetch does not use S3 or other Object Storage solutions due to high latency and request-per-second throttling.

Data on both NVMe and SSD drives is encrypted with LUKS AES-256 or similar technologies depending on the environment.