# Design a CI platform like GitHub Actions: system design interview question

> A platform that executes untrusted code, respects job dependencies, and shares limited capacity fairly across repositories.

Source: https://sysround.com/questions/design-ci-platform-like-github-actions
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a continuous integration platform that runs tests and validation when developers push code. Jobs have dependencies and need isolated execution. The platform must share execution resources fairly across repositories."

## What to clarify first

- Triggers and dependencies
- Scale
- Job resources
- Fairness
- Isolation and secrets
- Read and write mix
- Latency
- Consistency and durability
- Retention and output
- Product boundaries

## Scope of a strong answer

Core requirements:

- Create a pipeline run for a code push at a fixed commit.
- Execute jobs after their required jobs succeed.
- Isolate each job and publish its status, logs, and artifacts.
- Share capacity fairly across repositories and support cancellation.

Usually out of scope:

- Host source repositories.
- Deploy applications.
- Implement a secrets service.
- Support multiple regions.

## What interviewers probe

### Which repository runs next

Repositories have different queue sizes and job sizes. New work must receive a fair share without stopping active jobs.

### Job results and dependencies

A worker can finish without reporting its result. Later events can conflict with a retry, a dependency decision, or cancellation.

### What a job can access

The platform deliberately executes untrusted code. A normal test command can attack credentials, other jobs, or the platform itself.

### Job output and downstream use

Job output greatly exceeds control traffic. Retries and partial uploads can expose the wrong artifacts to dependent jobs.

## Common mistakes

- Treats the platform as a queue without defining dependency or attempt states.
- Equates equal job counts with fair resource allocation.
- Assumes a lost worker has stopped execution.
- Uses container isolation without a threat model for hostile code.
- Promises exactly-once execution despite worker failures.
- Sends logs and artifacts through the scheduler or metadata database.

## The bar by level

- **Senior:** Separates jobs from attempts and handles stale results, cancellation races, and missed dispatch events. Accounts for reserved CPU in repository fairness. Defines hostile-code isolation, secret permissions, output limits, and recovery after worker failure.
- **Staff+:** Defines precise fairness, execution, and durability guarantees. Explains the limits of nonpreemptive allocation and repeated execution. Controls the damage from worker compromise and platform partitions. Uses estimates to justify scheduler simplicity, fleet limits, and separate output storage.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=continuous-integration


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