Definition
Microservices is an architecture pattern where a software application is structured as a collection of small, loosely coupled services. Each service owns a specific business capability (e.g., user authentication, payment processing, notification delivery), has its own codebase and database, and communicates with other services through APIs or message queues.
The pattern emerged as a counter to monolithic architectures, where all functionality lives in a single codebase deployed as one unit. Netflix, Amazon, Spotify, and Uber are well-known adopters. Amazon's move to microservices in the mid-2000s -- driven by a mandate from Jeff Bezos that every team must expose its functionality through APIs -- is one of the most cited examples in software architecture.
In a microservices architecture, the "user profile" service, the "search" service, and the "payments" service are separate applications. Each can be written in a different programming language, use a different database, and be deployed on a different schedule. The tradeoff: the system is more flexible and scalable, but also more operationally complex.
Why It Matters for Product Managers
Microservices define team boundaries. Most companies that adopt microservices also adopt the "two-pizza team" model (Amazon's term) where each team owns one or more services end-to-end. This means the org chart shapes the architecture, and vice versa -- a principle known as Conway's Law.
For PMs, this has concrete implications. If you want to build a feature that touches the checkout flow, the notification system, and the user profile, you are now coordinating across three teams with three different roadmaps and three different deployment schedules. Features that cross service boundaries take longer and require explicit contracts (APIs) between teams.
The upside is significant. Within a single service, your team has full autonomy. You can ship multiple times a day without coordinating with anyone else. Your team can choose the best technology for their problem. And when a service needs to scale (say, the search service during a flash sale), it can scale independently without scaling the entire application.
Understanding your company's architecture helps you scope features realistically. A PM who proposes a "simple feature" that actually requires changes to five microservices will blow their timeline.
How It Works in Practice
Service boundaries align to business domains -- Each service maps to a business capability, not a technical layer. "Order Management" is a good service boundary. "Database Access Layer" is not. Domain-Driven Design (DDD) provides a framework for identifying these boundaries.
Services communicate via APIs -- Services call each other through well-defined API contracts. REST and gRPC are common for synchronous calls. Kafka or RabbitMQ handle asynchronous messaging when one service needs to notify others without waiting for a response.
Independent deployment -- Each service has its own CI/CD pipeline. Team A can deploy their service three times on Tuesday without affecting Team B's service at all. This is the primary operational benefit.
Decentralized data -- Each service owns its data store. The user service has a user database. The order service has an order database. If the order service needs user data, it calls the user service's API -- it does not query the user database directly. This prevents tight coupling but introduces eventual consistency challenges.
Monitoring and tracing -- When a user request passes through 5 services, debugging a failure requires distributed tracing (tools like Jaeger or Datadog APM) to follow the request across service boundaries.
Common Pitfalls
Adopting microservices too early. A 10-person startup splitting their application into 15 services is creating operational overhead without the organizational benefit. Start with a monolith, and extract services when specific boundaries become clear and specific teams need deployment independence.
Distributed monolith. If every service change requires coordinated deployments across multiple services, you have a distributed monolith -- all the complexity of microservices with none of the benefits. This usually means service boundaries were drawn incorrectly.
Ignoring dependency management. Cross-service dependencies are the hidden cost of microservices. PMs need to track which features require changes to multiple services and plan accordingly, adding buffer time for API negotiations between teams.
Underestimating operational costs. Each service needs monitoring, alerting, logging, deployment pipelines, and on-call support. Going from 1 monolith to 20 services means 20x the operational surface area. Make sure the engineering team has the DevOps maturity to handle this.
Related Concepts
API-First Design -- the practice of defining service interfaces before building implementations, critical for microservices
Technical Debt -- the accumulated cost of shortcuts that microservices can both reduce (through isolated boundaries) and amplify (through inconsistent standards across services)
Dependency -- the cross-team coordination challenges that increase with microservices adoptionExplore More PM Terms
Browse our complete glossary of 100+ product management terms.