Architecture | BuildFetch

Cluster 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.


             ╔═══════════════ 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 event-driven and 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.

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.

Storage

Follower cluster CAS shards use NVMe (µs latency) drives for ephemeral storage and SSD (ms latency) for persistent storage. BuildFetch does NOT use S3 due to high latency and req/s throttling. Data on both NVMe and SSD is encrypted with LUKS AES-256 or similar technologies.