What Factors Should You Consider When Splitting Microservices?

Problems Caused by Service Splitting

Using an e‑commerce order‑placement example, the author shows that a monolithic application relies on a single database session to guarantee ACID properties, ensuring strong consistency even if the process crashes. After splitting into separate order and inventory services, communication occurs via RPC, which is not controlled by the same session, leading to potential data inconsistency due to business failures, crashes, or network issues.

This illustrates a classic complexity shift : the code complexity of the monolith moves to the communication complexity between microservices, so overall complexity does not decrease.

Referring to the CAP theorem, the author reminds that in a distributed system you can only choose two of consistency, availability, and partition tolerance. An accompanying diagram visualizes these trade‑offs.

To address consistency, the industry introduces mechanisms such as BASE theory, distributed transaction models (XA, TCC), and JTA. Depending on consistency requirements, solutions range from strong consistency to eventual consistency, aiming to preserve ACID guarantees in a distributed setting.

In practice, heavy distributed transactions are discouraged. Asynchronous scenarios often use transactional message queues (RabbitMQ, Kafka, RocketMQ), while synchronous scenarios employ business state machines to handle errors via retries, alerts, or manual intervention, treating the mutable state as the "soft state" of BASE.

How to Split Microservices Reasonably

The author proposes several guiding ideas:

1. Split by Single Responsibility – Using the same e‑commerce platform, the original OMS handled users, orders, products, inventory, warehousing, marketing, etc. Rapid growth caused the codebase to balloon, making changes affect the entire chain and reducing stability. By extracting independent services—UC (user), PMS (product), CIS (central inventory), WMS (warehouse), MCS (marketing)—each service focuses on its domain, with vertically split databases and dual‑node high availability.

2. Split by Team Organization (Conway's Law) – Conway's law states that system architecture mirrors the communication structure of the organization that builds it. The author outlines four laws, emphasizing that communication patterns shape system design, that work must be tackled incrementally, and that large systems tend to be decomposed. Aligning service boundaries with small, cross‑functional "two‑pizza" teams reduces coordination cost and improves cohesion.

3. Align System and Team Structure – If a system is monolithic but teams are distributed, coordination costs explode. Conversely, splitting the system into microservices that match team responsibilities yields higher efficiency, reflecting the principle of high cohesion and low coupling.

4. Recognize Scale‑Driven Decomposition – As systems grow, more personnel are added, increasing communication overhead. Decomposing into smaller services and teams mitigates this, following the observation that "big systems tend to be split, and split systems tend to be merged" over time.

The author also warns against over‑splitting: a single developer should stick to a monolith unless clear benefits exist, and traditional large enterprises with siloed dev/ops/testing teams may struggle with microservice adoption.

Practical Recommendations

Improve communication efficiency using tools like Slack, GitHub, and wikis; keep discussions small and responsibilities clear.

Adopt an MVP approach, iterating to validate and refine the system, ensuring elasticity.

Design teams around business domains so each small team owns the full lifecycle of its service, enabling clear boundaries and reducing hand‑offs.

Maintain small, effective teams (typically 7‑8 people) to keep coordination costs low; the "two‑pizza" rule is a useful guideline.

In summary, as long as the communication is clear, operational capabilities keep pace, and the split aligns with business needs, service decomposition is justified.