Why Split Your Monolith? Practical Steps for Application & DB Partitioning

Why Split?

Heavy coupling between applications, poor business scalability, legacy code that is hard to maintain, and limited system extensibility all drive the need to split a monolith into independent services.

Preparation Before Splitting

Understanding Business Complexity

Analyze the system from multiple dimensions, discuss domain models with product and developers, and identify tight couplings that resemble a heart‑pacemaker relationship rather than a replaceable component.

Defining Service Boundaries

Apply the principles of high cohesion, low coupling, and single responsibility. Use the "Hulu brothers" analogy: each service has independent functionality but can be combined into a unified platform.

Setting Post‑Split Goals

Determine concrete objectives for each service, such as separating databases first and redesigning data models later, to avoid endless deepening of the split without clear outcomes.

Database Splitting Practice

Vertical and Horizontal Partitioning

Vertical splitting moves tables into separate databases based on functional domains (e.g., messages vs. organization). Horizontal splitting shards large tables across multiple databases.

Global ID Generator

Replace auto‑increment primary keys with globally unique IDs to avoid conflicts during migration and rollback. Options include Snowflake, a dedicated MySQL table, or dual‑table odd/even strategies.

Migration Steps

Create new tables with utf8mb4 charset and proper indexes.

Perform full data sync during low‑traffic periods, controlling concurrency.

Use binlog incremental sync tools (e.g., Alibaba Canal, Otter) after full sync.

Ensure the binlog start position precedes the full sync to avoid data loss.

Cross‑Database Query Refactoring

When a table is moved to another database, rewrite join queries using one of the following strategies:

Avoid cross‑database joins by decoupling business logic.

Maintain global tables (not recommended for large systems).

Redundant fields to store needed foreign keys.

In‑memory joins via RPC calls.

Local caching for high‑frequency data.

Cut‑Over Schemes

DB Stop‑Write

Temporarily stop writes, switch to the new database, then resume. Fast and low cost but risky during peak periods and hard to roll back.

Double‑Write

Write to both old and new tables simultaneously, handling exceptions explicitly. Safer rollback and less impact on character set, but adds latency and complexity.

Ensuring Consistency After Split

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

Stability Practices Post‑Split

Assume third‑party components may fail; apply defensive programming and degradation strategies.

Design minimal, well‑documented interfaces to prevent misuse.

Implement capacity limits and flow control per service.

Adopt single‑responsibility design, clean legacy pitfalls, and standardize SOPs for incidents.

Predict resource usage (CPU, memory, network, disk) and use caching layers (e.g., Redis, local Guava cache) to smooth traffic spikes.

Summary

1) Prepare for pressure. Break complex problems into testable, rollback‑able steps.

2) Decompose issues into multiple phases, ensuring each can be verified and reverted.

3) Follow Murphy's Law: anticipate failures and have SOPs ready.

4) Embrace "fake‑to‑real" learning: use challenging refactoring projects to grow expertise.