Refactoring a Legacy Transaction System to Java: Strategies and Process
Facing high maintenance costs, complex business demands, and costly Microsoft tech, a company migrated its five‑year‑old transaction platform to Java, employing phased refactoring, comparative testing, and traffic‑splitting to ensure correctness, minimal impact, and a smooth, zero‑downtime rollout with centralized configuration and logging.
Why Refactor
Old system had been running for over five years, with soaring maintenance costs.
Business complexity increased, exceeding the capabilities of the legacy architecture.
The legacy stack was based on Microsoft technologies, incurring high expenses.
The company was undergoing a technology shift to Java, requiring the transaction system to follow suit.
Refactor Goals
Ensure the refactored code is correct.
Minimize impact on upstream and downstream systems.
Deploy the new system smoothly without affecting order placement.
Refactor Strategy
Perform refactoring in batches.
Compare order results between the new and old systems to verify correctness.
Use traffic‑splitting to gradually route a portion of users to the new system, enabling incremental rollout.
Refactor Process
Development Phase : New system development proceeds in parallel with maintenance of the old system, resulting in a heavy development workload. Once development is complete, the new system is deployed online.
Internal Testing Phase : A comparison system validates the new system’s processing results. After stable correctness is confirmed, internal whitelist accounts are created, and a traffic‑splitting mechanism directs these users to the new system for further verification.
External Testing Phase : The traffic‑splitting system gradually increases the proportion of real users routed to the new transaction system, continuously testing and expanding until the new system handles all traffic.
Completion : After traffic is fully shifted, the old system is decommissioned.
Key Systems Involved
Comparison System : The new transaction system does not serve external users directly. Orders are first submitted to the old system, which processes them normally and simultaneously copies the request data to the new system. After both systems finish processing, the comparison system retrieves results from the old and new transaction databases and compares them to verify correctness.
Traffic‑Splitting System : Initially, only internal whitelist users (employees) are routed to the new system. After successful internal testing, a small fraction of real users (e.g., 5 out of 10,000) are gradually directed to the new system. The proportion is increased step‑by‑step after each successful test until the new system handles all traffic and the old system is retired.
New System Features
Centralized Configuration : Replaces file‑based configuration with Zookeeper, allowing instant configuration changes without service restarts.
Log Centralized Search : Aggregates logs from all servers for unified searching, solving the previous issue of scattered logs.
Diagnostic System : Adds status monitoring to each business process step, enabling rapid pinpointing of issues.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java High-Performance Architecture
Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.