Microservices architecture

Teams move to microservices when one codebase and one release train stop being fast enough for several teams. Splitting the system by business capability lets each team deploy, scale and fail on its own, at the cost of more moving parts.

Why does microservices architecture matter?

• Independent releases. A change to the payment service ships without rebuilding or retesting orders.
• Targeted scaling. The catalog gets ten times the traffic of checkout, so it gets ten times the instances.
• Fault isolation. When the recommendation service falls over, the store keeps selling.
• Clear ownership. One team, one service, one on-call rotation.

What are the parts of a microservices architecture?

• Services. Small deployable units, each owning one business capability. In the example above they are orders, payments, inventory and shipping.
• Private databases. Each service owns its data and no other service reads it directly.
• API gateway. The single entry point for clients. It routes requests, terminates TLS and handles authentication and rate limiting once. See API gateway.
• Message broker. The channel for asynchronous communication. Services publish events such as “order placed” and others subscribe; see event-driven architecture.
• Service discovery. A registry that maps service names to addresses, so callers do not hard-code them.
• Observability. Centralized logs, metrics and tracing, because one request now crosses several processes.

From the clients’ side, the whole system is still a client-server architecture with one address; the split only shows behind the gateway.

How do microservices communicate?

Style	How it works	Use it when
Synchronous request and response	One service calls another over HTTP or gRPC and waits	The caller needs the answer to continue, such as checking stock before confirming an order
Asynchronous events	A service publishes to a broker and moves on; subscribers react later	Several services care about the same fact, or the caller should not fail when a downstream service is slow

Default to events between services and keep synchronous calls for the places where a request genuinely cannot proceed without an answer, because long synchronous chains couple services together again. Eraser’s engineering blog goes deeper on the trade-offs between communication patterns.

How do you read a microservices architecture diagram?

Start at the clients and follow the arrows. In the e-commerce example at the top of this page, web and mobile apps call the API gateway over HTTPS, and the gateway routes each request by path to the order, payment, inventory or shipping service. Each service sits in its own tinted group with the database only it may touch.

The dashed lines are the other half. When the order service saves a new order it publishes an “order placed” event to the message broker, and the inventory service consumes it to reserve stock. When the payment service captures a payment it publishes “payment captured”, which the shipping service consumes to create a shipment. No service calls another directly, so a slow shipping service never slows checkout.

Reading it this way raises the right questions: what happens to an order if the inventory service is down for an hour, and how does the storefront show order status when it lives in four databases?

How does microservices architecture compare with a monolith?

	Monolith	Microservices
Deployment	One unit	One per service
Data	One database, joins across modules	One database per service, data copied through events
Communication	In-process calls	Network calls and events
Scaling	Whole application	Each service on its own
Failure	One crash takes everything down	One service fails, the rest keep running

The monolith on the left is a classic three-tier layout, and it is the right default for most new products. A monolithic architecture stays the better choice until the release process, not the code, becomes the bottleneck. Some services on the right could also run as serverless functions rather than containers.

How do you design a microservices architecture?

1. Find the domain boundaries. List the business capabilities and the data each one owns.
2. Draw the services and their data. Give each service its own store and decide which events it publishes. An architecture diagram at the system architecture level is the main design artifact.
3. Put a gateway in front. Let it handle authentication, routing and rate limiting, and keep business logic out of it.
4. Choose the communication style per edge. Default to events, and justify every synchronous call.
5. Plan for failure. Add timeouts, retries with backoff and circuit breakers on synchronous calls, and make event consumers idempotent.
6. Extract, do not rewrite. From a monolith, pull one capability out at a time and route to it from the gateway, as in parallel paths.

What are common microservices mistakes?

• The distributed monolith. Services that must be deployed together, share a database or call each other in long synchronous chains. All the cost with none of the independence.
• Too many services too early. A three-person team running fifteen services spends its time on infrastructure, not product.
• Splitting by technical layer. A “database service” and a “UI service” are layers, not capabilities. Split by domain.
• Ignoring data consistency. Without a shared database there are no cross-service transactions. Design for eventual consistency, or keep those operations inside one service.

What tools help with microservices architecture?

• Container orchestration platforms. Kubernetes and the managed container services of the major clouds handle deployment, scaling and service discovery for dozens of services.
• API gateways and service meshes. A gateway handles traffic from clients; a mesh handles traffic between services, with retries, mutual TLS and tracing built in.
• AI diagramming tools. Tools like Eraser turn a description of your services, or the infrastructure code that deploys them, into a system architecture diagram you can keep editing as services are added.

For more on this kind of diagram, see architecture diagrams.

Frequently asked questions