Design GitHub Code Hosting

Design a hosted Git collaboration platform with repository storage, push and fetch, branches, pull requests, review, permissions, and large-repository support.

Design a hosted Git collaboration platform with repository storage, push and fetch, branches, pull requests, review, permissions, and large-repository support. Use this guide to structure the discussion, test the design under pressure, and practise explaining trade-offs clearly.

Problem and Scope

Design a GitHub-like code-hosting platform. Users should be able to create repositories, push and fetch Git objects, manage branches, review and merge pull requests, and collaborate safely on repositories ranging from small projects to very large monorepos.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

Create public and private repositories with organization and collaborator permissions
Push, fetch, and clone Git objects and update branch or tag references
Browse files, commits, branches, diffs, and repository history
Open, review, update, and merge pull requests with protected-branch rules
Emit webhooks or events for downstream CI and integrations
Support large files and repositories without forcing every operation through one storage path

Non-functional requirements:

Never acknowledge a durable push and then lose its reachable Git objects or reference update
Keep repository metadata and common browse operations highly available and responsive
Scale object storage, pack generation, cloning, diff computation, and search independently
Enforce repository authorization consistently across Git and web/API protocols
Provide auditability, abuse controls, backup, disaster recovery, and repository restoration

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

Serve tens of millions of repositories and millions of active developers
Support repositories with millions of files, long histories, and multi-gigabyte object graphs
Expect bursty clone and fetch traffic after popular releases or CI fan-out
Treat writes to a single branch reference as ordered while allowing repository reads to scale broadly
Store immutable Git objects separately from mutable repository metadata and references

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

Git object model, content-addressable storage, pack files, and object reachability
Push negotiation, object upload, atomic reference updates, and concurrent writers
Repository metadata, permissions, organizations, branches, and protected rules
Pull-request diffs, comments, reviews, mergeability, and merge queues
Clone and fetch scaling, caching, replication, large files, and hot repositories
Durability, garbage collection, corruption detection, backup, security, and audit logs

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

How do you ensure a branch reference never points to Git objects that were not durably stored?
- Focus: Assess the ordering and atomicity between immutable object upload and mutable reference updates.
How would clone and fetch behave for a very large or suddenly popular repository?
- Focus: Assess pack generation, caching, replication, bandwidth, partial clone, and hot-repository mitigation.
Where would you compute pull-request diffs and mergeability, and how would updates invalidate them?
- Focus: Assess derived-data ownership, asynchronous computation, correctness, and invalidation on new commits.
How do protected branches and a merge queue handle many concurrent pull requests?
- Focus: Assess authorization, ordering, stale validation, CI integration, and race-free reference updates.
How would you garbage-collect unreachable objects without deleting data still needed by forks or in-flight pushes?
- Focus: Assess reachability, grace periods, shared-object ownership, repair, and operational safety.
What is your disaster-recovery story after metadata loss or object corruption?
- Focus: Assess backups, replication, integrity verification, recovery points, and repository restoration.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

Requirements and scope (15%): Clarifies and prioritizes the required behavior for Create public and private repositories with organization and collaborator permissions; Push, fetch, and clone Git objects and update branch or tag references; Browse files, commits, branches, diffs, and repository history. Establishes the constraints that materially affect Design GitHub Code Hosting, including Never acknowledge a durable push and then lose its reachable Git objects or reference update; Keep repository metadata and common browse operations highly available and responsive. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Git object model, content-addressable storage, pack files, and object reachability; Push negotiation, object upload, atomic reference updates, and concurrent writers; Repository metadata, permissions, organizations, branches, and protected rules; Pull-request diffs, comments, reviews. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
Data and scaling (25%): Uses workload assumptions such as Serve tens of millions of repositories and millions of active developers; Support repositories with millions of files, long histories, and multi-gigabyte object graphs to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Git object model, content-addressable storage, pack files, and object reachability; Repository metadata, permissions, organizations, branches, and protected rules; Pull-request diffs, comments, reviews, mergeability, and merge queues. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Durability, garbage collection, corruption detection, backup, security, and audit logs; Never acknowledge a durable push and then lose its reachable Git objects or reference update; Keep repository metadata and common browse operations highly available and responsive. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Pull-request diffs, comments, reviews, mergeability, and merge queues; Clone and fetch scaling, caching, replication, large files, and hot repositories; Durability, garbage collection, corruption detection, backup, security, and audit logs. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.