12 Rules for Successful Architecture Refactoring – Insights from Uber’s Engineering Leader

For developers, architecture design is the most critical part of software development, akin to needing a blueprint before building a house. In today’s app‑filled internet era, mature architectural patterns exist for developers and architects to reference.

However, as applications evolve, initial architectures often encounter problems such as failing to meet customer needs, lacking extensibility, or not supporting new features. This article shares Uber engineering leader Raffi Krikorian’s twelve rules for avoiding pitfalls and successfully refactoring architectures.

1. Define the purpose and necessity of refactoring

Do not overlook this step. Each architecture refactor is a major operation, like surgery, that consumes resources. Decision‑makers must analyze why the refactor is needed, explore alternatives, and ensure the goal is to satisfy a genuine business requirement and is the best solution. If analysis reveals other options—such as adding compute resources—refactoring may be unnecessary.

Checklist:

What is the reason for the refactor? Is it to meet business needs or merely aesthetic?

Are there alternative solutions, and have their pros and cons been analyzed?

2. Define the boundary of “refactor completed”

When a refactor is decided, set clear, quantifiable goals or testable criteria. Without a precise definition, the team cannot know when the work is done. For example, a performance‑optimization effort should specify a target improvement (e.g., 10% latency reduction) and how it will be measured.

Checklist:

Can the refactor’s goal be quantified or tested?

What are the acceptance criteria, and have business owners approved them?

3. Incremental (progressive) refactoring

Apply fast iteration, continuous delivery, and early feedback to the refactor itself. Break the work into small, deployable steps that can be evaluated quickly. If the architecture change is too large to be incremental, consider building a copy of the system, refactoring it, and then migrating data and traffic after thorough testing.

Checklist:

Can the refactor be divided into small iterations with rapid feedback?

Is the progress regularly demonstrated to business stakeholders?

4. Determine the current architecture state

Before starting, the team must understand the existing architecture, its original intent, and the decisions that led to it. Without this baseline, teams risk making changes that conflict with hidden constraints, leading to rework.

Checklist:

Do you know the current design, its rationale, and previous choices?

Can you establish a baseline for measuring improvement?

5. Do not ignore data

Data flows are the core of any business system. Refactoring must consider data requirements, storage, processing, and analysis impacts. Use real data to validate the effectiveness of the new architecture.

Checklist:

Are business data requirements reflected in the refactor design?

Can actual data be used to verify the refactor’s impact?

6. Manage technical debt

Architecture refactoring often aims to repay technical debt, but new debt should not be created in the process. Treat technical debt like credit‑card interest: it accumulates cost if not managed. Cultivate a culture of design quality, encourage regular refactoring, and allocate time for debt repayment and review.

Checklist:

Does the team track technical debt and have a memo system?

Are there regular training and review mechanisms for technical debt?