Practical Guide to Application and Database Splitting: Preparation, Implementation, and Stability

1 Why Split?

Discusses reasons: heavy coupling between applications, poor business scalability, legacy code, system scalability issues, and increasing technical debt.

2 Preparation before Splitting

2.1 Understanding Business Complexity

Emphasizes multi‑dimensional analysis of business complexity, comparing system‑business relationship to a heart‑pacemaker, and the need for technical and product discussions to map domain models.

2.2 Defining Service Boundaries

Advocates high cohesion, low coupling, single responsibility; uses the “Hulu brothers” analogy to illustrate independent yet composable services.

2.3 Setting Goals for Each Split

Recommends clear, incremental objectives such as separating DB and application first, then redesigning data models.

2.4 Assessing Architecture, Code, Dependencies

Highlights the cost of thinking versus solving problems after migration, and warns against hidden constraints.

2.5 Preparing Contingency Plans

Suggests “have a pouch” – keep multiple solutions and fallback plans to increase confidence.

2.6 Relieve Stress

Encourages staying relaxed before execution.

3 Practice

3.1 Database Splitting

3.1.1 Global ID Generator

Explains why auto‑increment IDs cause conflicts during migration and lists options such as Snowflake, MySQL auto_increment table, dual‑table sequences.

3.1.2 Create New Tables, Migrate Data, Binlog Sync

Recommends utf8mb4 charset, careful index creation, full‑load sync during low traffic, and incremental sync via binlog tools like Canal or Otter.

3.1.3 Refactor Join Queries

Describes the need to rewrite cross‑database joins because they are unsupported after split, offering strategies like business decoupling, global tables, redundant fields, RPC stitching, and caching.

3.1.4 Switch‑over Schemes

Two approaches: a) DB write‑stop with quick rollback risk, b) Dual‑write with longer cycle but online continuity and lower character‑set issues.

3.1.5 Switch Implementation

Emphasizes initializing switch flags to null to avoid stale defaults during restarts.

3.2 Ensuring Consistency After Split

Discusses distributed transactions (not recommended), message‑based compensation, and scheduled task compensation for eventual consistency.

3.3 Maintaining Stability

Three pillars: suspect third‑party services, guard consuming applications, and keep your own service clean (single responsibility, clean up legacy issues, SOPs, resource predictability).

4 Summary

Prepare for pressure, decompose complex problems into testable steps, adopt SOPs, and treat low‑probability risks as inevitable.