System Design: GitHub

One beefy machine, bare git repositories on disk, nginx fronting git over HTTPS and sshd for git over SSH, users table for auth. This is literally how self-hosted git starts, and for a small org it is the right answer.

At ~200M repos averaging ~50 MB, you are staring at ~10 PB (dedupe helps — forks share objects) that cannot fit one machine and, more importantly, must never be lost. A dead disk here is not degraded service; it is someone's company history gone. Durability, not throughput, forces the first real architecture.

The fix is a fleet of storage servers, each repo living as three replicas on different hosts (Spokes/DGit-style). A push streams through the git front end to the primary replica and reaches quorum before the client sees success; reads are served by any replica. A routing layer maps repo → replica set, and rebalancing moves repos off hot or dying hosts.

Two flavors of bytes get split out: large binary assets (LFS, release artifacts) go to a blob store rather than bloating git object databases, and traffic is asymmetric — on the order of ~1M pushes/day but ~10M fetches/day (CI is most of it), so front ends autoscale on the fetch side and cache pack computations for hot repos.

Everything that is not git objects — repos, PRs, issues, reviews, permissions — lives in sharded SQL (sharded by repo/org so one hot monorepo cannot brown out a shard of strangers). The PR lifecycle is a state machine: opened → reviews requested → checks pending → approved → merged, with webhooks firing at each transition.

The senior talking point is the merge queue: on a busy repo, two green PRs can conflict semantically, so instead of merging directly, PRs enter a queue that creates speculative merge commits, runs CI against the combined result, and lands them in order — rolling back queue entries behind a failure. It converts 'merge then break main' into 'break the candidate, main stays green.'

Every push can trigger workflows — on the order of ~2M runs/day, wanting ~50K concurrent runners. A scheduler consumes webhook events, resolves workflow YAML, and dispatches jobs to runner pools of ephemeral VMs: created for one job, destroyed after, because runners execute arbitrary user code and must never be shared or reused across trust boundaries.

Secrets are injected at job start from an encrypted store, scoped per repo/environment, and never written to the (persisted, streamable) logs — which, with artifacts, land in the blob store. The queue also absorbs the thundering herd after an incident: backlogged workflows drain by priority instead of stampeding the scheduler.

Around ~100M notification events/day (~1.1K/s) fan out through a notification service to websocket sessions and email workers — classic async fan-out, nothing exotic, which is exactly why you mention it briefly and move on. Search over code and issues runs on separate indexes fed by the same event stream.

The security pipeline earns its own lane: secret scanning on every push (revoking leaked credentials with partner providers), a dependency graph powering vulnerability alerts, and code signing. Enterprise wraps it with SSO, org-wide policy enforcement, and exportable audit logs — the SOC2/GDPR/FedRAMP checklist that turns a developer tool into something procurement approves.