Microservices

An architectural pattern where a product is composed of loosely-coupled, independently-deployable services communicating through APIs. Each service owns a distinct business capability and its own data store.

What are Microservices?

Microservices architecture breaks a product into smaller services, each responsible for a specific business capability (e.g., payments, notifications, search, recommendations). Each service has its own codebase, database, deployment schedule, and team. Services communicate through APIs (synchronous) or asynchronous messaging (events, queues).

The contrast is a monolith—one large codebase where all functionality lives. Monoliths are simpler initially but become coordination bottlenecks as scale increases: changing one feature requires rebuilding the entire product.

Autonomy and Scaling

Microservices enable team autonomy. A notifications team owns the notifications service end-to-end: API design, implementation, deployment, operations. They don’t need to coordinate with search, payments, or other teams except through published APIs. This parallelism is how large organizations scale engineering velocity.

They also enable independent scaling. If your search service needs more capacity, you scale just that service, not the entire product. This granularity reduces costs and improves reliability—one service failing doesn’t bring down the whole product.

Distributed Complexity

The cost is distributed complexity. A monolith is easier to debug locally. A microservices system spans multiple processes, networks, and databases—failures are harder to diagnose. Debugging a request flowing through 5 services requires distributed tracing. Data consistency becomes complex (transactions can’t span services).

Most organizations should start with a monolith (easier to coordinate, faster to develop) and graduate to microservices only when the monolith becomes a bottleneck. Microservices are an optimization for scale, not an arbitrary choice.

Service Boundaries

The critical decision in microservices is service boundaries: where to split the system. Poor boundaries create tightly-coupled services that undermine the benefits. Good boundaries reflect business domains: a “users” service, a “billing” service, a “content” service. This is domain-driven design applied to architecture.

Boundaries should be stable. If you’re constantly reorganizing services, they’re too fine-grained or poorly defined. Well-designed services evolve independently for years.

Why It Matters for Product People

Microservices are an organizational tool disguised as architecture. They enable team scale by creating clear ownership and reducing coordination overhead. But they’re only worthwhile at significant scale: $100M+ ARR companies with 50+ engineers benefit; Series A startups should use monoliths.

When considering microservices, ask: Are we limited by monolith deployments? Can separate teams develop independently? Are we managing data consistency across services now? If the answer to most is no, stay monolithic. The overhead isn’t justified.

Microservices connect to API-first design (how services communicate), team topologies (how teams align to services), and platform engineering (the infrastructure needed to make microservices viable at scale).