When to Split a Monolith into Microservices: Practical Guidelines and a Step‑by‑Step Example

Background and Motivation

The author recently worked on two projects that both featured multiple components and clear service boundaries—typical microservice scenarios. Drawing on earlier monolith experience, the article explores the pros and cons of microservices versus monolithic applications and discusses when and how to split a monolith.

Key Considerations for Splitting

Whether to split a system depends on several factors, including team size, operational sensitivity, project urgency, developers' skill level, and the existing infrastructure for microservices. The goal is to deliver the project quickly and completely, not to adopt microservices merely for prestige.

Microservices vs. Monolith: Comparative View

Small, single‑developer projects with low concurrency and no strict uptime requirements are better kept as monoliths to avoid unnecessary complexity.

Projects with multiple developers, higher concurrency, user‑facing services that cannot be restarted arbitrarily, and existing expertise in RPC, connection pools, and service operations benefit from a microservice approach, enabling linear horizontal scaling and independent deployment.

Splitting improves fault isolation, allows parallel development, and speeds up iteration, whereas monoliths often suffer from tightly coupled releases.

Example Project: Shared Points System

The example is a "shared points" system where mining devices report data to a server, which then calculates and allocates points based on workload. The system also integrates with external user and boss systems.

The team consists of three developers, each experienced with microservices, and the development timeline is one week.

Step‑by‑Step Decomposition Process

Step 1 – Split by Service Responsibility

Identify distinct responsibilities and create separate services:

Collector : gathers reports from mining devices and other sources.

Finance : processes financial information and allocates points.

Center : acts as the API gateway, handling all external requests and forwarding them via RPC.

Step 2 – Initialize Common Libraries

Place shared utilities in a common package, including logging, configuration, error handling, and connection pools for Redis, MongoDB, MySQL, as well as RPC (gRPC or custom Go RPC) and tracing libraries. These foundations are set up before any service code is written.

Step 3 – Define Inter‑Service Interfaces

Use protobuf to describe RPC interfaces. Each service (Collector, Finance, Center) exposes its own gRPC endpoints. The Center forwards incoming API calls to the appropriate backend service, while Collector also provides an RPC endpoint for Finance to pull collected data.

Step 4 – Parallel Development and Testing

With interfaces and common libraries ready, developers work on their assigned services independently. Unit tests validate each component, followed by integration testing and coordinated deployment.

Conclusion

The walkthrough demonstrates a simple yet systematic approach to breaking a monolith into microservices, emphasizing responsibility‑driven decomposition, shared library setup, clear RPC contracts, and parallel development. More complex projects may involve additional services and deeper considerations such as dynamic configuration, centralized management, and advanced connection‑pool strategies.