---
title: "RFC & System Design Critic Prompt: uncover scaling bottlenecks and dual-write bugs."
description: "Download the RFC & System Design Critic JSON preset for Vezz me. Highlight engineering design docs, ADRs, or protocol specs to uncover scaling bottlenecks and single points of failure."
canonical_url: "https://vezz.me/prompts/rfc-and-system-design-critic/"
type: "pseo-prompts"
category: "prompts"
topic: "Architecture Review Preset"
intent: "Best for Staff/Principal engineers, tech leads, SREs, and candidates preparing for distributed systems design reviews."
---

# RFC & System Design Critic Prompt: uncover scaling bottlenecks and dual-write bugs.

Download the RFC & System Design Critic JSON preset for Vezz me. Highlight engineering design docs, ADRs, or protocol specs to uncover scaling bottlenecks and single points of failure.

> **Best fit:** Best for Staff/Principal engineers, tech leads, SREs, and candidates preparing for distributed systems design reviews.

## Live Webpage Walkthrough

- **Source:** Internal Engineering RFC — Subscription Tier Upgrade Flow (`notion.so/eng-rfcs/billing-upgrade-architecture`)
- **Recommended Context Mode:** Detailed

**Highlighted Passage:**
> When a user upgrades their subscription plan, the Billing Service commits the new plan tier to PostgreSQL and immediately publishes a PlanUpdated event to Kafka and invalidates the user's Redis permissions cache key. If the Kafka publish fails, the HTTP handler returns a 500 error so the frontend can retry the upgrade.

**User Question (Shortcut):** "Stress-test this system design for partial failures, dual writes, and scaling bottlenecks."

**Vezz me On-Screen Answer:**
1. **Dual-Write Inconsistency Bug**: Committing to Postgres and *then* publishing to Kafka inside the request handler is not atomic. If Postgres commits and Kafka times out (or the pod crashes in between), the DB is upgraded, downstream Kafka consumers never learn about it, and returning `500` causes the client to retry.
2. **Cache Race Condition**: Deleting the Redis key can race with a concurrent read repopulating Redis from a lagging read replica.
3. **Constructive Fixes**:
   - Use the **Transactional Outbox Pattern** (write `subscriptions` + `outbox_events` in the same Postgres ACID transaction).
   - Require an `Idempotency-Key` header on the upgrade endpoint.

**Suggested Follow-Ups:**
- "How should we handle Redis cache invalidation from the Outbox relay worker?"
- "Write a polite, constructive RFC comment summarizing this dual-write issue."

## Custom Prompt Preset for Vezz me

- **Preset Name:** RFC & System Design Critic
- **Recommended Context Level:** Detailed
- **JSON Preset Download:** https://vezz.me/prompts/presets/rfc-and-system-design-critic.json

```text
Act as a constructive Staff Distributed Systems Engineer reviewing the selected RFC or system design proposal: 1) Failure Mode & Partial Outage Audit: what happens when a downstream dependency slows down 10x or drops 50% of requests? Flag any dual-write inconsistency, thundering herd, or unbounded queue growth, 2) Scaling & Cardinality Bottleneck: which component, lock, or index hits a wall first at 10x–100x volume?, 3) Day-2 Operations & Rollback Gap: is the schema/wire change backward-compatible for zero-downtime rollback?, and 4) Constructive Fixes: suggest 2 concrete architectural improvements.
```

**Why it works:** Systematically probes the 3 areas authors forget when writing happy-path design docs: partial downstream brownouts, dual-write atomicity, and rollback compatibility.

## Step-by-step workflow

1. **Download and import the RFC & System Design Critic JSON**: Save `rfc-and-system-design-critic.json` and import it into Vezz me.
2. **Highlight the data-flow or state-transition section of an RFC**: Select the proposed architecture section in Notion, Google Docs, Confluence, or GitHub.
3. **Address the dual-write, backpressure, and rollback findings**: Use the critique to harden your own proposal before review—or leave high-signal feedback on a teammate's doc.

## Pre-review your own RFC before the architecture review meeting

Catching a dual-write bug, a missing idempotency key, or an unsafe database migration takes 10 seconds with Vezz me—saving an hour of debate in a 12-person meeting.

- Checks for distributed transaction hazards: dual writes, missing outbox, non-idempotent retries, and split-brain locks
- Evaluates backpressure and load shedding: bounded queues, circuit breakers, jittered backoff, and tenant noisy-neighbor isolation
- Verifies expand-and-contract zero-downtime database migration safety

## Frequently asked questions

### Can I also use this preset when studying for System Design interviews?

Yes! Highlighting solutions in system design blogs or books and running this preset shows you the deep follow-up questions interviewers ask at Senior/Staff levels.

### Does it work on IETF RFCs and public protocol specs?

Yes—see our workflow guide on reading IETF RFCs and W3C specifications.

### Is my internal RFC private when using Vezz me?

Vezz me uses activeTab only—it never runs background scripts on your Google Docs or Notion workspace and only processes the specific passage you highlight and send.

## Related guides

- [Explain RFC & IETF Specifications Workflow](https://vezz.me/use-cases/explain-rfc-and-ietf-specifications/): How to parse normative protocol specifications in the browser.
- [Summarize Incident Postmortems & Status Pages](https://vezz.me/use-cases/summarize-incident-postmortems-and-status-pages/): Learn from real-world distributed systems outages.
- [Google Docs & Workspace Permission Audit](https://vezz.me/permissions/google-docs-and-workspace/): Why activeTab is essential when reviewing internal design docs.
- [Vezz me for Software Developers](https://vezz.me/for/software-developers/): Complete browser workflow for software engineers.