Teams reach for microservices hoping to move faster, but the architecture only pays off when you understand what actually makes a service a microservice. The defining property is not size, technology, or the presence of HTTP APIs; it is independent deployability. If you cannot deploy one service without lockstep-deploying others, you have a distributed monolith that carries every cost of distribution and delivers none of the autonomy. Understanding the fundamentals lets you decide honestly whether the benefits outweigh the substantial new costs.

Microservices trade one kind of complexity (a large, tightly coupled codebase) for another (a distributed system with network partitions, partial failure, and data spread across many stores). That trade is only worth making for specific reasons, so knowing the real drivers keeps you from adopting the style as a default.

A microservice is an independently deployable service modeled around a business domain, owning its own data and communicating with others over networks. Two ideas do the heavy lifting.

First, independent deployability: you can change, test, and release one service into production on its own, without coordinating a release train across the whole system. This forces loose coupling and explicit, stable interfaces.

Second, the bounded context from Domain-Driven Design: a service should map to a clear business capability with a well-defined boundary, hiding its internal model and exposing only what collaborators genuinely need. Getting boundaries right is the hardest and most important design decision, because a boundary that cuts through a cohesive concept produces chatty, coupled services that must change together.

Size is deliberately vague: 'small enough and no smaller.' A good service is one a team can hold in their heads and own end to end. Counting lines of code or mandating a maximum size misses the point.

Imagine an online retailer with a single monolith handling catalog, pricing, inventory, and fulfillment. The catalog team wants to ship search improvements weekly, but every release also redeploys fulfillment, which finance insists on freezing during month-end close. Releases stall.

Splitting Catalog into its own service with its own datastore lets the catalog team deploy on their own cadence. Crucially, this works only if Catalog no longer shares database tables with fulfillment and exposes a stable API instead of letting other services read its tables directly. If fulfillment still joins against catalog tables, a catalog schema change breaks fulfillment and you are back to lockstep deploys. The lesson: information hiding and independent data ownership are what unlock the deployment autonomy, not the mere act of drawing a service boundary.

Fundamentals set up everything that follows. Independent deployability drives the need for asynchronous, loosely coupled communication and eventual consistency, because you can no longer rely on a single ACID transaction spanning services. Bounded contexts feed directly into decomposition strategies when migrating a monolith. And the costs uncovered here (operational overhead, distributed debugging, data consistency challenges) are exactly what API management, observability, and patterns like the strangler fig exist to tame.

The honest conclusion many teams reach: start with a well-structured monolith, extract services only when a concrete pressure (independent scaling, team autonomy, differing release cadence) justifies the distributed-systems tax.