Microservices

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services. Each service owns a bounded context, has its own data store, and communicates with other services over a network. The goal is to enable team autonomy, independent scaling, and technology diversity.

Microservices are not a free lunch. They trade development simplicity for operational complexity. A system that fits comfortably in a well-modularized monolith is often faster to build, test, and operate than an equivalent microservices system run by a small team.

This guide covers how to identify service boundaries, how services communicate, how they find each other, and the tradeoffs that determine whether microservices are the right choice for your organization.

A monolith is a single deployable unit that contains all functionality. Calls between modules are in-process function calls. A microservices architecture splits functionality into separate processes that communicate over the network.

The hardest part of microservices is drawing the boundaries. A boundary should align with a business capability, not a technical layer. Services organized by function — orders, payments, inventory — are more stable than services organized by layer — frontend, backend, database.

Bounded Contexts

From Domain-Driven Design, a bounded context is a linguistic boundary within which a domain model is consistent. The word "customer" might mean something different in billing than in support. Each bounded context is a candidate for a microservice.

Signs of a Bad Boundary

Services communicate either synchronously or asynchronously. Synchronous calls are simpler to reason about but create temporal coupling: if the downstream service is slow or unavailable, the caller blocks or fails. Asynchronous communication decouples services through message queues or event streams.

Synchronous

HTTP/REST and gRPC are the dominant synchronous protocols. REST is human-readable and widely supported. gRPC is faster and strongly typed but requires HTTP/2 and protobuf tooling. Reserve synchronous calls for operations where the response is needed immediately and the dependency is reliable.

In a dynamic environment, service instances come and go. Service discovery lets clients locate healthy instances without hard-coding addresses. There are two main models: client-side discovery, where the client queries a registry and picks an instance, and server-side discovery, where a load balancer or proxy routes requests.

Each microservice should own its data. No other service should read or write that service's tables directly. Data access happens only through the service's API. This encapsulation is what makes services independently evolvable.

The tradeoff is that operations spanning multiple services cannot use a single database transaction. You must design for eventual consistency using sagas, outbox patterns, or compensation transactions.

Several patterns help manage the complexity of distributed systems. Knowing when to apply them separates a working microservices architecture from a fragile one.

In a distributed system, failures are inevitable and debugging is harder. Observability — logs, metrics, and traces — is non-negotiable. Distributed tracing in particular follows a request across service boundaries, revealing latency hotspots and failure points.