Why and How to Split Monolithic Applications: Practical Guidance and Database Migration Strategies

1. Why Split?

Applications become tightly coupled over time, making any change require modifications across many services; business expansion is hindered; legacy code becomes hard to maintain; system scalability suffers; and new problems compound, eventually threatening the system’s viability.

2. Preparation Before Splitting

2.1 Multi‑dimensional Understanding of Business Complexity

Assess the relationship between the system and business, aiming for a platform‑style product where functionality is centrally managed rather than scattered across isolated modules.

Gather technical insights through discussions with product and development teams, and deepen understanding via hands‑on refactoring, requirement analysis, and architecture reviews.

Define clear service boundaries based on high cohesion and low coupling, following the single‑responsibility principle.

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

Use analogies like independent “Huluwa” brothers to illustrate independent services that can later be combined into a cohesive platform.

2.3 Determine Post‑Split Application Goals

Set concrete objectives for each split phase, such as separating databases and applications first, then redesigning data models later.

2.4 Assess Current Architecture, Code, and Dependencies

Identify potential pitfalls early; the cost of solving problems after the split is far higher than the cost of thorough pre‑split analysis.

2.5 Keep a “Preparedness Pocket‑Guide”

Maintain a checklist of alternative solutions, decomposition strategies, and contingency plans to increase confidence and success probability.

2.6 Relax and Stay Positive

Maintain a calm mindset before starting the work.

3. Practice

3.1 Database Splitting

Database splitting is the most complex part, involving vertical (table‑level) and horizontal (sharding) strategies.

3.1.1 Global ID Generator for Primary Keys

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

3.1.2 Create New Tables, Migrate Data, Binlog Sync

Use UTF‑8 mb4 charset, ensure indexes are recreated, perform full data migration during low‑traffic windows, then enable incremental binlog synchronization (e.g., Alibaba Canal or Otter) with the binlog position set before the full load.

3.1.3 Refactor Join Queries

Rewrite cross‑database join queries because they are unsupported; consider strategies such as business decoupling, global tables, redundant fields, RPC‑based data stitching, or caching.

3.1.4 Cut‑over Schemes

a) DB Write‑Stop Scheme – fast, low‑cost but risky during peak periods and rollback.

b) Dual‑Write Scheme – writes to old and new tables simultaneously, allowing online operation and easier rollback at the cost of longer duration and increased latency.

3.1.5 Proper Switch Management

Initialize feature switches to null; avoid default values that could cause stale reads after a restart.

3.2 Ensuring Consistency After Splitting

Options include distributed transactions (generally avoided), message‑based compensation, and scheduled compensation jobs.

3.3 Maintaining Post‑Split Stability

Adopt defensive programming, set timeouts, degrade gracefully, reduce third‑party coupling, design minimal interfaces, enforce flow control, and implement SOPs for incident handling.

4. Summary

1) Prepare for pressure; 2) Decompose complex problems into testable, rollback‑able steps; 3) Expect Murphy’s law and have SOPs ready; 4) Use “borrow‑fake‑fix‑real” mindset to turn challenges into growth opportunities.