Designing a Peer Review System

A peer review system coordinates code review workflows, ensuring quality gates before merging.

Pull Request Lifecycle

Developer opens PR
    ↓
Auto-assign reviewers
    ↓
CI checks run (tests, lint, security scan)
    ↓
Code review (comments, suggestions)
    ↓
Revisions submitted
    ↓
Approvals collected (min 2 required)
    ↓
Merge (auto or manual)

Data Model

pull_requests(
  id, repo_id, author_id,
  title, description,
  base_branch, head_branch,
  status,     -- open, in_review, approved, merged, closed
  created_at, merged_at
)

reviews(
  id, pr_id, reviewer_id,
  state,      -- approved, changes_requested, commented
  body,
  submitted_at
)

comments(
  id, pr_id, review_id,
  file_path, line_number,
  body, resolved, created_at
)

ci_checks(
  id, pr_id,
  check_name,
  status,   -- pending, running, passed, failed
  url
)

Reviewer Assignment

Auto-assignment strategies:

1. Code Ownership (CODEOWNERS file):
   /src/payments/ → @payment-team
   /infra/        → @devops-team

2. Round-Robin: Distribute evenly among team

3. Expertise-based: Analyze past reviews on same files

4. Load-based: Assign to reviewer with fewest open reviews

Merge Policies

protection_rules:
  required_approvals: 2
  dismiss_stale_reviews: true
  require_code_owner_review: true
  required_status_checks:
    - ci/unit-tests
    - ci/integration-tests
    - security/sast
  restrict_merge_to: ["@senior-engineers"]

Real-Time Collaboration

WebSocket connections for:
  - Live comment notifications
  - Review status updates
  - CI check progress
  - Conflict detection

"Alice is reviewing this PR" presence indicator

Diff Generation

Git diff algorithm (Myers diff)
Side-by-side diff rendering
Syntax highlighting by file type
Collapse unchanged sections

Conclusion

PR systems are workflow engines with git integration, real-time collaboration, and configurable quality gates. Code ownership + required CI checks are the most impactful merge protection policies.