I've made the microservices mistake twice. The first time, I pushed a Rails monolith serving 50,000 users into 12 separate services. Deployment frequency jumped from weekly to daily. The engineering team loved it. Then P99 latency went from 200ms to 850ms because every page load triggered six inter-service API calls. We spent three months on circuit breakers and caching just to get back to monolith performance. The second time, I said no to microservices when we hit 35 engineers. The monolith held for another year, then deployment coordination became so painful that two teams missed their quarterly goals. By the time we extracted the first service, the technical debt was so tangled that the "simple" notifications service took four months to split out instead of four weeks. Both decisions were defensible at the time. Both were also wrong. This is the guide I wish I had: a decision framework for when microservices make sense, when they don't, and how to migrate without betting the company on a rewrite.…