How Qunar Cut Half Its Codebase: A Practical Guide to Service and Code Slimming

Background

Qunar began its ticket business in 2005 and over more than a decade accumulated a large number of legacy backend services, many of which are over five years old. Rapid business growth and frequent team reshuffles left most developers maintaining codebases they inherited, resulting in limited system knowledge and a steadily increasing codebase.

The lack of cleanup for short‑lived holiday features caused code to only increase, leading to higher maintenance cost, slower new‑feature development, and a heavy per‑developer burden of tens of thousands of lines of code.

To address these pain points, Qunar launched a company‑wide slimming project in 2022 with the goal of cutting 50% of both code and services, facing three major challenges: massive deletion volume (millions of lines), coordination across dozens of teams and thousands of services, and the absence of reference cases.

Service Slimming Practice

The project was split into two phases: May‑June for service reduction and July‑November for code reduction. A virtual "Slimming Support Team" was created to provide common tools and technical assistance, and each business line was assigned a 50% reduction target.

Service merge criteria were derived from typical micro‑service decomposition principles, such as domain separation, process boundaries, and business importance. Services that did not meet these split criteria could be merged.

Service delete criteria focused on three signals:

No traffic: services that receive no inbound or internal requests.

No iteration: services with no recent code or configuration changes.

Already offline: services that have been decommissioned but not removed.

Two supporting tools were built: “Findable” to locate all services matching the above signals, and “Delete well” to automate safe removal.

Finding no‑traffic services leveraged gateway access logs, trace topology data, and scheduled‑task presence, intersecting the three result sets to obtain a comprehensive list.

Deletion standards required precision (no accidental removal), completeness (clean up domains, machines, etc.), and speed. An "Application Slimming Platform" was built to standardize a four‑cycle, ten‑step deletion workflow, with manual confirmation steps to guarantee accuracy.

Code Slimming Practice

Code reduction followed the same pattern: first identify generic characteristics of removable code, then use tools to locate the full candidate set and finally execute the removal.

Three common removal methods were evaluated:

Static analysis to drop unused methods (low volume).

Refactoring to simplify logic and eliminate duplication (high impact but manual).

Removing code that has long‑term no runtime traffic (abundant and highly automatable).

The chosen solution for the third method was the Serviceability Agent (SA), a JVM‑level tool that can count method executions without affecting business performance.

SA Overview : SA provides an API to observe the JVM. By randomly taking an instance offline, running SA to collect method‑level counters, and bringing the instance back online, the impact on production traffic is eliminated.

Implementation uses the observer pattern with custom InvocationCounterVisitor and CompiledMethodVisitor to extract execution counts from both interpreted and compiled methods.

Because a single run may miss infrequently executed methods, the process is repeated (e.g., daily for a month) to build a comprehensive execution set. The full method list of the codebase is obtained with tools like Spoon, and the intersection of executed methods is subtracted to produce the "removable method set".

Calibration is performed by instrumenting the identified methods with lightweight tracing points; a second SA run validates that no false positives remain.

Two deletion workflows were created:

Fully automated : clone the repository, create a slimming branch, delete the identified code, push the branch, and submit a code review (CR) before the usual verification and release steps.

Semi‑automated : an IntelliJ IDEA plugin scans for removable methods, offers batch deletion, method body clearing, and point insertion, giving developers fine‑grained control and lower risk.

After deletion, a six‑step verification pipeline is executed: beta release, automated testing, fault‑drill, gray release, full release, and post‑release metric monitoring.

Final Results

The initiative removed 49.87% of the codebase, exceeding ten million lines, and achieved the following measurable benefits:

Average development estimation reduced by ~10.9%, saving roughly ten thousand person‑days per year.

Release efficiency improved by ~9.5% due to smaller code size and faster build cycles.

Future Outlook

Line‑level code slimming to further reduce complexity.

Handling long‑cycle code that runs only rarely (e.g., yearly jobs).

Dependency slimming to eliminate redundant JARs.

Configuration slimming to clean up unused config items.

Automated service merging pathways.