New RFC
Source: Notion | Last edited: 2025-12-11 | ID: 2c62d2dc-3ef...
Overview
Section titled “Overview”A high-level overview of your project. An overview should briefly touch on the purpose of your project and the problem it’s trying to solve.
Example***:***
Re-architecture and rewrite the existing node backend in order to address bad architecture and testability.
Business Impact
Section titled “Business Impact”Describe the business impact when your project is completed. Note that this section is not required if you already have the PRD link listed above.
Example*:*
- Engineering will be able to move more quickly on features – which means happier customers.
- Less bugs means reducing engineer debugging time and saving cost.
List all the goals of your proposed project. A goal is generally related to business objectives and usually cannot be measured until the project has been completed. A goal should express what is the desired outcome and usually capture the motivations and rationale behind it.
Example*:*
- Easier to develop and maintain.
- Speed up feature development.
Non-Goals
Section titled “Non-Goals”What is explicitly not in scope and why?
Requirements
Section titled “Requirements”List all the requirements of your proposed project. A requirement is somewhat related but not necessarily a goal. In other words, a requirement is a short description of how the system will behave when it’s finished. In contrast to goals, requirements are usually binary in nature, either a requirement has been met or it has not.
Example
- The backend should be written in a modern language such as Kotlin and be compatible with Java because the core Agora project is written in Java.
- Must have unit tests and integration tests.
- Must be able to scale and distribute across nodes.
Solution
Section titled “Solution”The section should contain all the details necessary to execute the project. This includes API design, database storage, algorithm, diagram, etc.. Use your own judgments to capture as much information as possible in this section. An outline of implementation can be expressed as:
Heading 1
-
Bullet point 1
-
Bullet point 2 Heading 2
-
Bullet point 1
-
Bullet point 2 On the other hand, if your project requires multiple phases, you can also list them here.
Templates
Section titled “Templates”Templates are just examples that you can copy and paste into your design document.
REST API Specification
GET /artists/by-user-id
Database Schema
Section titled “Database Schema”Coding Snippet
Section titled “Coding Snippet”interface SmsService { /** * Send SMS [message] from [from] phone number to [to] phone number * * @param from The sender phone number * @param from The receiver phone number * @param message A message to be sent */ suspend fun send(from: String, to: String, message: String): Boolean
companion object { /** * For sms, we use twilio https://www.twilio.com/docs/libraries/java */ fun twilio( sid: String, token: String ): SmsService { return TwilioSmsService(sid, token) } }}Diagram
Section titled “Diagram”You can use either https://app.diagrams.net/ or if you are savvier with code you can use this as well https://mermaid-js.github.io/mermaid-live-editor/edit
Rollout Plan
Section titled “Rollout Plan”Capture all complications that your project will encounter when it’s going to be pushed live. This might include a testing plan, AB test or any configuration to release this project safely. Focus on the technical details and allow the PRD to cover the product rollout strategy.
Example:
- Monitor service-admin request latency after release.
- Enable 50% on the first rollout.
Discussions
Section titled “Discussions”List all issues that need to be resolved before the project can be shipped or it could be a topic for future discussions. If you cannot keep it short, feel free to add meeting links and link them back to this doc.
Example:
- What are the complications of rolling out the new service?