When a monolith starts hurting

Your bookstore has grown. The Order team ships features every week. The Inventory team is integrating with a warehouse API that changes quarterly. They are stepping on each other. One team's deploy breaks the other's tests. A shared database query accidentally causes an outage. This is the classic monolith pain.

The reasons to split are team boundaries, deploy contention, and independent scaling. Not technology curiosity. Not resume driven development. Splitting is expensive, and the pain it solves has to be real and measured before you take on the cost.

A monolith is the right choice almost always, right up until it is not. One team of engineers building one product should ship a monolith. Two teams that rarely touch each other's code should ship a monolith. You reach for microservices when teams start fighting over deploys, when one service needs to scale independently of everything else, or when different parts of the system have truly different failure domains.