# Microservices

> Break your app into small, independently deployable services — each owns one business capability and can be scaled, updated, or rewritten without touching the rest.

- **Category**: Software Design
- **Subcategory**: architectural
- **Canonical URL**: https://designpattern.fyi/patterns/microservices/

---

## Description
**Intent**: Eliminate the shared-everything deployment model so each team ships at their own pace without coordination overhead.

**Context**: Your monolith has grown to where a bug fix in the payments module requires redeploying the entire application. Different parts of the system have wildly different scaling needs. Five teams are merging to the same codebase and stepping on each other constantly.

**Solution**: Split the application into small services, each:
- Owning exactly one business capability (orders, inventory, users, payments).
- Having its own database — no shared schema.
- Communicating over HTTP APIs or message brokers (Kafka, RabbitMQ).
- Deployable, scalable, and rewritable independently.

An API Gateway routes incoming requests to the right service.


## Use Cases
Use for large, complex products with multiple autonomous teams, high-traffic services with uneven scaling needs, or when different parts of the system require different tech stacks.



## Implementation Example

```javascript
// Microservices conceptually interact over API Gateways / HTTP / Message Brokers
class InventoryService {
  async checkStock(itemId) {
    return { itemId, available: true, qty: 150 };
  }
}

class OrderService {
  constructor(inventoryService) {
    this.inventory = inventoryService;
  }
  async createOrder(itemId, qty) {
    const stock = await this.inventory.checkStock(itemId);
    if (stock.available && stock.qty >= qty) {
      return { status: "SUCCESS", orderId: "ORD-9981" };
    }
    return { status: "FAILED", reason: "Out of Stock" };
  }
}

```



## Trade-offs


### Advantages

- Deploy a single service without touching anything else — faster, safer releases.

- Scale only the bottlenecked service — no need to scale the whole app for one hot endpoint.

- Teams pick the right tool per service — Python for ML, Go for high-throughput, Node for APIs.




### Considerations & Drawbacks

- Distributed systems are hard — service discovery, network failures, and distributed transactions all become your problem.

- End-to-end testing is a nightmare; integration bugs only surface when services talk to each other.