What is Microservices Architecture? How is it structured and how does it work?

Question

IT Interview Practice · Accepted Answer

**Microservices organizes an application into services that can be developed and deployed independently around business capabilities.** Each service runs separately and communicates through a network API or messages. A service is a business boundary, not simply one endpoint or one database table.

## Understand the main parts

For an online shop, Orders owns order status, Inventory owns stock, and Payments owns payment records. A gateway may route incoming requests, but it is optional. A message broker may carry asynchronous messages when the receiving service need not respond immediately.

```text
Client -> Orders service -> Orders data
             | network call
             +-> Inventory service -> Inventory data
             +-> Payments service  -> Payments data
```

Each service controls access to its data. Other services ask through a contract rather than editing its tables. Data isolation does not necessarily require a separate physical database machine for each service. See [microservice data ownership](https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations).

## Follow a purchase

In one illustrative workflow, Orders creates a pending order. It asks Inventory to reserve stock and Payments to charge the customer. After receiving confirmed outcomes, it marks the order confirmed and returns or exposes that status to the client.

These are separate steps across separate systems. If payment fails after stock was reserved, the workflow must request release of that reservation. This is a compensating action: a new operation that reverses a business effect, not a database rollback across all services.

If a payment request times out, the result is unknown: it may already have succeeded. Check the result and reuse the same operation identifier for any retry. Payments must recognize that identifier and avoid charging twice, returning the stored result when available. Keep the order pending until the outcome is known. [Stripe's idempotency guide](https://docs.stripe.com/api/idempotent_requests) shows this duplicate-protection mechanism.

## Why accept the extra work?

- **Independent releases:** Inventory can deploy a compatible change without releasing Orders.
- **Independent capacity:** A busy service can receive more instances without copying every service.
- **Clear ownership:** A team can own the service's behavior, data and operation.

The price is network failures, more deployments, distributed tracing and coordination of data changes. Service boundaries limit some failures only when timeouts and resource isolation are designed correctly; they do not automatically stop cascading failures. See [the architecture overview](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices).

## When are they suitable?

Choose them when independent delivery or capacity provides enough value to justify operating distributed components. A small team still discovering its domain may move faster with a modular monolith.

A useful check is whether one service can change and release without coordinating every other service. If all services share tables and must deploy together, separate processes have added network cost without achieving meaningful independence.

Understand the main parts

Follow a purchase

Why accept the extra work?

When are they suitable?

Related questions