How the interviewer opens it
“Design a service that hosts Git repositories. Users must clone repositories, fetch changes, and push updates.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Protocol and repository access
- Repository count and size
- Operation volume and read:write mix
- Transfer sizes
- Latency
- Consistency and availability
- Durability and deployment
- Push behavior
- Object retention
- Identity and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create repositories and enforce repository access permissions
- Serve clone and fetch operations through Git over HTTPS
- Accept concurrent pushes without losing accepted updates
- Keep accepted repository data durable
Usually out of scope
- Pull requests and code review
- CI jobs
- Git LFS
- A web code viewer
- A new version control protocol
What interviewers ask about
- Concurrent branch updates
- Two valid pushes can start from the same branch tip. The service must preserve Git semantics without serializing entire transfers.
- When a push succeeds
- A ref can expose objects that storage has not made durable. Failover can also permit two workers to change one repository.
- Large clone and fetch requests
- Transfer counts hide large differences in bytes and CPU cost. Pack construction can overload a worker before network capacity runs out.
- Old objects and repository size
- Force pushes remove refs while readers still need old objects. Object cleanup also needs temporary space and competes with live traffic.
Common mistakes
- Treats a Git repository as one file and copies it for every operation.
- Uses last-writer-wins updates for branch refs.
- Reports push success before both objects and refs meet the durability requirement.
- Assumes an object store directly provides the filesystem behavior that standard Git tools need.
- Sizes the service from request counts without transfer sizes or pack construction costs.
- Removes unreachable objects without protecting old ref tips and active transfers.
The bar by level
- Senior (L5/E5)
- Defines push publication order and atomic multi-ref behavior. Handles force pushes, failed responses, failover, large transfers, and safe object removal.
- Staff (L6+/E6+)
- Defines enforceable ownership and storage guarantees. Compares storage designs and plans live repository moves. Controls maintenance cost while preserving consistency and latency.
Sources · 1 reference
These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.
SysRound · 1 record
No company association
Design a Git hosting service like GitHub
Reported date not specified
Source snapshot: Nov 12, 2026
View source