What Are Microservices?

Microservices are a way of building one application as a collection of small, independent programs that each do one job and talk to each other over the network. Instead of a single codebase where every feature lives together, you have an orders service, a payments service, a catalog service, and so on — each deployed and scaled on its own.

The word "micro" misleads people. It is not about writing tiny classes. It is about drawing boundaries so that a team can change, test, and release one piece without touching or redeploying the rest. That single idea drives almost every rule you will read below.

The core definition

A microservice has three properties that separate it from an ordinary module:

• Single business capability. It owns one clear responsibility, such as "process payments" or "manage inventory", end to end.
• Independent deployment. You can build, test, and release it without coordinating a release of the whole system.
• Private data. It owns its own database. No other service reaches into that database directly; they ask through its API.

If you remove any one of these, you drift back toward a distributed monolith — the worst of both worlds, where services are separate to deploy but still tangled together at runtime.

Pro tip: When you evaluate whether something is "really" a microservice, ask one question: can this team release this service on a Tuesday afternoon without asking any other team to do anything? If the answer is no, the boundary is wrong.

A concrete example

Imagine an e-commerce site. In a monolith, placing an order calls Java methods that live in the same process: orderService.place() calls inventoryService.reserve() and paymentService.charge() directly.

In a microservices setup, those become separate services communicating over HTTP. Here is a trimmed Spring Boot controller in the Order service that calls the Payment service:

@RestController
@RequestMapping("/orders")
public class OrderController {

    private final RestClient paymentClient;

    public OrderController(RestClient.Builder builder) {
        this.paymentClient = builder.baseUrl("http://payment-service").build();
    }

    @PostMapping
    public OrderResponse place(@RequestBody OrderRequest request) {
        // Reserve stock, then charge via a separate service over the network
        PaymentResult result = paymentClient.post()
                .uri("/payments")
                .body(new PaymentRequest(request.orderId(), request.amount()))
                .retrieve()
                .body(PaymentResult.class);

        if (!result.approved()) {
            throw new PaymentDeclinedException(request.orderId());
        }
        return new OrderResponse(request.orderId(), "CONFIRMED");
    }
}

The key difference from a monolith is the line that does an HTTP POST. That call can be slow, it can time out, and the Payment service can be down while Order is healthy. Every in-process method call you turn into a network call inherits latency and failure. This is why resilience patterns like the circuit breaker pattern exist — they are not optional decoration, they are how you stop one slow service from taking down the callers waiting on it.

How services are deployed

Each service ships as its own unit, usually a container. A minimal deployment descriptor for one service in Kubernetes looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  replicas: 3            # scale this service independently of the others
  selector:
    matchLabels:
      app: payment-service
  template:
    metadata:
      labels:
        app: payment-service
    spec:
      containers:
        - name: payment-service
          image: registry.example.com/payment-service:2.4.1
          ports:
            - containerPort: 8080
          env:
            - name: DB_URL
              value: jdbc:postgresql://payment-db:5432/payments

Notice replicas: 3. If payments are your bottleneck during a sale, you scale that service to three or ten instances without touching the catalog service. That independent scaling is one of the strongest real reasons to choose microservices. If you are new to packaging services this way, start with the fundamentals in Docker basics for microservices.

What microservices actually give you

Teams adopt this style for a handful of concrete benefits, not because it is fashionable:

• Independent releases. Ten teams can ship daily without a shared release train.
• Targeted scaling. Scale only the hot service, saving infrastructure cost.
• Fault isolation. A crash in the recommendations service should not take down checkout, if you build the boundaries and fallbacks correctly.
• Technology freedom. One team can use a different language or datastore where it fits.

These benefits are real but conditional. They only appear once you have the deployment automation, monitoring, and team structure to support many moving parts.

When a monolith is the better choice

Here is the honest part most tutorials skip: for a lot of projects, microservices are the wrong call. A single well-organized monolith is easier to build, easier to debug, and faster to ship when:

• You have one small team. Splitting into services just adds network calls between people who sit next to each other.
• The product is early and the domain boundaries are still changing weekly. Moving a boundary inside a monolith is a refactor; moving it across services is a migration.
• You do not yet have CI/CD, centralized logging, and monitoring. Microservices multiply the number of things that can break, and you need tooling to see it.

Common mistake: Starting a brand-new product with fifteen microservices "so it scales later". You inherit distributed-systems complexity — network failures, eventual consistency, distributed debugging — before you have a single paying user. Most successful systems started as a monolith and split out services once the pain was real and the boundaries were obvious.

A useful rule: build a modular monolith first, keep clean internal boundaries, and extract a service only when a specific pressure justifies it — a team that needs to release independently, or a component that must scale on its own. The monolith vs microservices comparison walks through this decision with concrete trade-offs.

The costs you sign up for

Every benefit has a bill attached. Going distributed means you now own:

• Network failure handling — timeouts, retries, and fallbacks on every remote call.
• Data consistency across services — you lose database transactions that span services, so you reach for patterns like the saga.
• Distributed debugging — a single user action touches five services, so you need request tracing to follow it.
• Operational overhead — more deployments, more dashboards, more configuration.

None of this is a reason to avoid microservices. It is a reason to adopt them deliberately, when the payoff is worth the cost.

Microservices are as much about teams as code

There is a reason microservices spread from companies like Amazon and Netflix, and it is not purely technical. Conway's Law observes that a system's design ends up mirroring the communication structure of the organization that builds it. If ten teams share one codebase, they spend their days coordinating merges and release windows.

Microservices align the architecture with the org chart: one team owns one service end to end, from code to database to on-call. That team ships on its own schedule and is accountable for its service in production. This is why "two-pizza teams" and microservices are talked about together — the boundaries are as much about letting people work independently as about letting software scale independently. If your organization is one small team, that benefit simply is not available to you yet, which is another honest reason a monolith often fits early-stage products better.

A quick self-check before you split

Before extracting a service from a monolith, run through a short checklist. If you cannot answer yes to most of these, wait:

• Is there a clear business boundary around this piece, with its own data?
• Does a specific pressure justify it — independent releases or independent scaling?
• Do you have CI/CD, centralized logging, and monitoring already in place?
• Can a team own it end to end?
• Are you prepared to handle network failures and eventual consistency at this seam?

Splitting a service is easy to do and expensive to undo. Treating extraction as a decision that must be earned, rather than a default, keeps you out of the distributed-monolith trap that sinks so many first attempts.

How this connects to the rest of the stack

Microservices in the Java world are usually built with Spring Boot, exposed as REST APIs, packaged into containers, and coordinated behind an API gateway. If you are learning the building blocks, a natural path is to first get comfortable with building REST APIs in Spring Boot, then study how the pieces fit together in microservices architecture explained.

Interview relevance

Interviewers rarely want a textbook definition. They want to know whether you understand the trade-offs. Expect questions like "when would you not use microservices?" and "how do two services share data?" A strong answer names the costs — network failures, eventual consistency, operational load — and shows you would default to a monolith until a real pressure justifies splitting. That maturity is what separates a candidate who has read about microservices from one who could be trusted to design them.

Related concepts

Once you are comfortable with the definition, study the direct comparison in microservices vs monolith, then move into the resilience and data patterns that make distributed systems survivable in production. Those patterns — not the definition — are where the real engineering lives.