← Back to all projects

TECHNICAL RFC MASTERY

In 1969, Steve Crocker wrote the first RFC (RFC 1) to document the host software for the ARPANET. What started as a humble request for feedback became the foundation of the modern internet. Today, Request for Comments (RFCs) or Design Docs are the primary tool used by companies like Amazon, Google, and Meta to scale engineering decision-making.

Learn Technical RFC Writing: From Zero to Architectural Alignment Master

Goal: Deeply understand the art and science of technical RFCs—not just as documents, but as strategic tools for architectural alignment, risk mitigation, and consensus building. By building these projects, you will learn to frame complex problems, evaluate rigorous trade-offs, anticipate edge cases, and drive engineering execution across team boundaries. You will move from writing “code-first” to “design-first,” becoming an engineer who can lead large-scale technical initiatives.

Why Technical RFCs Matter

In 1969, Steve Crocker wrote the first RFC (RFC 1) to document the host software for the ARPANET. What started as a humble request for feedback became the foundation of the modern internet. Today, “Request for Comments” (RFCs) or Design Docs are the primary tool used by companies like Amazon, Google, and Meta to scale engineering decision-making.

Without a strong RFC culture, teams suffer from:

  • Architectural Drift: Disconnected systems that don’t talk to each other.
  • Expensive Re-writes: Discovering a fatal flaw 80% into the implementation.
  • Siloed Knowledge: Only the original author understands why a decision was made.
  • Consensus Paralysis: Meetings that never end because the trade-offs weren’t mapped.

Mastering the RFC is mastering the Architecture of Thought.

The RFC Lifecycle

    Idea
      │
      ▼
┌───────────────┐
│ Problem Frame │  <-- Define the "Pain"
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Draft Design  │  <-- The "How" and "What Else"
└───────┬───────┘
        │
        ▼
┌───────────────┐      ┌─────────────────┐
│ Review Cycle  │ <───>│ Stakeholder Feedback │
└───────┬───────┘      └─────────────────┘
        │
        ▼
┌───────────────┐
│ Finalization  │  <-- Decided/Rejected/Deferred
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Implementation│  <-- Clean execution
└───────────────┘

Core Concept Analysis

1. Framing: The “Why” Before the “How”

Most RFCs fail because they dive into the solution before proving the problem exists. Framing is the art of establishing the context, the business impact, and the constraints.

CONTEXT  ->  PROBLEM  ->  IMPACT  ->  CONSTRAINTS
(Where are we?) (What's broken?) (Why fix it?) (What limits us?)

2. Trade-off Analysis (The “What Else”)

Architecture is the stuff that’s hard to change later. A great RFC doesn’t just present “The Solution”; it presents “The Landscape.” It shows why other paths were rejected.

The Trade-off Triangle:

       Consistency
          /  \
         /    \
        /      \
Availability --- Partition Tolerance
      (The CAP Theorem Example)

3. Failure Mode Analysis

You must become your own worst critic. A senior RFC writer spends 30% of their time dreaming up ways the system will fail (network splits, database locks, human error, security breaches).

4. Stakeholder Mapping

Who needs to approve? Who needs to be informed?

  • Platform Team: Will this break our infra?
  • Security: Is this a data leak?
  • Product: Does this meet the deadline?
  • On-call: Will this wake me up at 3 AM?

Concept Summary Table

Concept Cluster What You Need to Internalize
Problem Definition You cannot solve a problem you haven’t accurately described. Root cause > Symptoms.
System Modeling Visualizing how data and control flow between components using diagrams.
Alternative Evaluation Every design choice has a cost. If you don’t know the cost, you don’t understand the design.
Operational Readiness Deployment, Monitoring, and Rollback are not “extras”; they are core features.
Consensus Building Managing feedback without losing the vision. Knowing when to compromise and when to “disagree and commit.”

Deep Dive Reading by Concept

Foundational Thinking

Concept Book & Chapter
Effective Communication The Pragmatic Programmer by Hunt & Thomas — Ch. 1: “A Pragmatic Philosophy” (Topic 4: Good Communication)
Architecture Logic Fundamentals of Software Architecture by Richards & Ford — Ch. 2: “Architectural Thinking”
Trade-off Analysis Designing Data-Intensive Applications by Martin Kleppmann — Ch. 1: “Reliability, Scalability, and Maintainability”

Detailed Design

Concept Book & Chapter
Stakeholders Software Systems Architecture by Rozanski & Woods — Ch. 9: “Identifying and Engaging Stakeholders”
Clean Design Clean Architecture by Robert C. Martin — Part V: “Architecture”
Failure Modes Release It! by Michael Nygard — Ch. 4: “Stability Antipatterns”

Project List

The following projects are designed to force you to grapple with different types of engineering challenges. For each project, your goal is to produce a Formal RFC Document (approx 1,500 - 3,000 words) that could be presented to a CTO or Architecture Review Board.

Project 1: The Monolith Decomposition (Architectural Shift)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English (Technical Writing)
  • Alternative Programming Languages: PlantUML, Mermaid.js (for diagrams)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 5. The Industry Disruptor
  • Difficulty: Level 3: Advanced
  • Knowledge Area: System Design / Microservices
  • Software or Tool: Markdown, Mermaid, LucidChart
  • Main Book: “Building Microservices” by Sam Newman

What you’ll build: A comprehensive RFC for breaking a mission-critical “Legacy Order Management Monolith” into a set of three domain-driven services (Orders, Inventory, Payments).

Why it teaches RFCs: This forces you to explain the “Why” (The pain of the monolith) and the “How” (The strategy for strangling the legacy system) without causing a business outage. You must address data consistency and cross-service communication.

Core challenges you’ll face:

  • Defining the Bounded Contexts → maps to Domain Driven Design
  • Data Migration Strategy → maps to The Strangler Fig Pattern
  • Handling Distributed Transactions → maps to The SAGA Pattern vs. 2PC

Key Concepts:

  • Bounded Context: “Domain-Driven Design” Ch. 14 - Eric Evans
  • Strangler Pattern: “Building Microservices” Ch. 5 - Sam Newman

Difficulty: Advanced Time estimate: 1 week Prerequisites: Understanding of REST APIs and relational databases.

Real World Outcome

A 10-page technical proposal that includes:

  1. Current State Diagram: The tangled mess of the monolith.
  2. Proposed Target State: Clean, isolated services.
  3. Migration Roadmap: Phase 1, 2, and 3 (with rollback points).
  4. Success Metrics: How we know it worked (e.g., “Deployment frequency increases by 40%”).

Example RFC Section (The Migration Plan):

### 4.2 Phase 1: The Read-Only Proxy
We will implement a Reverse Proxy (Nginx) in front of the Monolith.
The proxy will begin routing `GET /inventory` requests to the new Inventory Service
while shadowing the data to ensure parity.

**Verification:**
$ curl -I https://api.internal/v1/orders
# Should return X-Routed-To: legacy-monolith

The Core Question You’re Answering

“How do we move the airplane’s engines while it’s mid-flight without the passengers noticing?”

Before you write, sit with the fear of a system-wide outage. If your RFC doesn’t have a “Rollback Plan,” it isn’t an RFC; it’s a wish.

Concepts You Must Understand First

Stop and research these before writing:

  1. The CAP Theorem
    • Can we have Consistency and Availability during the split?
    • What happens if the Payment service is down but Orders is up?
    • Book Reference: “Designing Data-Intensive Applications” Ch. 9
  2. Database Per Service Pattern
    • Why shouldn’t microservices share a database?
    • How do we join data across services?
    • Book Reference: “Building Microservices” Ch. 4

Project 2: The Global Auth Overhaul (Security & Compliance)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: YAML (for OIDC Config)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The Service & Support Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Identity / Security / RFC 6749
  • Software or Tool: Auth0, Okta, or Keycloak (Conceptual)
  • Main Book: “Mastering FreeBSD and OpenBSD Security” (for security mindset)

What you’ll build: An RFC proposing the migration from “Homegrown Session Cookies” to a centralized “OIDC/OAuth2 Identity Provider” for a suite of 10 internal and external apps.

Why it teaches RFCs: Security RFCs require extreme precision. You must anticipate failure modes like “Token Theft,” “Replay Attacks,” and “Identity Provider Downtime.”

Core challenges you’ll face:

  • Backward Compatibility → How do users stay logged in during the switch?
  • Standard Compliance → Why choose OIDC over SAML or pure JWT?
  • User Experience → Addressing the “Too many redirects” problem.

Key Concepts:

  • JWT Structure: RFC 7519
  • OAuth Flows: “OAuth 2 in Action” - Justin Richer

Project 3: The Distributed Rate Limiter (Performance & Scale)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Go or Lua (for Redis scripts)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The Micro-SaaS
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Distributed Systems / Infrastructure
  • Software or Tool: Redis, Envoy, or Nginx
  • Main Book: “System Design Interview” by Alex Xu

What you’ll build: An RFC for a cross-cluster rate limiting service that protects an API from DDoS and “Thundering Herd” problems while maintaining < 5ms latency overhead.

Why it teaches RFCs: This is a classic “Performance vs. Consistency” trade-off. Do we use a central Redis? Do we use local caches with eventual consistency? Your RFC must justify the choice with numbers.

Core challenges you’ll face:

  • Algorithm Selection → Token Bucket vs. Leaky Bucket vs. Sliding Window.
  • Race Conditions → How do we prevent over-counting in a distributed cluster?
  • Failure Mode → If the Rate Limiter service dies, do we “fail open” (allow all) or “fail closed” (block all)?

Project 5: The Multi-Region Database Expansion (High Availability)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: SQL (DDL for partitioning)
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. The Industry Disruptor
  • Difficulty: Level 5: Master
  • Knowledge Area: Cloud Infra / Databases
  • Software or Tool: CockroachDB, Aurora Global, or Spanner
  • Main Book: “Operating Systems: Three Easy Pieces” (for concurrency concepts)

What you’ll build: An RFC proposing moving a US-East-1 database to a Global Multi-Region setup (US, EU, ASIA) to meet GDPR requirements and reduce latency for global users.

Why it teaches RFCs: This is the “Final Boss” of RFCs. You must address data sovereignty (GDPR), light-speed latency, and the risk of “Split Brain” scenarios.

Real World Outcome

A proposal for a globally distributed database that provides:

  1. Latency Heatmap: Show the reduction in ms for users in Tokyo and Berlin.
  2. Failover Protocol: What happens if us-east-1 goes offline?
  3. Data Residency Rules: How we ensure German data never leaves the EU.

Example RFC Section (The Quorum Logic):

To maintain consistency while allowing local reads, we will use a 3-region 
voting quorum. Writes must be acknowledged by 2 out of 3 regions.
- Leader: US-East
- Follower 1: EU-Central
- Follower 2: AP-Northeast

The Core Question You’re Answering

“How do we defy the speed of light to provide a local experience to a global audience?”

Concepts You Must Understand First

  1. Raft/Paxos Consensus
    • How do distributed nodes agree on the state?
  2. Geo-Partitioning
    • How does a database split data based on location?
  3. Eventual vs. Strong Consistency
    • When is it okay to be wrong for a few milliseconds?

Questions to Guide Your Design

  1. What is the cost of ‘Global Strong Consistency’?
    • How much will write latency increase if we wait for all regions?
  2. How do we handle ‘Stale Reads’?
    • Is it acceptable for a user in Japan to see a slightly old version of their profile?

Thinking Exercise

The Light-Speed Limit

Calculate the round-trip time (RTT) for light between New York and Singapore (approx 15,000 km).

  • If our database requires 3 round trips to commit a transaction, what is the minimum theoretical latency?
  • How does this affect our UX design?

The Interview Questions They’ll Ask

  1. “What is the CAP Theorem, and how does your global database design choose its two letters?”
  2. “How would you handle a network partition between the US and EU regions?”
  3. “Why would you choose CockroachDB over a traditional RDS with read replicas for this use case?”

Hints in Layers

Hint 1: Local vs. Global Categorize your data. Some data (like session tokens) needs to be global. Other data (like user-uploaded images) can be local.

Hint 2: Follower Reads Look into “Stale Follower Reads” to optimize performance in remote regions.

Hint 3: Regional Failover Design for the “Region Down” scenario. Does the system stay alive or become read-only?

Books That Will Help

Topic Book Chapter
Consistency “Designing Data-Intensive Applications” by Kleppmann Ch. 9
CAP Theorem “Cloud Architecture” (General resources) N/A

Project 6: Zero Trust Network Access (ZTNA) Transition

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: HCL (Terraform), Rego (OPA)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The Service & Support Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Networking / Security
  • Software or Tool: Cloudflare Access, Tailscale, or Pomerium
  • Main Book: “Zero Trust Networks” by Evan Gilman & Doug Barth

What you’ll build: An RFC proposing the removal of the corporate VPN in favor of a Zero Trust architecture where identity and device posture determine access to every internal resource.

Why it teaches RFCs: This is a high-friction change. You have to balance security (strict checks) with developer productivity (no annoying VPN logins). You must sell the “Trust nothing, verify everything” philosophy.

Real World Outcome

A proposal that results in:

  1. Network Topology Map: Before (Mantle/Perimeter) vs. After (Identity-aware).
  2. Access Policy Examples: User X on Managed Device Y can access Grafana.
  3. Migration Steps: How to move 500 employees without a “Locked out” disaster on Monday morning.

Example Output (Policy Logic):

# OPA Policy snippet for the RFC
default allow = false
allow {
    input.user.groups[_] == "engineering"
    input.device.is_encrypted == true
    input.location.country == "US"
}

The Core Question You’re Answering

“If our firewall is breached, why is our data still safe?”

Concepts You Must Understand First

  1. The Perimeter Security Model
    • What are the flaws of “Castle and Moat” security?
    • What is lateral movement?
  2. Mutual TLS (mTLS)
    • How do services verify each other’s identity?
  3. Identity-Aware Proxies (IAP)
    • How does a proxy sit in front of an app to handle auth?

Questions to Guide Your Design

  1. How do we handle legacy apps?
    • Some internal apps don’t support modern auth. How do we wrap them?
  2. What is our ‘Device Trust’ signal?
    • How do we know the laptop accessing the DB isn’t a random infected machine?

Thinking Exercise

The “Stolen Credential” Trace

Trace a request where a hacker has a developer’s password.

  • In a VPN world, what can they see?
  • In a ZTNA world, where are they stopped? (Device certificate? Geo-fencing? MFA?)

The Interview Questions They’ll Ask

  1. “Why is ZTNA better than a traditional VPN for a remote-first company?”
  2. “How do you handle ‘Emergency Access’ if the Identity Provider (e.g., Okta) goes down?”
  3. “Explain the role of mTLS in a Zero Trust environment.”

Hints in Layers

Hint 1: The Identity Provider Start by choosing a single source of truth for identity. Everything flows from there.

Hint 2: The Policy Enforcement Point (PEP) Research where the “Gatekeeper” sits. Is it on the load balancer? On the app itself?

Hint 3: Gradual Rollout Don’t suggest switching everything at once. Suggest a “Shadow Mode” where VPN and ZTNA coexist for a month.

Books That Will Help

Topic Book Chapter
ZT Philosophy “Zero Trust Networks” by Gilman & Barth Ch. 1-2
mTLS & Identity “Cloud Native Infrastructure” by Justin Garrison Ch. 7

Project 7: Standardized Observability Pipeline

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: JSON (Log formats), OpenTelemetry Config
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 4. The Open Core Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DevOps / Reliability
  • Software or Tool: Prometheus, Grafana, OpenTelemetry, ELK Stack
  • Main Book: “Site Reliability Engineering” by Niall Murphy et al.

What you’ll build: An RFC for a unified telemetry pipeline that collects Logs, Metrics, and Traces from 50 different microservices and routes them to a central dashboard with unified correlation IDs.

Why it teaches RFCs: This project is about Standards. You have to force developers to follow a specific logging format (Structured Logging). Your RFC must justify why the extra work for developers is worth the better debugging later.

Real World Outcome

  1. Standardized Log Schema: timestamp, level, trace_id, user_id, message.
  2. Service Level Objectives (SLOs): Defining what “Up” actually means for the business.
  3. Alerting Strategy: How to prevent “Alert Fatigue.”

Example RFC Section (The Correlation Trace):

When a user sees a 500 error:
1. User provides RequestID: `abc-123`
2. Search Logs for `abc-123` -> Reveals Database Timeout.
3. Open Trace for `abc-123` -> Reveals Service B waited 5s for Service C.
4. Check Metrics for Service C -> Reveals 100% CPU usage.
# This is the "Aha!" moment your RFC promises.

The Core Question You’re Answering

“How do we find the needle in a haystack of 1,000 services before the customer calls support?”

Project 8: Zero-Downtime Infrastructure Migration (Cloud-to-Cloud)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Terraform, Bash
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The Resume Gold
  • Difficulty: Level 4: Expert
  • Knowledge Area: Cloud Engineering
  • Software or Tool: AWS, GCP, Terraform
  • Main Book: “How Linux Works” (for networking fundamentals)

What you’ll build: An RFC for migrating a high-traffic production environment from AWS to Google Cloud Platform (or vice-versa) with zero user-perceivable downtime.

Why it teaches RFCs: This tests your ability to plan for the “Unthinkable.” You must document the “Dark Launch,” the data synchronization across clouds, and the final DNS “Cutover.”

Real World Outcome

A migration playbook that ensures:

  1. Cross-Cloud Connectivity: VPN or Direct Connect between AWS and GCP.
  2. Data Parity Report: How we verify that the Postgres in AWS matches the Cloud SQL in GCP.
  3. DNS Weighting Plan: Moving 1%, 10%, 50%, 100% of traffic.

The Core Question You’re Answering

“How do we swap the foundation of a skyscraper without the building shaking?”

Project 9: The Global Feature Flag System

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Go (Implementation), YAML (Config)
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 2. The Micro-SaaS
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Software Delivery
  • Software or Tool: LaunchDarkly (Conceptual) or Unleash
  • Main Book: “Accelerate” by Nicole Forsgren

What you’ll build: An RFC for an internal Feature Flag platform that allows Product Managers to toggle features for specific user segments (e.g., “10% of users in Brazil”) without a code deploy.

Why it teaches RFCs: You must address the Performance Overhead. If every if statement in the code requires a network call to the Flag Service, the app will be slow. Your RFC must solve for “Client-side Caching” and “Local Evaluation.”

Real World Outcome

A system design that enables:

  1. Instant Rollbacks: Turn off a buggy feature in < 500ms.
  2. A/B Testing: Serve different UI versions to different users based on IDs.
  3. SDK Usage: A clean if (flags.isEnabled("new_checkout")) pattern for devs.

Project 10: GraphQL Adoption Strategy

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: GraphQL SDL
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The Resume Gold
  • Difficulty: Level 3: Advanced
  • Knowledge Area: API Design
  • Software or Tool: Apollo Federation or Hasura
  • Main Book: “Design and Build Great Web APIs” by Mike Amundsen

What you’ll build: An RFC for wrapping 20+ legacy REST APIs in a single GraphQL Federated Gateway to solve the “Over-fetching” and “N+1 query” problems on the mobile app.

Why it teaches RFCs: GraphQL is controversial. Some devs hate it; some love it. Your RFC must objectively weigh the complexity of the “Gateway” against the productivity gains of the frontend.

Project 11: The Mono-repo Transition (Engineering Productivity)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Makefile, BUILD (Bazel)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The Resume Gold
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Developer Experience (DX)
  • Software or Tool: Bazel, NX, or Turborepo
  • Main Book: “Software Engineering at Google” by Titus Winters

What you’ll build: An RFC proposing the migration of 50 disparate GitHub repositories into a single “Mono-repo” to improve cross-team code sharing and dependency management.

Why it teaches RFCs: This is a pure “Workflow” RFC. You must address the technical hurdles (slow CI, giant git clones) and the cultural hurdles (Who owns the root folder? Who reviews what?).

Real World Outcome

  1. Build Speed Benchmarks: Showing how local caching reduces build times.
  2. Code Ownership Model: Using CODEOWNERS files to maintain service autonomy.
  3. CI/CD Pipeline Design: How to only build what changed.

Project 12: MLOps Infrastructure Strategy

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Python (Inference scripts), YAML (K8s)
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. The Industry Disruptor
  • Difficulty: Level 4: Expert
  • Knowledge Area: Machine Learning / Systems
  • Software or Tool: Kubeflow, BentoML, or SageMaker
  • Main Book: “AI Engineering” by Chip Huyen

What you’ll build: An RFC for a standardized pipeline to deploy, monitor, and retrain Machine Learning models across the company’s product lines.

Why it teaches RFCs: ML models are “Black Boxes.” Your RFC must explain how to handle “Model Drift,” “Data Versioning,” and the high cost of GPU inference.

Real World Outcome

A standardized MLOps blueprint including:

  1. The ‘Model Registry’ Flow: How a model moves from a Jupyter notebook to Production.
  2. Monitoring Dashboards: Visualizing “Prediction Drift” vs. “Ground Truth.”
  3. Cost Projection: How much the GPU inference will cost at 1k, 10k, and 100k requests/sec.

The Core Question You’re Answering

“How do we ensure our AI isn’t hallucinating or becoming obsolete in production?”

Project 13: Decentralized Identity (DID) Implementation

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: JSON-LD
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. The Industry Disruptor
  • Difficulty: Level 5: Master
  • Knowledge Area: Cryptography / Privacy
  • Software or Tool: ION (Bitcoin-based) or Polygon ID
  • Main Book: “Serious Cryptography” by Jean-Philippe Aumasson

What you’ll build: An RFC proposing the use of W3C Verifiable Credentials and Decentralized Identifiers (DIDs) to allow users to prove their identity without a central database storing their sensitive PII.

Why it teaches RFCs: This involves deep philosophical and technical shifts. You must explain why “Privacy by Design” is worth the complexity of cryptographic wallets and ledger-based lookups.

Real World Outcome

A privacy-first architecture that provides:

  1. Identity Sequence Diagram: How a user proves they are > 18 without revealing their birthdate.
  2. Wallet Integration Strategy: How users store their credentials.
  3. Revocation List Plan: How we handle lost or stolen identities.

The Core Question You’re Answering

“How can we trust a user’s data without ever seeing or storing it?”

Project 14: Modernizing Legacy Desktop Apps (Wasm/Electron)

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Rust (for Wasm), TypeScript
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The Service & Support Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: UI Architecture
  • Software or Tool: WebAssembly, Electron, or Tauri
  • Main Book: “Programming Rust” by Jim Blandy

What you’ll build: An RFC for porting a legacy C++ desktop application to the web using WebAssembly, ensuring the performance remains near-native while allowing instant updates.

Why it teaches RFCs: You must address the “Sandbox” constraints of the web. Your RFC must solve for “File System Access” and “Performance bottlenecks” in the browser.

Real World Outcome

  1. Performance Benchmarking: Comparative analysis of Native vs. Wasm execution.
  2. Offline Mode Design: How the app works when the internet is down (PWA).
  3. Bridging Plan: How Wasm talks to the JS DOM without overhead.

Project 15: The Chaos Engineering “Game Day” Protocol

  • File: TECHNICAL_RFC_MASTERY.md
  • Main Programming Language: English
  • Alternative Programming Languages: Bash, Python
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The Open Core Infrastructure
  • Difficulty: Level 4: Expert
  • Knowledge Area: Reliability Engineering
  • Software or Tool: Gremlin or Chaos Mesh
  • Main Book: “Chaos Engineering” by Casey Rosenthal

What you’ll build: An RFC establishing a formal practice of “Chaos Engineering,” including a proposal for the first “Game Day” where the team intentionally kills production servers to test resilience.

Why it teaches RFCs: This is a high-risk proposal. You have to convince the CEO that “Breaking things on purpose” is the only way to ensure they don’t break by accident during peak traffic.

Real World Outcome

  1. Blast Radius Analysis: How we ensure “Chaos” doesn’t affect real customers.
  2. Experiment Hypothesis: “If we kill the Primary Database, the Replica should take over in < 10s.”
  3. Incident Response Link: How Chaos Engineering integrates with the on-call rotation.

The Core Question You’re Answering

“If our system is truly resilient, why are we afraid to break it?”

```