# Design a distributed build system like Bazel Remote: system design interview question

> Remote build execution with dependent actions, reusable results, worker failures, and reproducibility under a declared execution contract.

Source: https://sysround.com/questions/design-distributed-build-system-like-bazel-remote
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a remote service that runs large software builds and reuses previous results. Builds contain dependent actions. The service must preserve reproducibility when build owners supply deterministic commands and complete input declarations."

## What to clarify first

- Scale
- Cache reuse and read-to-write ratio
- Action resources
- File volume
- Latency
- Build graph and client behavior
- Reproducibility
- Correctness, availability, and durability
- Retention and access
- Scope boundaries

## Scope of a strong answer

Core requirements:

- Accept a build graph and declared input files.
- Run dependent actions under the declared execution contract.
- Reuse successful action results across builds within a project.
- Track each build through success, failure, or cancellation.

Usually out of scope:

- Create the build graph from source code.
- Design compilers or package managers.
- Support interactive development sessions.
- Support platforms other than Linux x86-64.

## What interviewers probe

### Repeated build results

A compiler, environment value, or hidden input can change outputs without changing the source. Incorrect reuse can silently corrupt a build.

### Build progress

Large graphs expose parallel work, but each action needs complete inputs. Duplicate events or coordinator failures can release work too early.

### Worker failures

A worker can finish an action without reporting success. Replacement attempts can overlap, but the service needs one authoritative outcome.

### File storage and reuse

Reusable results depend on many files. Zone failures and deletion races threaten durability, while last-use retention prevents a fixed storage bound.

## Common mistakes

- The action key omits toolchains, environment values, or transitive inputs.
- The design assumes that containers make arbitrary commands reproducible.
- The coordinator releases dependents before their input files become durable.
- The design treats worker retries as exactly-once execution.
- The capacity estimate counts actions but ignores file transfer and worker memory.
- The design assumes that seven-day retention starts at creation, or acknowledges data before separate zones durably store it.

## The bar by level

- **Senior:** Explains reproducibility limits, durable dependency progress, and stale attempt rejection. Sizes workers and file traffic. Handles cancellation, incomplete results, last-use retention, and zone-safe acknowledgment.
- **Staff+:** Defines correctness boundaries across SQL, workers, and object storage. Resolves publication and deletion races. Proves acknowledged data survives zone failure. Evaluates fairness, trust, and storage growth without assuming a fixed retention window.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=distributed-build-system


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.