Practical Guide to Application Splitting and Database Migration

1 Why Split?

Applications become tightly coupled, have poor scalability, contain outdated code, and the system cannot handle rapid business growth, leading to a risk of system failure if not refactored.

2 Preparation Before Splitting

2.1 Understand Business Complexity from Multiple Dimensions

Analyze the relationship between system and business, assess coupling, and involve product, development, and business teams to define clear goals.

2.2 Define Service Boundaries – High Cohesion, Low Coupling, Single Responsibility

Use analogies like independent “Huluwa” services to illustrate clear boundaries and modular design.

2.3 Set Clear Post‑Split Application Goals

Determine specific objectives for each split, such as separating DB and services in the first phase.

2.4 Assess Current Architecture, Code, and Dependencies

Identify potential issues early to reduce costly problems during implementation.

2.5 Prepare Contingency Plans

Adopt a "be prepared" mindset with multiple solutions and fallback strategies.

2.6 Manage Stress

Stay relaxed and focused before starting the work.

3 Practice

3.1 Database Splitting Practice

Discuss vertical and horizontal sharding, the need for a global ID generator, and migration steps.

3.1.1 Global ID Generation

Replace auto‑increment IDs with globally unique IDs (e.g., Snowflake, MySQL sequence tables, Alibaba tddl‑sequence) to avoid primary‑key conflicts during migration.

3.1.2 Create New Tables, Migrate Data, Binlog Sync

Use UTF‑8 mb4 charset, ensure indexes, perform full‑load migration during low‑traffic windows, then use binlog tools (e.g., Canal, Otter) for incremental sync.

3.1.3 Refactor Join Queries

Rewrite cross‑database joins because they are unsupported after splitting; consider business‑level decoupling, global tables, redundant fields, or in‑memory stitching via RPC.

3.1.4 Switch‑Over Schemes

Two approaches: a) DB stop‑write – fast but risky; b) Dual‑write – slower but allows online rollback and reduces character‑set issues.

3.1.5 Write Switches Carefully

Initialize feature switches to null to avoid default‑value mishaps during rollout.

3.2 Ensuring Consistency After Split

Options include distributed transactions (generally avoided), message‑based compensation, and scheduled‑task compensation for eventual consistency.

3.3 Maintaining Stability After Split

Adopt a three‑point strategy: suspect third‑party components, guard the consumers, and improve the service itself through single responsibility, cleaning legacy issues, SOP automation, and resource predictability.

4 Summary

Prepare for pressure, decompose complex problems into testable steps, and always have SOPs ready because unexpected issues will inevitably arise.