Bird
Raised Fist0

Design a Code Repository System - Diff, Branch, Merge, Pull Request

HLDhardInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway Layer

Receives Pull Request creation HTTP request

User submits PR with branch and commit references

Protocol:HTTP/REST
BeforeUser has local branch changes ready to submit
AfterPR request forwarded to Pull Request Service
Pull Request Service

Validates PR and requests merge conflict check

Pull Request Service calls Merge & Conflict Service

Protocol:gRPC
BeforePR metadata stored but merge status unknown
AfterMerge & Conflict Service invoked to compute diff
Merge & Conflict Service

Fetches commits and blobs for diff calculation

Requests commit data from Commit Service

Protocol:Internal RPC
BeforeNo diff or conflict info available
AfterDiff computed, conflicts detected or cleared
Commit Service (Git Backend)

Retrieves commit metadata and blob references

Reads commit history from Metadata Store and blobs from Blob Storage

Protocol:S3 API and Cassandra queries
BeforeCommit data not loaded for diff; Metadata Store queried for commit history
AfterCommit and blob data returned for diff calculation; Metadata Store returned commit metadata
Pull Request Service

Updates PR status with merge result

Marks PR as mergeable or conflicting

Protocol:gRPC response
BeforePR merge status pending
AfterPR status updated with mergeability
Notification Service

Sends notification about PR status to users

Pushes notification to subscribers

Protocol:Event Stream
BeforeNo notification sent for this PR update
AfterUsers notified of PR merge status
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   API Gateway Layer   │
└──────────┬────────────┘
           │ HTTP/REST
           ▼
┌───────────────────────────────┐
│   Pull Request Service         │
│  - Handles PR creation         │
└─────────────┬─────────────────┘
              │ gRPC
              ▼
┌───────────────────────────────┐
│   Merge & Conflict Service     │
│  - Runs diff and conflict check│
└─────────────┬─────────────────┘
              │ Internal RPC
              ▼
┌───────────────────────────────┐
│   Commit Service (Git Backend) │
│  - Stores commits, branches    │
└───────┬─────────────┬─────────┘
        │             │
        │             │ S3 API
        ▼             ▼
┌───────────────┐  ┌────────────────────────┐
│Metadata Store │  │ Blob Storage (S3/MinIO) │
│(Apache Cassandra)│  │ - Stores file blobs    │
└────────────────┘  └────────────────────────┘
        │
        │ Event Stream
        ▼
┌───────────────────────┐
│ Notification Service   │
│ - Sends PR notifications│
└───────────────────────┘
Design Rationale

This architecture diagram illustrates the flow of a Pull Request submission in a code repository system. The API Gateway Layer receives the user's HTTP request and routes it to the Pull Request Service, which manages PR lifecycle. The Pull Request Service calls the Merge & Conflict Service to compute diffs and detect conflicts by fetching commit metadata from the Commit Service. The Commit Service accesses commit history from the Metadata Store and file blobs from Blob Storage. After mergeability is determined, the Pull Request Service updates the PR status. Finally, the Notification Service sends updates to users. This vertical flow emphasizes separation of concerns and efficient data retrieval for merge operations.

Primary Focus

✓

Practice

(1/5)
1. A distributed database system needs to evenly distribute data across 100 shards and handle dynamic addition/removal of shards with minimal data movement. Which component is most appropriate to manage shard assignment?
easy
A. Use a modulo-based hash function on the primary key to assign shards directly
B. Implement consistent hashing with virtual nodes to map keys to shards
C. Assign shards based on a centralized lookup table updated on every shard change
D. Use range-based partitioning with fixed key ranges per shard

Solution

  1. Step 1: Understand shard assignment requirements

    Modulo hashing (Use a modulo-based hash function on the primary key to assign shards directly) causes massive remapping when shards change; centralized lookup (Assign shards based on a centralized lookup table updated on every shard change) creates a bottleneck and single point of failure; range partitioning (Use range-based partitioning with fixed key ranges per shard) can cause hotspots and uneven load.

  2. Step 2: Evaluate consistent hashing benefits

    Consistent hashing with virtual nodes (Implement consistent hashing with virtual nodes to map keys to shards) evenly distributes keys and minimizes remapping when shards are added or removed, making it ideal for dynamic shard management.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Consistent hashing minimizes shard remapping on topology changes [check]
Hint: Consistent hashing minimizes data movement on shard changes [OK]
Common Mistakes:
2. In a composite index on columns (A, B), a query filters only on column B. At step 3 in the query execution plan, the database engine uses the composite index. What is the state of index usage at this step?
easy
A. The composite index cannot be used efficiently because column A is not filtered, causing a full index scan
B. The composite index is fully used to seek on column B alone efficiently
C. The database ignores the composite index and uses a table scan instead
D. The composite index is partially used by scanning leaf nodes but with poor performance

Solution

  1. Step 1: Understand composite index column order

    Composite indexes are ordered by the first column (A), then second (B). Queries filtering only on B cannot efficiently seek the index without filtering on A.

  2. Step 2: Analyze index usage at step 3

    Since column A is not filtered, the engine must scan the entire index or large portions, resulting in a full index scan rather than an efficient seek.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Composite index requires leading column filter for efficient seeks [check]
Hint: Composite index needs leading column filter for seeks [check]
Common Mistakes:
3. A deployment system must ensure zero downtime during releases by switching traffic instantly between two identical environments. Which deployment strategy best fits this requirement?
easy
A. Rolling deployment updating servers one by one
B. Canary deployment with gradual traffic shifting to new version
C. Feature flags toggling new features on the same environment
D. Blue-Green deployment with instant switch of load balancer target

Solution

  1. Step 1: Identify zero downtime requirement

    Blue-Green deployment uses two identical environments and switches traffic instantly, ensuring zero downtime.

  2. Step 2: Eliminate other options

    Canary is gradual, not instant; Feature flags don't switch entire environments; Rolling updates cause partial downtime.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Blue-Green switches environments instantly for zero downtime [check]
Hint: Instant switch between identical environments is Blue-Green [OK]
Common Mistakes:
4. Without the message queue (Kafka), what exactly breaks when Alice sends a message to Bob in a distributed chat system?
medium
A. Messages are duplicated because no deduplication occurs
B. Alice's message is delivered instantly but out of order
C. Alice's send blocks until Bob's server responds; if Bob's server crashes, message is lost with no retry
D. Bob receives the message but cannot acknowledge receipt

Solution

  1. Step 1: Understand role of Kafka in message durability and ordering

    Without Kafka, no durable queue exists to buffer messages. Synchronous sends block (Alice's send blocks until Bob's server responds; if Bob's server crashes, message is lost with no retry) but blocking alone is not the only failure. Instant delivery out of order (Alice's message is delivered instantly but out of order) is unlikely without queue. Bob receiving but not acknowledging (Bob receives the message but cannot acknowledge receipt) is unrelated.

  2. Step 2: Identify duplication risk without queue deduplication and ordering guarantees

    Without Kafka, retries and network issues cause message duplication due to lack of idempotent storage.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No queue -> duplicates due to no deduplication [check]
Hint: No queue means no deduplication, causing duplicates [check]
Common Mistakes:
5. Without the distributed consensus mechanism in a NoSQL cluster, what exactly breaks during a network partition?
medium
A. Clients receive stale data but writes continue without errors
B. Writes may be lost or overwritten due to lack of coordination, causing data inconsistency
C. All read requests block until the partition heals
D. The cluster automatically switches to a relational database fallback

Solution

  1. Step 1: Understand distributed consensus role

    Consensus protocols ensure coordinated writes and consistency across nodes.

  2. Step 2: Trace failure without consensus during partition

    Without consensus, the cluster cannot safely coordinate writes and may fallback to a safe mode or external system.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No consensus -> fallback to relational DB (plausible in some designs) [check]
Hint: No consensus -> fallback to safe storage [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard