When NOT to Use Microservices

Most teams who adopt microservices regret it. The complexity tax is real, the velocity gain is theoretical, and a well-organized Rails monolith scales further than you think. This skill exists to slow the user down before they make an architecturally expensive mistake.

The opinion

Stay on the monolith. Default to a modular monolith with clear domain boundaries (use packs, namespaces, and engines if needed). Microservices are a solution to organizational problems — too many teams stepping on each other — not to scaling problems. If you have fewer than ~50 engineers, you do not have an organizational problem big enough to justify the distributed-systems tax.

This isn't dogma. It's a hard-earned consensus across the industry: GitHub, Basecamp, Shopify, and Stack Overflow all run mostly-monolith Rails. Companies that went micro and walked it back: Segment, Istio (kind of), InVision, Amazon Prime Video (2023 — went monolith, cut costs 90%).

The microservices tax (what you're paying for)

When you split, you take on: