Writing Technical RFCs: Indian Engineers Guide

You’re a software engineer at a fast-growing startup like Razorpay or Swiggy, and your team lead just asked you to draft an RFC for a major new feature. Your mind races—where do you even start? In India’s collaborative tech culture, where clear communication across teams in TCS, Infosys, or product companies is crucial, a well-written RFC can be the difference between a smooth launch and months of rework. It’s not just a document; it’s your blueprint for alignment, your tool for gathering critical feedback, and your ticket to becoming a more impactful engineer.

What is an RFC and Why Should You Care?

RFC, or Request for Comments, is a formal document that proposes a significant technical change, new system, or major feature. It outlines the what, why, and how before any code is written. Think of it as the architectural plan before constructing a building.

In the Indian tech ecosystem, where projects often involve large, distributed teams (think Wipro or HCL projects) or cross-functional squads in startups like Freshworks or Zomato, RFCs are invaluable. They move discussions from chaotic Slack threads to a structured, asynchronous format. This is critical for engineers who may be collaborating across time zones or with non-technical stakeholders in product and business roles. Writing a good RFC demonstrates ownership, foresight, and professional maturity—qualities that are highly valued during performance reviews and can directly influence your career growth and compensation.

The Core Structure of a Winning RFC

While formats can vary, most effective RFCs in companies like Flipkart or Paytm follow a similar skeleton. This structure ensures you cover all bases and make it easy for reviewers to digest.

1. Title and Metadata

Start with a clear, concise title (e.g., "RFC: Implementing a Real-Time Notification Service using WebSockets"). Include metadata like Author, Date, Status (Draft, In Review, Accepted), and a list of key stakeholders or reviewers from engineering, product, and DevOps.

2. Summary and Motivation

This is your elevator pitch. In 2-3 paragraphs, summarize the proposal and, most importantly, explain why it’s needed. Is it to reduce API latency for users in Tier-2 cities? To cut cloud costs on AWS or Azure? To solve a scaling problem before the next festival sale? Link to specific pain points, user stories, or business metrics.

3. Detailed Design Proposal

This is the heart of the document. Use diagrams (tools like Draw.io or Excalidraw are great), sequence flows, and pseudo-code to illustrate your solution.

• System Architecture: How do the new components fit with the existing ones?
• APIs and Data Models: Define new endpoints, request/response schemas, and database changes.
• Technology Choices: Justify your selection of a specific database, framework, or protocol. Why Kafka over RabbitMQ? Why PostgreSQL over MongoDB for this use case?

4. Alternatives Considered

Show you’ve done your homework. Briefly describe other approaches you evaluated and why you rejected them. This could include using a third-party service, a different architectural pattern, or a simpler hack. This section builds credibility and pre-empts the "have you thought about X?" questions.

5. Implementation Plan and Timeline

Break down the work into phases. This helps in planning and resource allocation, a practice common in Accenture or Infosys project plans.

1. Phase 1: Prototype and core backend service (Weeks 1-3).
2. Phase 2: Frontend integration and developer APIs (Weeks 4-5).
3. Phase 3: Testing, deployment, and monitoring rollout (Weeks 6-7).

6. Open Questions and Risks

No solution is perfect. Explicitly list known unknowns, potential bottlenecks, and risks. For example: "How will this perform under a 10x traffic spike?" or "This introduces a new single point of failure at component Y." This invites collaborative problem-solving.

Pro Tips from the Indian Tech Trenches

Writing for an Indian engineering audience requires specific nuance. Here’s how to make your RFC resonate.

• Assume Diverse Contexts: Your reviewers could be a fresher from an NPTEL course background, a principal engineer with 15 years of experience, and a product manager. Write clearly, avoid unnecessary jargon, and link to foundational concepts if needed.
• Embrace Asynchronous Review: Given different meeting schedules and time zones, craft your document to be self-sufficient. Use clear headings, bullet points, and visuals so someone can review it independently at 11 PM.
• Quantify Everything: Back your arguments with data. Instead of "improve performance," say "reduce p99 latency from 2s to 200ms for users in North India." Instead of "save costs," estimate "reduce monthly AWS RDS costs by ~₹1.5 lakh."
• Leverage Familiar Examples: When explaining a complex pattern, relate it to systems people know. "This is similar to how Ola handles surge pricing updates" or "We're adopting the gateway pattern, much like Razorpay's routing system."

Common Pitfalls to Avoid

Steer clear of these mistakes that can derail your RFC's success.

• The Solution Looking for a Problem: Don't start with the cool technology (e.g., "Let's use GraphQL"). Always lead with the user or business problem.
• The Monolithic Document: An RFC shouldn't be a 50-page thesis. If it's getting long, split it into a core RFC and separate, detailed annexes for specific subsystems.
• Ignoring Non-Functional Requirements (NFRs): For Indian users, NFRs like low data usage, offline capability, and cost efficiency are often as critical as features. Dedicate a section to NFRs: scalability, security, monitoring, and cost implications.
• Defensive Tone: An RFC is a request for comments, not a decree. Use phrases like "We propose" and "One potential approach is" to invite feedback. The goal is collective ownership, not winning an argument.

How to Run the RFC Review Process

Writing the document is only half the battle. Managing the review effectively is key.

1. Socialize Early: Before sending the formal draft, discuss the core idea with 1-2 senior engineers or your tech lead. This gets early buy-in and catches major flaws.
2. Share the Draft: Send the RFC link (using a tool like Google Docs, Confluence, or GitHub Discussions) to the identified stakeholders. Set a clear deadline for comments (e.g., "Please provide feedback by EOD Thursday").
3. Host a Discussion Meeting: Schedule a 30-45 minute meeting after people have had time to read the doc. Use this time to discuss high-level concerns and open questions, not to read the document aloud.
4. Incorporate Feedback and Finalize: Update the RFC, logging major changes. Once consensus is reached, change the status to Accepted. This now becomes the source of truth for implementation.

Next Steps

Mastering the RFC process is a powerful step in your engineering career. To sharpen the foundational skills that make great RFCs—like system design, clear communication, and understanding scalable architectures—explore relevant courses. You can browse free system design and software engineering courses to build your knowledge. If you're looking to strengthen your core computer science fundamentals, which are essential for making sound technical decisions, check out our curated list of free DSA and CS theory courses. For those aiming at product-based company roles where this skill is paramount, our guide on cracking the coding interview can be a valuable resource.