Distributed Systems / Build Infrastructure

ForgeGrid

ForgeGrid is a distributed build and action-execution platform. It turns deterministic commands into schedulable work, executes them across a worker pool, and safely reuses outputs through content-addressed storage.

  • Go
  • gRPC
  • PostgreSQL
  • MinIO
  • Prometheus

Measured Results

5.68×

One-to-eight-worker speedup on a 1,000-action CPU workload.

30.6%

Critical-path scheduling improvement over FIFO.

93.75%

Duplicate compute avoided across 16 identical builds.

95.7%

Reduction in remote content-store traffic.

96 ms

Median recovery from two simultaneous worker failures.

Why I built it

Build systems are a compact way to study difficult distributed systems problems: deterministic identity, shared storage, scheduling, duplicate work, stragglers, and partial failure all appear in one workflow.

The goal was not a CRUD dashboard around shell commands. ForgeGrid owns the lifecycle from digesting an action to assigning a lease, materializing inputs, accepting exactly one result, and making that result reusable by later clients.

System Diagram

ForgeGrid control plane, worker pool, metadata, and content-addressed storage

How an action runs

1

Identify the work

The client hashes the command, environment, input digests, dependencies, outputs, timeout, and execution platform.

2

Reuse or schedule

A cache hit returns immediately. A miss joins the priority queue, while identical in-flight requests share one operation.

3

Lease to a worker

Capacity-aware workers pull leases, materialize verified inputs, execute in disposable directories, and upload declared outputs.

4

Commit or recover

The first valid completion wins. Missed heartbeats requeue work, and fenced leases prevent late results from corrupting state.

Key engineering choices

Separate metadata from bytes

PostgreSQL owns result metadata while MinIO/S3 owns immutable blobs, allowing each workload to scale independently.

Make policy replaceable

FIFO, shortest-job, critical-path, locality, and fair-share policies share one scheduler interface and worker protocol.

Treat failure as normal

Heartbeats, lease fencing, retry limits, and first-result-wins commitment keep recovery explicit and testable.

Boundaries

The measured studies are single-host experiments. The scheduler is one process, execution sandboxes are not a hostile-code security boundary, and the current API is not Bazel Remote Execution compatible. Those limits keep the project’s claims aligned with what was actually exercised.

Hire me!

You still here?

It’s over

Karan Bhaskar