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
Follower Clusters use bus-bar networking through round-robin DNS fully utilizing network channel of each CAS shard providing minimum network hops and maximum throughput for the customers.
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.