What Are Microservices?

Analogy categoryAnalogies

A microservice is a small, independently deployable software component that owns a single business capability, such as billing, inventory, or user authentication, and exposes that capability through a well-defined network API. Instead of shipping one large application binary, a microservices architecture splits the system into many such services, each built, tested, deployed, and scaled on its own schedule. The services communicate with each other over the network, typically using HTTP/REST, gRPC, or asynchronous messaging, rather than through in-process function calls.

🏏

Cricket analogy: Think of an IPL franchise: the batting coach, bowling coach, physio, and analytics team each own one specialty and report results independently, the way a payments microservice owns billing without needing to know how the shipping service works.

Core Characteristics

Independent deployability is the defining trait: a team can change and release its order-service without coordinating a release with the teams owning payment-service or notification-service, as long as the API contract stays stable. Each microservice typically owns its own database or data store, so the inventory-service's schema is invisible to the shipping-service; any other service that needs inventory data must ask through the inventory-service's API, never by querying its tables directly. This data ownership boundary prevents the tight coupling that made monolithic databases hard to evolve.

🏏

Cricket analogy: A franchise can swap its wicketkeeper mid-season without renegotiating the bowling attack's contracts, just as one microservice can be redeployed without a coordinated release across the whole system.

A Simple Example

javascript

// order-service calls inventory-service over HTTP to check stock
async function placeOrder(orderRequest) {
  const stockCheck = await fetch(
    `https://inventory-service.internal/api/v1/items/${orderRequest.sku}/availability`
  );
  const { available, quantity } = await stockCheck.json();

  if (!available || quantity < orderRequest.qty) {
    throw new Error('Insufficient stock');
  }

  const order = await db.orders.insert({
    sku: orderRequest.sku,
    qty: orderRequest.qty,
    status: 'PENDING_PAYMENT',
  });

  // order-service owns only its own 'orders' table;
  // inventory-service owns the 'items' table exclusively
  return order;
}

Notice that order-service never queries inventory-service's database directly. It always goes through inventory-service's HTTP API. This is the boundary that keeps the two services independently deployable.

Why Teams Adopt Microservices

Organizations typically adopt microservices to let multiple teams work in parallel without stepping on each other's code, and to scale hot paths independently, for example running 50 replicas of a checkout-service during a flash sale while keeping a reporting-service at 2 replicas. This maps engineering org structure onto system architecture, an idea often summarized by Conway's Law: the software tends to mirror the communication structure of the organization that builds it.

🏏

Cricket analogy: A national cricket board can scale up its T20 selection committee's activity during World Cup season while keeping the domestic first-class committee running at normal capacity, similar to scaling checkout-service without scaling reporting-service.

Microservices are not free. Splitting a system introduces network latency, partial failure modes, and operational overhead (service discovery, distributed tracing, versioned APIs) that a single-process monolith never has to deal with. Adopt this style when team-scaling or independent-deployment needs justify that cost, not by default.

A microservice owns one business capability end-to-end, including its own data store.
Services communicate over the network via APIs (REST, gRPC, or messaging), never via shared in-process calls.
Independent deployability means one service's release doesn't force a release of the others.
Data ownership boundaries prevent other services from directly querying a service's database.
Microservices let teams scale hot-path services independently of low-traffic ones.
Conway's Law: system boundaries tend to mirror the organization's team boundaries.
The architecture trades implementation simplicity for operational complexity — it is a deliberate cost/benefit decision.

Practice what you learned

1. What is the defining characteristic of a microservice?

2. How should one microservice access data owned by another microservice?

3. Which of the following is a genuine cost of adopting microservices compared to a monolith?

4. What does Conway's Law suggest about microservice boundaries?

Was this page helpful?

Monolith vs Microservices

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Software Engineering Study Notes

Python · 40 topics

Software Engineering

Git & Version Control Study Notes

Bash · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#SoftwareArchitecture#MicroservicesStudyNotes#SoftwareEngineering#WhatAreMicroservices#Microservices#Core#Characteristics#Simple#StudyNotes#SkillVeris

What Are Microservices?