Microservices: when splitting a system helps and when it adds complexity

Microservices divide a system into services with defined responsibilities and interfaces. This can enable independent changes and scaling. Local calls also become network interactions, requiring new operational procedures. Service count alone does not indicate architectural quality.

Find business responsibility boundaries

Consider orders, inventory and notifications. Separating notifications may help when their load differs and they must not delay the main operation. Splitting by database tables alone can create constant cross-calls rather than independence.

Define owners, data and contract-change rules for each boundary. If simple changes always require coordinated updates everywhere, expected independence may be absent. Organise modules and dependencies before splitting.

Make distributed data explicit

Services may own different data, so a shared transaction is no longer an obvious solution. Agree when updates become visible and how partial completion is handled. Users need an accurate state while work remains in progress.

Messages may repeat or arrive late. Define identifiers, retries and format compatibility. Compensation must match business meaning: cancelling a message is not equivalent to refunding money.

Prepare for network failures

Agree timeouts, bounded retries and dependency-outage behaviour. Uncontrolled retries can amplify load during incidents. Identify functions that can be temporarily limited without corrupting core data.

Logs, metrics and tracing should follow operations across boundaries. Enforce authorisation between components. Include infrastructure, on-call work and diagnostics in maintenance costs as well as initial development.

Check whether a simpler option is sufficient

A modular monolith can suit a team evolving one product without independent-release needs. Shared PHP components on the ALL IT Agency site provide reuse without making every page a service. Match the solution to the problem’s scale.

Where separation is justified, start with an agreed boundary and measure results. Check contracts, recovery and rollback. Gradual change tests assumptions before moving the entire system.

Sources and further reading

• Microsoft: microservices architecture
• OpenTelemetry: observability concepts

• Related subservice: Microservices
• Explore this service area