Skip to main content
MergeWatch runs as a fully serverless pipeline on AWS. A GitHub webhook triggers a chain of Lambda functions and model invocations that ends with review comments posted back to the pull request.

​
Component overview

ComponentTypeMemoryTimeoutRole
WebhookHandlerLambda (Node 20, ARM64)256 MB30sValidate HMAC, invoke ReviewAgent (async)
ReviewAgentLambda (Node 20, ARM64)1024 MB300sFetch diff, invoke agents, post results
API GatewayREST API—29sReceive webhook, proxy to Lambda
DynamoDBOn-demand tables——Installation config, review history
SSM Parameter StoreSecureString——Encrypted credentials

​
Architecture diagram

GitHub
  |
  | pull_request webhook (HMAC-signed)
  v
API Gateway (REST)
  |
  v
WebhookHandler Lambda
  |  Validates HMAC-SHA256 signature
  |  Parses event type
  |  Invokes ReviewAgent (InvocationType.Event — async, fire-and-forget)
  v
ReviewAgent Lambda
  |  Fetches diff via GitHub API (installation token)
  |  Fans out to agents via Promise.all()
  |
  +-- Security agent ------+
  +-- Logic agent ---------+---> Bedrock (parallel)
  +-- Style agent ---------+
  +-- Summary agent -------+
  |
  v
Orchestrator agent
  |  Deduplicates findings
  |  Ranks by severity + confidence
  |  Computes merge readiness score
  v
GitHub API
  |  Posts Check Run
  |  Posts inline review comments
  v
DynamoDB
  |  Writes review record (90-day TTL)

​
DynamoDB tables

Primary key: installationId (partition key)GSI: accountId-index on accountIdStores GitHub App installation records and per-repo settings. Each item represents one GitHub App installation and includes:
  • GitHub account/org information
  • List of enabled repositories
  • Per-repo configuration overrides (model, skip rules, custom instructions)
  • Installation status and timestamps
This table uses on-demand billing and has no TTL — installation records persist until the app is uninstalled.
Primary key: installationId#repoFullName (partition key), reviewId (sort key)GSI: createdAt-index on createdAtTTL: 90 days (automatically expires old review records)Stores all review records including:
  • Raw agent findings (security, logic, style, summary)
  • Orchestrator output (deduplicated findings, severity rankings)
  • Merge readiness score
  • Timing data (per-agent latency, total duration)
  • GitHub metadata (PR number, commit SHA, check run ID)

​
Concurrency model

WebhookHandler invokes ReviewAgent asynchronously via the AWS Lambda Invoke API (InvocationType.Event). There is no queue between the two functions, so there is no built-in per-PR serialization.
How it works in practice:
  • PR #1 in acme/api and PR #2 in acme/api trigger independent ReviewAgent invocations that run in parallel.
  • Two rapid pushes to PR #1 each trigger a separate ReviewAgent invocation. Both run concurrently — there is no queuing or ordering guarantee.
  • Each ReviewAgent invocation edits the same summary comment on the PR. If two invocations overlap, the last one to finish overwrites the summary (last write wins). Inline review comments are additive and are not affected by concurrency.

​
Latency breakdown

Typical end-to-end timing from webhook receipt to comments appearing on the PR:
StepDuration
GitHub → API Gateway<100ms
WebhookHandler Lambda200–500ms
ReviewAgent startup (cold)5–10s
GitHub diff fetch200–800ms
5x parallel Bedrock calls8–20s
Orchestrator3–8s
GitHub comment posting200–500ms
Total (warm)~15–35s
Total (cold start)~25–50s
Cold starts only affect the first invocation after a period of inactivity. Once the Lambda is warm, subsequent reviews skip the 5–10s startup penalty. Under steady load, most reviews complete in under 30 seconds.

​
Next steps

Deployment Models

Understand the differences between self-hosted, BYOC, and SaaS deployments.

SAM Template Reference

Explore the full SAM template parameters, resources, and outputs.