Architecture
Cluster Topology
BuildFetch uses Leader-Follower clusters topology where one Leader (BuildFetch Cloud, Custom Cloud Deployment or On-Premise Kubernetes deployment) controls many Follower clusters.
Each BuildFetch Follower cluster synchronizes its state with Leader via event and/or pull-based sync.
Each Follower cluster consists of CAS shards with active replication.
Fault Tolerance
Follower Clusters run in different geographical regions and sync project configurations with Leader cluster. This topology is designed to be resilient to errors in individual clusters, i.e., failure of Follower Cluster A does not mean failure of Follower Cluster B, and failure of Leader Cluster does not mean failure of Follower Clusters meaning your Cache API requests will work even if website/api is down.
Networking
BuildFetch Clusters use bus-bar networking through round-robin DNS where most of Kubernetes worker nodes accept external traffic directly fully utilizing network capabilities, providing minimum network hops & maximum throughput for the customers as the clusters grow.
BuildFetch Clusters fully support HTTP/3, however some client software like Gradle and Bazel might not support it fully and can fallback to HTTP/2 or HTTP/1.
Storage
Follower Clusters CAS shards use NVMe (µs latency) drives as ephemeral storage and SSD (ms latency) as persistent storage, we do NOT use S3 due to high latency and req/s limits. Data on both NVMe and SSD is encrypted with LUKS AES-256-XTS.