The Monolith Was Right. Until It Wasn't. Here's Exactly When We Split.

The standard advice is correct: start with a monolith, split when necessary. In the early stages, shared code, shared database, shared deployment are advantages. A change to the user model updates everywhere immediately. A bug fix deploys once. You don't need service discovery or inter-service communication for features that don't exist yet.

For eighteen months, the monolith served us well. Feature velocity was high. The codebase was understandable. Deployments were one command. The team could work on any part of the system without specialisation.

Signal one: deployment coupling became a liability. A database migration for the reporting module required downtime that affected the user-facing product. These were unrelated systems that happened to share infrastructure. The cost of coupling was now visible in production.

Signal two: scaling requirements diverged. The image processing module needed three times the compute of every other part of the application during batch jobs. Scaling the whole monolith to handle it was wasteful. Signal three: team friction. Two teams were blocked on each other's releases because they shared a release cycle. Independence was worth more than code sharing at that point.