Microservices Architecture

Definition: A software architecture style where a single application is composed of many small, loosely coupled, and independently deployable services, each built around a specific business capability and communicating over a network. The term and pattern gained traction in the early 2010s as an evolution of Service-Oriented Architecture (SOA), popularized by a widely-read 2014 article from James Lewis and Martin Fowler after companies like Amazon and Netflix had already been running similar architectures internally for years. It’s commonly framed as the opposite of a monolith — one deployable unit containing all functionality — though in practice most systems land somewhere on a spectrum between the two.

How It Works

Bounded contexts: each service is scoped to a specific business capability (User Auth, Billing, Inventory) using Domain-Driven Design boundaries, rather than being split along arbitrary technical layers
Database per service: each service owns its own database and never reaches directly into another service’s schema, forcing all cross-service data access through an API and enforcing real loose coupling
Network communication: services talk over lightweight protocols — synchronous HTTP/REST or gRPC for request-response needs, or asynchronous message queues and event brokers (Kafka, RabbitMQ) when a caller shouldn’t block on the callee, see Event-Driven Architecture
Polyglot freedom: individual services can be written in different languages and use different data stores, since the only public contract is the network API, not shared code or a shared runtime
Independent deployability: each service has its own build, test, and deploy pipeline, so a team can ship a change to Billing without coordinating a release with the team that owns Inventory
Conway’s Law in practice: team boundaries tend to mirror service boundaries — the org chart and the system architecture end up shaping each other, for better or worse

Why It Matters

Lets large engineering organizations work in parallel on different parts of a system without constantly stepping on each other in one shared codebase or release train
Enables isolated scaling — a traffic spike on the checkout service can be handled by scaling just that service, instead of scaling an entire monolith to cover one hot path
Contains blast radius: a bug or crash in a non-critical service (say, recommendations) doesn’t necessarily take down the checkout flow, if the system is designed with proper fault isolation
Allows incremental technology adoption — a team can rewrite one service in a new language or framework without a big-bang rewrite of the whole system

Under the Hood: Data Consistency Across Service Boundaries

The database-per-service rule is what makes microservices loosely coupled, but it also destroys the one thing a monolith gets for free: a single ACID transaction spanning all the data a business operation touches. When “place an order” needs to debit inventory, charge a payment, and create a shipment — three separate databases owned by three separate services — there’s no single COMMIT that can make all three happen atomically. The common answer is the Saga pattern: break the operation into a sequence of local transactions, each service committing its own change and then publishing an event (or being explicitly told) to trigger the next step, with a compensating action defined for each step to undo it if a later step fails (e.g., if payment fails, an inventory-restock event compensates for the earlier stock decrement). This trades strong consistency for eventual consistency — there’s a window, however small, where inventory has been decremented but payment hasn’t cleared yet — which is why sagas are usually paired with an outbox pattern (writing the “event to publish” in the same local transaction as the state change, then relaying it asynchronously) to guarantee the event isn’t lost even if the service crashes right after committing.

Comparison: Microservices vs Monolith vs Modular Monolith

	Microservices	Monolith	Modular Monolith
Deployment	Independent per service	Single deployable unit	Single deployable unit
Data ownership	Database per service	Shared database	Shared database, enforced module boundaries
Team scaling	Scales well to many teams	Coordination bottleneck at scale	Good middle ground
Operational overhead	High (network, observability, deployment tooling)	Low	Low to moderate
Best fit	Large orgs, independently-scaling domains	Small teams, early-stage products	Teams wanting boundaries without distributed-systems cost

Common Pitfalls

Building a “Distributed Monolith”: services that are deployed separately but so tightly coupled through synchronous calls or a shared database that they must still be deployed together and one outage cascades through all of them
Drawing service boundaries around technical layers (a “database service,” a “validation service”) instead of business capabilities, which maximizes cross-service chatter for every real operation
Underinvesting in observability — without distributed tracing, correlation IDs, and centralized logging, debugging a request that touches six services becomes close to impossible
Ignoring network reliability: every inter-service call can now time out, fail, or arrive late, and code that doesn’t account for that with retries, timeouts, and circuit breakers turns transient network blips into full outages
Adopting microservices before the team or product actually needs them, taking on real distributed-systems complexity (service discovery, distributed transactions, network debugging) to solve an organizational scaling problem that doesn’t exist yet
Skipping API versioning, so a breaking change in one service silently breaks every consumer that hasn’t been updated in lockstep

Code Example

# docker-compose.yml: three independently deployable services with their own datastores
services:
  auth-service:
    build: ./auth
    ports: ["4001:4000"]
    environment:
      DATABASE_URL: postgres://auth-db:5432/auth
    depends_on: [auth-db]

  billing-service:
    build: ./billing
    ports: ["4002:4000"]
    environment:
      DATABASE_URL: postgres://billing-db:5432/billing
      EVENT_BROKER: kafka:9092
    depends_on: [billing-db, kafka]

  auth-db:
    image: postgres:16
  billing-db:
    image: postgres:16
  kafka:
    image: bitnami/kafka:latest

Code Example: Circuit Breaker for an Inter-Service Call

// Wrapping a call to the Inventory service so a slow/failing dependency
// doesn't cascade into the caller hanging or retrying forever
const breaker = new CircuitBreaker(callInventoryService, {
  timeout: 3000,          // fail fast instead of hanging
  errorThresholdPercentage: 50,
  resetTimeout: 10000,    // try again after 10s in the "half-open" state
});

breaker.fallback(() => ({ inStock: null, degraded: true }));

app.post('/orders', async (req, res) => {
  const stock = await breaker.fire(req.body.sku);
  if (stock.degraded) {
    // Inventory service is unhealthy — proceed with a cached/optimistic
    // check rather than blocking checkout entirely
  }
  // ...continue order flow
});

Best Practices

Define service boundaries using Domain-Driven Design bounded contexts, not org charts or arbitrary technical splits
Enforce database-per-service strictly — no service should ever query another service’s tables directly, even “just this once”
Invest in distributed tracing (correlation IDs propagated through every hop) and centralized logging before the service count grows past a handful, retrofitting it later is painful
Design every inter-service call to fail gracefully with timeouts, retries with backoff, and circuit breakers, see Service Mesh for offloading this out of application code
Automate CI/CD per service so teams can deploy independently, and version APIs explicitly so consumers aren’t broken by a producer’s internal changes

FAQ

How many microservices should I start with? For most new products, fewer than you think — starting with a well-modularized monolith and splitting out services only once real scaling or team-boundary pain shows up avoids paying distributed-systems tax before you need to.

How is this different from Service-Oriented Architecture (SOA)? Microservices are often described as a more disciplined evolution of SOA — SOA commonly centralized communication through a shared Enterprise Service Bus and often shared databases, while microservices insist on database-per-service and prefer simple point-to-point protocols over a heavyweight central bus.

Do microservices require Kubernetes? No — they require independent deployability and network communication, which can run on plain VMs, a PaaS, or containers without an orchestrator, but Kubernetes (K8s) has become the de-facto standard for running many independently-scaled services because its primitives (Services, Deployments) map naturally onto the pattern.

History

Roots trace to Service-Oriented Architecture in the 2000s, and to companies like Amazon (internal API mandate, early-to-mid 2000s) and Netflix, which broke apart their monoliths years before the term existed
The name was popularized by a 2014 article from James Lewis and Martin Fowler, which gave a shared vocabulary to a pattern several companies were already converging on independently
Rose alongside Docker (2013) and Kubernetes (2014), since lightweight containers and an orchestrator solved much of the deployment and scaling complexity that made running dozens of separate services practical
Became something of an industry default recommendation through the mid-to-late 2010s, followed by a wave of “maybe we over-did it” retrospectives as smaller teams found the operational overhead outweighed the benefits at their scale

Example

Netflix transitioned from a monolithic architecture to hundreds of independently deployable microservices, so the “Recommendation Engine” service can scale independently from the “Video Streaming” service — a traffic surge in one doesn’t force over-provisioning of the other, and each is owned, deployed, and scaled by a different team on its own schedule.

Referenced by

Dig deeper

Spot an error in this note?