What is microservices architecture, and how does it work?

In this article

1. Before you start
2. Why interviewers ask this
3. Microservices architecture from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one step of the system design learning path.

Why interviewers ask this

Microservices come up in design rounds because every boundary you draw creates a cost you must be able to name. A candidate who says "split it into services" without saying what each service owns, how services talk and what happens when one fails has described a diagram, not a design.

A weak answer lists benefits: scaling, flexibility, small teams. A strong answer defines a service by a business capability, says that each service owns its data, and then states what that costs: network calls that can fail, queries that cannot join across databases and transactions that cannot be local. A Staff-level answer also says when not to split, and how to move from one deployable to several in small steps. This page builds that answer from zero, then gives you a version you can say aloud in under a minute.

Microservices architecture from first principles

Microservices architecture

A microservices architecture is an approach that builds a single application as a suite of small services, each running in its own process, communicating through lightweight mechanisms, organized around a business capability and deployable independently through automated deployment, as Lewis and Fowler describe it, with no precise standard beyond those common traits.

Bounded context

A bounded context is a natural division within a business that gives an explicit boundary inside which one domain model, with its own terms and rules, applies. In a microservices architecture each service implements one business capability within one bounded context.

Database per service

Database per service is a pattern in which each service keeps its persistent data private in a database that only that service accesses. Other services reach the data through the owner's API or events, which keeps services loosely coupled but removes joins and transactions that span services.

In plain words

Picture a shopping mall. Each shop has its own staff, stock and till. A shop can change its opening hours or its prices without asking the others. Now compare a department store, where everything runs as one business with one till.

A microservices architecture is the mall. A monolith is the department store: an application deployed as one unit. The analogy breaks in one place. Shops in a mall do not need to agree on one customer's purchase. Services often do. One customer order may touch three services, and they must end up consistent.

In one precise sentence, a microservices architecture splits one application into services that each own one business capability and its data, and that run and deploy separately.

Lewis and Fowler (2014) say that there is no precise definition of the style, only common characteristics: organization around business capability, automated deployment, intelligence in the endpoints and decentralized control of languages and data.

Step 1: Split the application by business capability

A microservice is a small service that implements one business capability, such as orders, customers or catalog. Microsoft's Azure Architecture Center says each service is self-contained and implements a single business capability within a bounded context.

Input: a whole application. Output: a set of services whose edges follow the business, not the code. The bounded context idea comes from Domain-Driven Design, which arXiv 2405.03619 describes as organizing entities and behaviors within well-defined limits in code and database schemas.

"Small" does not mean a number of lines of code. It means the service is small enough that one team can understand, change and release it alone. The same sources define the style by business capability and independent deployment, never by size.

You now know where the lines go. The next step is the rule that makes the lines real: who holds the data.

Step 2: Each service owns its own database

Each service owns one database, and no other service reads or writes it directly. This is the database per service pattern. Richardson describes it as the way each service gets its own database to ensure loose coupling.

Input: the data a service needs. Output: a private store behind the service's API. Because the store is private, each service can use the type of database best suited to its needs, as the pattern page notes. Database per service means each service's data is private; Richardson notes this can be private tables, a private schema or a separate database server, so it does not require one server per service (microservices.io).

The cost arrives immediately. The same pattern page says business transactions that span several services are not straightforward, and queries that join data now held in several databases are challenging. This single rule creates most of the difficulty of the style. If two services share one database, they are coupled through its tables, and a change to one can break the other.

You now know why microservices are harder than they look: the data is split too, and Step 4 shows the repair.

Step 3: Services talk through an API gateway, calls and events

Services communicate over the network, and clients enter through an API gateway. An API gateway is a single entry point for clients that forwards each request to the right service. The figure below shows the gateway in front of three services, each with its own database.

Input: a client request. Output: calls between services. There are two main styles. Richardson lists messaging and remote procedure invocation as two different ways that services can communicate. A synchronous call waits for the answer, often over an HTTP (HyperText Transfer Protocol) resource API, as Lewis and Fowler note. An event is a message published when something happened, for example an order was approved. Subscribers react later, without the sender waiting.

Synchronous calls are simple to read but couple the caller's speed and uptime to the callee. Events decouple them but make the flow harder to follow. The worked example below shows what chained synchronous calls cost. The API gateway rate limiter design shows one job a gateway does.

You now know how a request moves. What remains is what to do when one business action needs several services to agree.

Step 4: A saga coordinates work that spans services

A saga coordinates local transactions across services through events or an orchestrator's commands. Richardson's saga page explains why: because the Order and Customer services have separate databases, the application cannot use a single local transaction of the kind that gives atomicity, consistency, isolation and durability (ACID).

Input: one business action, such as placing an order. Output: a chain of local transactions, each in one service. If a step fails, earlier steps are reversed by compensating actions. Because a retried message can arrive twice, each step should be idempotent, meaning that repeating it has the same effect as doing it once.

Richardson names two coordination styles. In choreography, each local transaction publishes domain events that trigger local transactions in other services. In orchestration, an orchestrator tells the participants what local transactions to execute. An orchestrator is easier to follow but is another component to run, and arXiv 2405.03619 notes it can become a single point of failure.

Consistency and queries across services

Distributed transactions across services are best avoided, the database-per-service page says, because of the Consistency, Availability, Partition tolerance (CAP) theorem. Eventual consistency is the state in which data in different services may disagree for a while and agrees once the events have been processed. Sagas have a known drawback: the saga page lists the lack of isolation, so concurrent sagas can produce data anomalies.

For queries that span services, the same pattern page names two options: API Composition, where the application performs the join, and Command Query Responsibility Segregation (CQRS), where views are kept up to date by subscribing to events. The payment system design is a full case of this problem.

1 · Split by capability2 · Own the data3 · Connect4 · CoordinateReplay

Step-by-step description

1. One service per business capability.
2. Each service gets its own database.
3. Clients enter through an API gateway.
4. Events link local transactions in a saga.

• Each service owns one database.
• An API gateway is a single entry point for clients.
• A saga coordinates local transactions across services through events or an orchestrator's commands.

Worked example

Two small computations show the costs. Both use illustrative inputs, so treat the outputs as arithmetic, not measurements.

First, a saga trace in the style of Richardson's order-and-credit scenario. The Order service creates an order in the pending state. The Customer service then reserves credit against a limit and publishes OrderApproved or OrderRejected, and the Order service sets the final state. The step order is our illustration. With a credit limit of 1,000 units and 700 already reserved (illustrative), an illustrative order of 200 units is approved and the reserved total becomes 900.¹ A second illustrative order of 400 units would pass the limit, so it is rejected and the reserved total stays 900.¹

Second, availability. If a request makes calls in series and each service is up 99.9% of the time (illustrative), and failures are independent, the chain is up 0.999 raised to the number of calls. Five calls give about 99.5%; ten give about 99.0%.¹ Over a 30-day month of 43,200 minutes, that is 215.6 minutes of downtime for five calls and 430.1 for ten, against 43.2 for one.¹ Downtime grows with every synchronous call in the chain.

Text description of the diagram

• Downtime grows with every synchronous call in the chain.
• Ten calls in series at 99.9% availability each give 430.1 minutes of downtime per 30 days.

Ten calls in series at 99.9% availability each give 430.1 minutes of downtime per 30 days.¹ The back-of-the-envelope estimation guide shows how to make numbers like these quickly in a round.

Trade-offs and edge cases

A monolith deploys as one unit, and each microservice deploys on its own. That independence is the benefit: a team can release its service without coordinating a release of everything. The price is that in-process calls become network calls, one local database transaction becomes a saga of local steps, and one failure becomes many possible partial failures.

Text description of the diagram

• A monolith deploys as one unit.
• Each microservice deploys on its own.
• A monolith keeps one local transaction; microservices use a saga.

The benefits and costs below come from the sources this page cites.

Edge cases a strong answer names:

• Operations. Lewis and Fowler list automated deployment as a core characteristic. Without it, many services mean many manual releases. Azure's own guidance says success takes a fundamental shift in mindset and goes beyond splitting an application into smaller services (Microsoft Learn). Release safety matters more with many services; see deployment strategies.
• Chatty services. If two services must call each other on every request, the boundary is probably wrong. Merge them or move the data.
• Partial failure. Azure's assessment guidance looks for timeouts at every network boundary, circuit breakers (which stop calls to a failing service for a while) and retry policies with bounded retry counts, backoff and jitter (random variation in the wait). Retried messages can arrive twice, so handlers should be idempotent, which is also why saga steps need to be. Because one request crosses many services, teams also trace it from service to service, and Azure's assessment guidance asks whether requests carry a trace identifier through every service.
• Caches and shared state. Hot lookups that many services need can sit in a cache cluster shared as infrastructure, with each service owning its own keys; the distributed cache design covers it.
• When not to split. A small team with unclear boundaries gains the costs without the benefits. A strong answer says to keep one deployable until the boundaries are clear.

Reported practice and terminology differ. Lewis and Fowler's 2014 article lists common characteristics rather than a precise definition (Thoughtworks); the term itself was first used at an architecture workshop in 2011 (arXiv 1606.04036).

How to answer it in an interview

The spoken structure: say the definition, then data ownership, then the cost, then when you would not split.

Common mistakes

• "A microservice is a tiny service." (wrong) The definition is about business capability and independent deployment, not lines of code. (right) "A service is sized so one team can own and release it, around one capability."
• "Services can share one database and still be microservices." (wrong) A shared database couples services through its tables. (right) "Each service owns its data and exposes it through an API or events."
• "I would use one ACID transaction across services." (wrong) Separate databases cannot share a local transaction. (right) "I would use a saga, accept eventual consistency and design compensating actions."
• "Microservices need HTTP." (wrong) Lewis and Fowler say "often" an HTTP resource API, and messaging is another style. (right) "Services use synchronous calls or events, depending on coupling and latency needs."
• "Microservices are always the better start." (wrong) They add network, data and operations costs. (right) "I start with the simplest deployable that fits the team and split where boundaries are proven."

Follow-up questions

How is microservices different from service-oriented architecture (SOA)?

Microservices build on service-oriented architecture (SOA) concepts but bring them down to the level of one application, with small services that each own their data and deploy alone (arXiv 1606.04036).

How do microservices talk to each other?

Through synchronous calls such as an HTTP resource API, or through events sent over messaging; a client usually enters through an API gateway. Calls are simple but couple uptime; events decouple but are harder to trace.

How do you handle a transaction across microservices?

With a saga: a sequence of local transactions coordinated through events or an orchestrator's commands, with compensating actions if a step fails. It gives eventual consistency, not isolation. See payment system design.

When should you not use microservices?

When the team is small, the boundaries are unclear or automated deployment and monitoring are missing. In those cases a single deployable avoids the network and data costs for little gain.

How do you move from a monolith to microservices?

Incrementally, with the strangler fig pattern: put a façade in front of the monolith and move one capability at a time behind it until the old code can be retired (Microsoft Learn). Roll each change out with a safe deployment strategy.

What happens to availability if each request makes ten calls instead of five?

With 99.9% per service (illustrative), five chained calls give about 99.5% and ten give about 99.0%, so expected downtime roughly doubles from 215.6 to 430.1 minutes per 30 days.¹

Sources

1. Microservices in a Nutshell (summary of Lewis and Fowler, Microservices) — Thoughtworks (Lewis and Fowler), 27 Jun 2014
2. Microservices architecture style — Microsoft Learn, Azure Architecture Center (accessed 2026-10-26), 26 Oct 2026
3. Pattern: Database per service — microservices.io, Chris Richardson (accessed 2026-10-26), 26 Oct 2026
4. Pattern: Saga — microservices.io, Chris Richardson (accessed 2026-10-26), 26 Oct 2026
5. Pattern: Microservice Architecture — microservices.io, Chris Richardson (accessed 2026-10-26), 26 Oct 2026
6. The trade-offs between Monolithic vs. Distributed Architectures (arXiv 2405.03619) — arXiv, 1 May 2024
7. Microservices: yesterday, today, and tomorrow (arXiv 1606.04036) — arXiv, 13 Jun 2016
8. Microservices assessment and readiness — Microsoft Learn, Azure Architecture Center (accessed 2026-10-26), 26 Oct 2026
9. Strangler Fig pattern — Microsoft Learn, Azure Architecture Center (accessed 2026-10-26), 26 Oct 2026