# Microservices

URL: https://softwaredictionary.org/terms/microservices
Category: Software Architecture
Last updated: 2026-09-29
In Turkish: Mikroservisler

In short: Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.

## What are microservices?

In a microservices architecture, each service owns one business capability, such as user accounts, payments, or search, and runs as its own process. Services talk to each other through APIs, usually over HTTP or through message queues, and each one typically manages its own data. Because they are independent, teams can develop, deploy, and scale each service separately.

Microservices are usually packaged in containers and run on an orchestration platform such as Kubernetes, with CI/CD pipelines deploying each service on its own schedule. If the search feature gets heavy traffic, only the search service needs more instances. If one service fails, a well-designed system can keep the rest of the application working.

This flexibility has a cost. Network calls are slower and less reliable than in-process function calls, data is spread across many databases, and debugging a request that passes through ten services requires good logging, monitoring, and tracing. Keeping data consistent across services is also harder than using a single database transaction.

Microservices are the opposite of a monolith, where everything is deployed as one application. They mainly solve the problem of many teams working on one large system, so many experts recommend starting with a well-structured monolith and extracting services only when there is a clear need.

## Key takeaways

- Each microservice handles one business capability and is deployed independently.
- Services communicate over the network through APIs or messages.
- Each service usually owns its own data.
- Benefits include independent scaling and deployment; the cost is operational complexity.
- Microservices suit large systems built by multiple teams.

## Example: One microservice calling another over HTTP

```typescript
// Order service: asks the separate inventory service for stock levels
async function placeOrder(productId: string, quantity: number) {
  const res = await fetch(`http://inventory-service/stock/${productId}`);
  const { available } = await res.json();

  if (available < quantity) {
    throw new Error("Not enough stock");
  }

  // Each service owns its data, so orders go into the order service's database
  await ordersDb.insert({ productId, quantity });
}
```

## Frequently asked questions

**What is the difference between microservices and a monolith?**

A monolith is one application deployed as a single unit, while microservices split the system into many small services that are deployed independently. Microservices allow independent scaling and team autonomy but add network, data, and operational complexity.

**When should you use microservices?**

Microservices make the most sense for large applications developed by several teams that need to deploy and scale parts of the system independently. For small teams and new products, a monolith is usually faster and simpler.

**How do microservices communicate?**

They communicate synchronously through REST, GraphQL, or other RPC-style APIs, or asynchronously by publishing events and messages through a message broker. Asynchronous messaging reduces direct dependencies between services.

## Sources

- [James Lewis and Martin Fowler: Microservices](https://martinfowler.com/articles/microservices.html)

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt