The microservices pendulum has swung back. In 2023-2025, Amazon, Stack Overflow, Basecamp, and several unicorns publicly documented consolidating services back to monoliths after years of distributed complexity. This doesn't mean microservices are wrong — it means teams adopted them at the wrong scale, for the wrong reasons.
The core problem with premature microservices: every service boundary creates a distributed systems problem. You trade a local function call for a network hop, a stack trace for a distributed trace, a local transaction for a saga or two-phase commit. The overhead is manageable when teams are large enough to own independent services end-to-end, but it's punishing for 2-10 person teams.
The numbers that matter: Amazon's Prime Video team documented reducing their infrastructure cost by 90% by moving from microservices to a monolith. Stack Overflow runs 9 million queries/day on 9 physical servers. Shopify's core commerce platform is a 3M-line Rails monolith, not microservices — and it processed $9.3B in Black Friday 2024 GMV.
When microservices make sense: different scaling requirements (your image processing service needs GPU nodes, your API needs CPU), different deployment cadences (payments team deploys daily, auth team deploys monthly), different compliance boundaries (PCI-scoped services must be isolated), or distinct technology requirements (ML inference in Python, API in Go). These are real architectural drivers.
The 2026 best practice is the modular monolith: a single deployable unit with clean internal module boundaries that can be extracted into services if and when a concrete driver emerges. Start monolith, extract when you feel the pain, not before.