When Should You Split a System Into Microservices?

Decomposing a system into microservices is one of the highest-risk architectural decisions in software engineering. When executed for the wrong reasons—such as hype, organizational fashion, or poorly understood code boundaries—it results in distributed monoliths with higher latency, tangled deployments, and severe debugging friction.

However, when applied under the right technical constraints, microservices provide critical organizational agility and infrastructure resilience.

The Microservices Decision Framework#

Before extracting a domain into a standalone microservice, evaluate this 4-step decision rubric:

                      Is there a genuine constraint?
                                    |
                    +---------------+---------------+
                    |                               |
                   YES                              NO
                    |                               |
    +---------------+---------------+        KEEP IN MODULAR
    |               |               |            MONOLITH
Different       Divergent       Dedicated
Tech Stack      Scaling Need    Team Autonomy
(e.g., Python   (e.g., 100x     (> 20 engineers
 ML models)      telemetry)      on 1 domain)
    |               |               |
    +---------------+---------------+
                    |
           IS DATA TRANSACTIONALLY
            DECOUPLED FROM CORE?
                    |
          +---------+---------+
          |                   |
         YES                  NO -> Re-architect domain
          |                         boundaries first
          v
    SAFE TO EXTRACT
   AS A MICROSERVICE

Genuine Reasons to Extract a Service#

1. Divergent Hardware and Resource Scaling#

If a specific sub-system requires specialized computing resources (e.g., GPU clusters for computer vision, huge memory instances for real-time graph calculations, or C-based WebSocket proxies), decoupling that component prevents having to over-provision expensive instances for the entire application fleet.

2. Autonomous Multi-Team Delivery Cadence#

According to Conway’s Law, system design mirrors communication structures. When an engineering organization grows beyond 40–50 developers across distinct product squads, merge conflicts and deployment coordination on a single repository can stall velocity. Decoupled services allow independent release pipelines.

3. Isolation of Critical Failure Domains#

If a tertiary capability (such as a third-party webhook ingestor or PDF report generator) is prone to memory leaks, unpredictable spike traffic, or segfaults, isolating it into a sandboxed microservice ensures failures cannot bring down primary checkout or login services.

The Anti-Patterns: Why NOT to Split#

The Extraction Strategy: Bounded Contexts First#

If you determine that a service split is necessary, follow the Strangler Fig Pattern:

1. Enforce Modular Boundaries in Monolith: Ensure the target module interacts with the rest of the application exclusively through explicit PHP interfaces (e.g. BillingGatewayInterface) and domain events.
2. Decouple Database Schema: Migrate tables into separate database schemas or logical databases to eliminate all direct SQL joins.
3. Swap In-Memory Implementation for Remote Client: Replace the local class binding in the platform service container with an HTTP/gRPC client pointing to the new service endpoint:

// Phase 1 (Monolith): Direct internal service binding
$this->app->bind(BillingInterface::class, InternalBillingService::class);

// Phase 2 (Extracted Microservice): Remote API client binding without altering controllers
$this->app->bind(BillingInterface::class, RemoteBillingServiceClient::class);

4. Add Circuit Breakers and Fallbacks: Guard the remote client with connection timeouts, retries, and fallback strategies.

Explore how Alegor's Module Architecture enables seamless modular monolith development that is structured for future service extraction when necessary.