Design an Event Capture System for GitHub Branch Operations

Design a system that captures events for branch operations on GitHub: whenever a branch is created, deleted, or moved by a push, a force-push or a merge, the system records an event and makes it available to the consumers that need it. The report gives only the name of the problem, so which operations to capture, who consumes the events, and the scale and delivery guarantees are open: settle them with the interviewer before designing. ```hint One place every change passes Think about where every branch change ends up, whichever way it was made (a git push, a merge in the web interface, an API call), and what capturing it there guarantees. ``` ```hint The change and its record Ask what happens if a branch update succeeds but the process crashes before the event is recorded, and how a consumer would ever find out. ``` ### Clarifying Questions - Which operations count: creating and deleting branches, fast-forward pushes, force-pushes, merges made in the web interface, renames, changes to branch protection rules? - Who consumes the events, for example webhook deliveries to integrations, audit logs, CI triggers, notifications or activity feeds, and how fresh must each be? - Is losing an event ever acceptable? Must the events of one branch or one repository arrive in order? Can consumers tolerate duplicates? - What scale: how many repositories, how many pushes per second at peak, and how large can a single push be, given that one push can update many branches? - How long must events be kept, and must consumers be able to replay past events? ### What a Strong Answer Covers - Requirements and scale agreed first, including the operations, the consumers and the delivery guarantees - A capture point that sees every branch update, whatever the client path - Durable recording that cannot silently diverge from the real branch state, and a clear event schema (repository, branch, old and new commit, operation type, actor, time, identifier) - Ordering per branch or repository, at-least-once delivery with deduplication, and replay from a retained history - Fan-out to many consumers with isolation, so one slow webhook endpoint does not delay the others - Hot repositories, failure recovery, reconciliation and monitoring ### Follow-up Questions - A very active repository receives thousands of pushes an hour, and some single pushes update hundreds of branches. How do you keep it from overwhelming its partition? - An integration's webhook endpoint is down for six hours. What happens to its events, and what happens when it recovers? - How do you tell that a push was a force-push, and how is that reported in the event? - How would a consumer replay every branch event of one repository from the past week?