Why and How to Split a Monolithic Application: Practical Guide

1 Why Split?

Monolithic systems suffer from severe inter‑application coupling, poor business scalability, legacy code that is hard to maintain, fragile system architecture, and an increasing number of technical debts that can eventually kill the system.

2 Preparation

2.1 Assess Business Complexity

Understand the relationship between business and system, use multi‑dimensional analysis, involve product, development and operations to grasp domain models and hidden complexities before taking action.

2.2 Define Service Boundaries

Apply high cohesion, low coupling, and single‑responsibility principles; think of services as independent "Huluwa" brothers that can later combine into a platform.

2.3 Set Goals for Each Split

Define concrete objectives for each service, e.g., separate database first, redesign data model in a later phase, to avoid endless deepening of work and morale loss.

2.4 Analyze Architecture, Code, Dependencies

Identify hidden costs, evaluate current architecture, code quality, and dependencies to anticipate problems and reduce post‑migration troubleshooting.

2.5 Prepare Contingency Plans

Keep multiple solution options, break complex problems into smaller pieces, and always ask "Is there an alternative? Can the problem be decomposed? Is there a fallback plan?"

2.6 Relax and Stay Focused

Maintain a calm mindset before starting the migration.

3 Practice

3.1 Database Splitting

Two scenarios: vertical splitting (move tables to appropriate databases) and horizontal splitting (sharding large tables). Use a global ID generator to avoid primary‑key conflicts during migration.

3.1.1 Global ID Generation

Replace auto‑increment IDs with globally unique IDs (e.g., Snowflake, dedicated MySQL table, odd/even tables) to prevent duplicate keys in roll‑back or incremental sync.

3.1.2 Create New Tables, Migrate Data, Binlog Sync

Build new tables with utf8mb4 charset, ensure all indexes are created, perform full data migration during low‑traffic windows, then use binlog incremental sync tools such as Alibaba Canal or Otter. The binlog position must be captured before the full load to avoid data loss.

3.1.3 Refactor Join Queries

All cross‑database join SQL statements must be rewritten before cut‑over because cross‑database joins are unsupported.

3.1.4 Cut‑over Strategies

DB‑stop‑write : fast and low cost but risky during peak periods and hard to roll back. Dual‑write : write to old and new tables simultaneously, allowing online operation and easier rollback, at the cost of longer process and increased latency.

3.1.5 Switch Management

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

3.2 Consistency After Split

Distributed transactions are usually avoided due to poor performance; instead use message‑based compensation or scheduled tasks to achieve eventual consistency.

3.3 Stability After Split

Adopt defensive programming, design robust APIs, enforce flow control, isolate third‑party failures, and establish SOPs for operations, including cache redundancy, timeout settings, and resource‑usage predictability.

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 Turn challenges into growth opportunities.