Introduction
Behind every scalable, reliable product is a series of decisions (some big, some small) that shape the architecture and experience. At Rightmove, we wanted a way to make those decisions more inclusive, transparent and collaborative. That’s why we introduced our RFC (Request for Comments) process.
RFCs are a lightweight framework that allow any engineer to propose ideas, spark discussion, and help shape the technical future of our platform. They enable thoughtful architectural change—not just by leadership, but by the people who build Rightmove every day.
In fact, our move towards event-driven systems, as described in From Legacy to Resilience: How Event-Driven Systems Improved Efficiency at Rightmove, started life as an RFC.
Why RFCs?
With multiple teams on product development like we have, it’s easy for good ideas to get lost in the shuffle. You spot a recurring problem, a tool that could help, or a better way to structure your services.
But how do you bring that idea to life?
RFCs give us a structured path. They’re particularly valuable when:
- Introducing cross-team features, such as non-functional requirements.
- Suggesting improvements to existing architecture, like better use of frameworks or SaaS tools.
- Sharing best practices based on real experience.
- Evaluating new technologies for adoption.
On the other hand, smaller, team-specific decisions are often captured as Architecture Decision Records (ADRs) instead.
Some examples of RFCs that got implemented:
- A transaction outbox pattern to make event streaming more reliable and easy to implement by product teams.
- A shift towards a GraphQL microservice architecture to streamline API usage.
- Standardising frontend application monitoring to improve user experience.
- Common cache pattern for microservices in that defines how to choose a cache, distributed vs local, and cache strategies (i.e. cache-aside, write-trough or write-back).
- RFC to define the same date format across all services.
How the RFC process works
It all begins when someone spots an opportunity, maybe a frustrating limitation in the current architecture, or an exciting new approach worth exploring. Instead of keeping it to themselves or trying to fix it in a silo, they raise it as an RFC: a lightweight, open proposal to start a conversation.
So, how do RFCs actually work in practice at Rightmove?
They’ll usually bounce the idea off someone in our Architecture team, or anyone that is working with them, who helps shape it into something clear and focused, they become the sponsor of the RFC. Then it’s written up, just enough detail to explain the problem, what the proposal aims to change, and why it matters.
Once it’s ready, it gets shared with our wider engineering community, where people can ask questions, challenge assumptions, and offer improvements. It’s a constructive, asynchronous conversation that helps make the proposal stronger.
The RFC writer can also target specific people for comments based on their seniority or expertise in the RFC’s domain.
When the idea feels well-baked and feedback has been addressed, the sponsor and author decide together whether to move forward. If it’s approved, we act, sometimes by building something new, sometimes by documenting a new standard, or by presenting the approach more widely.
It’s a process that encourages curiosity, discussion, and shared ownership, and it’s helped us make better decisions, faster.
Anyone can raise an RFC. The process is simple, open, and designed to fit naturally into engineering workflows.
Sponsoring/reviewing
As a sponsor, I’m often the first to hear the pitch of an idea. It’s rewarding to see people taking time to develop solutions for problems they face. I especially enjoy helping junior members, and sometimes seniors, refine their proposals by offering feedback about scalability and corner cases they may not have considered yet.
Actioning the RFC
For an RFC to be considered ready, it should have:
- followed the template with sufficient information
- addressed all outstanding issues raised in the comments
- received approval from the reviewers
An RFC can be discarded at any point in the process, though it’s important to document the reasons why. RFCs can be revisited in the future, as both business needs and available resources evolve.
Once an RFC is ready for implementation, finding resources becomes the next challenge. When the RFC aligns with a team’s objectives, they may willingly add it to their roadmap. However, architectural changes that benefit multiple teams but lack a clear owner can be particularly challenging to implement.
Why it matters
Technical decisions aren’t just about code, they’re about people. The RFC process ensures ideas are heard, refined, and aligned with our long-term vision. It gives engineers a voice and ensures our architecture evolves in thoughtful, deliberate ways.
By opening the door to collaboration and inviting challenge and discussion, we’ve created a system that leads to better solutions, and a better platform for everyone.
Curious about how we approach engineering challenges at Rightmove? Check out more stories and insights on the Rightmove Tech Blog, we regularly share how we’re evolving our platform, experimenting with new ideas, and learning as a team.