Microservices Weren't Wrong — They Were a Phase

Every few years, engineering culture rediscovers the same trade-off and gives it a new name. Microservices promised independent deployability and team autonomy; monoliths are now being rediscovered for the operational simplicity microservices quietly gave up. Neither side of this cycle is wrong — they're answers to different constraints that most teams experience at different points in their growth.

The actual variable that should decide the choice isn't fashion, it's organizational size. A ten-person team splitting into microservices is usually importing coordination overhead it doesn't need yet. A three-hundred-engineer team running a single monolith is usually running into deployment contention it can't scale past.

Treated as a pendulum driven by trends, this debate never resolves. Treated as a function of team size and deployment frequency, the right architecture at any given moment becomes almost mechanical to determine.