When Splitting Microservices Backfires: Risks and Smart Strategies

What problems arise when splitting services?

Consider an e‑commerce order‑placement scenario. In a monolithic app, the order method calls the inventory method within the same process, using a single database session to guarantee ACID properties and strong consistency, even if the application crashes after the order succeeds.

After splitting into microservices, the order service calls the inventory service via RPC, losing the shared database session; failures, crashes, or network issues can lead to data inconsistency.

This illustrates a classic complexity shift : the code complexity of the monolith moves to the communication complexity between microservices, without reducing overall complexity.

Recall the distributed CAP theorem: you can only achieve two of consistency, availability, and partition tolerance.

CAP defines three guarantees:

Consistency : either return an error or return absolutely consistent latest data.

Availability : always return data (no error) but not necessarily the latest.

Partition tolerance : keep running despite internal data‑sync problems.

To address consistency, the industry introduces mechanisms such as BASE (Basically Available, Soft state, Eventual consistency), distributed transaction models (XA, TCC, JTA), and distinguishes strong, weak, and eventual consistency solutions to preserve ACID in distributed systems.

In practice, heavy distributed transactions are avoided; asynchronous scenarios use transactional message queues (RabbitMQ, Kafka, RocketMQ), while synchronous scenarios employ business state machines to handle retries, alerts, or manual intervention, treating state as the “soft state” of BASE.

Bottom line : using BASE theory guides production.

Splitting microservices improves partition tolerance and availability but sacrifices the consistency advantage of a monolith; therefore, splitting should be motivated by clear reasons.

How to split microservices reasonably?

Here are some guiding ideas:

1. Split by single responsibility

Using the e‑commerce platform example, the original OMS handled users, orders, products, inventory, logistics, marketing, etc. As the business grew, the codebase exploded, making changes risky and operations difficult. By separating concerns, you create independent services such as UC (user), PMS (product), CIS (central inventory), WMS (warehouse), MCS (marketing), each with its own database and high‑availability setup.

2. Split by team organization (Conway's Law)

Conway's Law states that system design mirrors the communication structure of the organization that builds it. It includes four sub‑laws:

Organizational communication shapes system architecture.

Time is limited; focus on completing one thing well.

Linear systems align with linear organizations.

Larger organizations tend to decompose systems.

Applying this, small “two‑pizza” teams should own corresponding microservices. If a company has a distributed team structure, each team can own a service, reducing inter‑team coordination costs and improving cohesion.

Conversely, a single monolith managed by many separate functional teams leads to high communication overhead and potential conflicts.

In short, design the system to match the team structure: front‑end/back‑end separation when teams are separated, and vice versa.

Specific practice suggestions

Improve communication efficiency with tools like Slack, GitHub, Wiki; keep discussions small and clear.

Adopt MVP design and iterate continuously; ensure the system is elastically designed.

Align system architecture with team boundaries; organize teams by business domain to foster autonomy and clear ownership, following the principle “inter‑operate, not integrate”.

Keep teams small (around 7‑8 members) to reduce communication overhead; larger teams increase friction.

Overall, as long as responsibilities are clear and operational capabilities keep pace, service splitting is generally justified.