Microservices

Microservices is an organizational architecture as much as a technical one. The definition is straightforward: an application is split into small, independently deployable services, each owning its own data and communicating over APIs or messaging queues. The PM implication is the part interviewers probe: each service maps roughly to a team and a domain. When you are deciding whether to decompose a feature into its own service, you are really deciding whether that domain needs to move at a different speed than the rest of the product, and whether a team can own it end-to-end, including the data. If the answer to both is yes, decomposition pays off. If not, you often create a distributed monolith: separate deployments with such tight coupling that nothing can actually ship independently. That is the worst of both worlds, and it is a PM failure as much as an engineering one.

Why it comes up in PM interviews

Interviewers surface microservices in three contexts: platform PM and API PM rounds (where you are expected to reason about service boundaries and team topologies), system design questions (where architectural choices carry product and org implications), and “explain this to a non-technical exec” prompts (where clarity of thinking matters more than jargon). The question is almost never “define microservices.” It is usually embedded in something bigger, like “walk me through a system you designed” or “how would you structure the teams and architecture for this platform.”

The company examples worth knowing

Netflix made the canonical transition from monolith to microservices starting in 2009. The driver was organizational, not purely technical: they needed hundreds of teams to ship independently across a global CDN. Knowing this framing (org scaling, not performance) is what separates a credible answer from a textbook one.
Uber decomposed aggressively and accumulated over 2,000 microservices by 2020. They then spent years consolidating, enforcing stricter ownership rules, and merging services. The lesson for PMs: over-decomposition creates coordination overhead that shows up on your roadmap as blocked launches and unclear accountability.
Shopify runs a modular monolith, called Shopify Core, for its main Rails application at massive scale. They have been explicit that it outperforms the overhead of full decomposition for their team structure. This is the most useful counter-example to have ready.

The 2026 counter-trend PMs need to know

The CNCF 2025 survey found that roughly 42% of organizations that adopted microservices have since consolidated at least some services back into larger units. The primary reasons: debugging complexity, operational overhead, and latency introduced by service-to-service calls. Microservices carry a 30-40% higher infrastructure cost on average compared to equivalent monolithic applications, plus the ongoing cost of 2-4 dedicated platform engineers to manage the orchestration layer. Below roughly 30-50 engineers, the coordination overhead of microservices typically nets negative.

The PM read on this is a viability question, not a technical preference. That infrastructure premium comes out of your margin. The decision to decompose is a build-versus-operate trade-off that you own as much as engineering does.

The 2026 forcing function: AI inference

Even teams that deliberately stayed monolithic are now adding dedicated microservices for AI inference. LLM calls, RAG pipelines, and embedding generation have categorically different latency profiles, cost structures, and update cadences from the rest of the product code. Separating them is not a trend; it is a practical necessity. A PM who can reason about where to draw that boundary, what SLAs it implies, how rollback works when a model version changes, and how to allocate the cost, is operating at a platform PM level. This is new territory that did not exist at scale five years ago, and it is a genuine differentiator in technical PM interviews.

Weak vs. strong answers

weak

"Microservices is when you break an application into small services that communicate via APIs. It scales better than a monolith." This is the Wikipedia answer. It tells the interviewer nothing about your PM judgment. It skips the actual job: deciding when to decompose, how to own service boundaries, and how to coordinate cross-service launches. Saying "it scales better" is the most reliable tell of a junior answer. A well-designed monolith will outscale a poorly-designed microservices architecture. Microservices solve organizational scaling problems first; raw performance is a secondary and often separable concern.

strong

"Microservices is really an organizational architecture. Each service maps to a team with clear domain ownership, so the question I ask is: does this domain need to move at a different speed, and is there a team that can own it end-to-end including the data? If yes to both, decomposition pays off. If not, you usually end up with a distributed monolith, which is tight coupling with the operational overhead of separate deployments added on top.

The honest 2026 picture is that the pendulum has swung. Shopify runs a modular monolith at massive scale and is vocal that it works better for their structure. Uber over-decomposed to 2,000+ services and spent years consolidating. The infrastructure cost is real: roughly 30-40% higher than an equivalent monolith, plus platform engineering headcount to maintain it. Below about 30-50 engineers, that overhead usually nets negative.

The new wrinkle is AI inference. Even teams staying monolithic are pulling out LLM calls, RAG pipelines, and embedding services as separate microservices, because those have completely different cost, latency, and update cadences. That boundary decision is a PM call, not just an engineering one.”

The PM-owned decisions in a microservices context

When your product runs on microservices, the decisions that fall to you include: how service boundaries map to team structure (Conway’s Law runs in both directions), how cross-service feature launches are coordinated so nothing ships half-baked to users, what the API versioning strategy is so partner teams are not broken by internal changes, and whether to build or buy shared platform capabilities like auth, notifications, and billing. These are not engineering implementation details. They are product decisions with direct user and business consequences.

For deeper context on the platform PM role these decisions live in, see platform PM. For the API layer that connects services, see the API glossary entry. For the AI workloads driving new service boundary decisions, see feasibility is free.