Why System Splitting Matters: Interview Insights on Distributed Architecture and Dubbo

1. Interview Question

Why split a system? How to split it? Can you avoid using Dubbo after the split?

2. Interviewer's Perspective

The discussion moves straight into distributed systems, which have become a standard interview topic. Nowadays, not knowing distributed concepts makes a resume unattractive, and many companies will ask about them.

In the early 2010s, most Chinese IT companies rarely mentioned distributed architecture or micro‑services. Large firms like BAT had distributed systems early on, but smaller companies mainly used SSH, Struts2, Spring, Hibernate, later moving to Spring MVC, Spring, MyBatis. Oracle was popular, and big‑data concepts were unheard of.

As the industry evolved, more companies adopted distributed architectures, largely driven by Alibaba's Dubbo framework, which pushed the technology forward.

Dubbo enabled many small‑to‑medium companies to split their monolithic applications into many services, allowing each developer to own a service, avoid code conflicts, and deploy independently, dramatically reducing the size of each release.

Today, distributed systems are a standard interview requirement, and interviewers naturally test candidates on them.

3. Friendly Tip

If you are unfamiliar with distributed systems or Dubbo, search for a Dubbo tutorial and try it out.

In simple terms, a 200,000‑line monolith can be split into 20 smaller systems of about 10,000 lines each. Instead of direct Spring calls, these services communicate via RPC (Dubbo) over the network.

4. Question Analysis

(1) Why split a system?

Without splitting, a large codebase maintained by many developers leads to frequent merge conflicts, extensive testing, and risky releases. Splitting reduces code size per service, eliminates conflicts, enables independent testing and deployment, and allows easier technology upgrades.

(2) How to split a system?

System splitting can be done in multiple rounds. Initially, break a monolith into a few services; as the system grows, further split large services into smaller ones. Aim for services around 10,000–20,000 lines of code, each owned by a small team or individual.

(3) Can you avoid Dubbo after splitting?

Yes, you could use plain HTTP APIs based on Spring MVC, but you would need to handle load balancing, retries, timeouts, and service discovery yourself, which is cumbersome. Dubbo provides these features out of the box, simplifying RPC communication.