What are Microservices?

What are microservices?

Microservices are an architectural style that builds one application as a set of small services, each running in its own process, owning one business capability and talking to the others over well-defined APIs. Each service can be deployed, scaled and updated without redeploying the rest. The alternative is a monolith, where all features ship together as one unit. The trade is simpler individual services for a more complex system overall.

How a microservices system works

• Services around business capabilities. A shop might have separate catalog, cart, payment and shipping services, each with its own codebase and a team that owns it.
• Communication over the network. Services call each other synchronously through API endpoints (usually REST or gRPC) or asynchronously through a message broker such as Kafka or a queue.
• Data owned by each service. Each service keeps its own data store, and others read it only through its API. This keeps services independent but means there is no single database transaction across them.
• An API gateway. Clients call one entry point, which routes requests to the right service and handles shared concerns such as authentication.
• Automation underneath. Independent deployment needs CI/CD, usually containers and an orchestrator such as Kubernetes, and centralized logging, metrics and distributed tracing.

Martin Fowler and James Lewis list nine common traits, among them decentralized data management, infrastructure automation, design for failure and evolutionary design. They note that not every system has all nine.

Benefits

• Independent deployment. A fix to one service does not wait for a release of everything else.
• Targeted scaling. Scale the services under pressure, not the whole application.
• Fault isolation. If one service is down, the others can keep working, provided callers handle the failure, for example with timeouts and circuit breakers.
• Team autonomy. Small teams own a service end to end and may pick different technologies.

The costs

Microsoft's Azure Architecture Center lists the trade-offs plainly: more moving parts, harder testing across service dependencies, data consistency without ACID transactions across services (eventual consistency instead), versioning of every API, extra network latency, and a need for mature DevOps skills. Fowler and Lewis add that a split can move complexity into the connections between services, where it is harder to see. For a small team or a young product, a well-structured monolith is often the better start.

Common mistakes

• Services cut by technical layer, not by business domain. The result is changes that always touch several services.
• A shared database. Shared schemas couple services and remove most of the benefit.
• Chatty services. Long call chains (A calls B calls C) add up in latency and make failures cascade.
• No timeouts, retries or circuit breakers. One slow dependency then slows every caller.
• Too many services too early. Operating dozens of services needs tooling most small teams do not have.
• Weak observability. Without correlated logs and traces, finding the failing service in a request chain is guesswork.

Microservices, load testing and monitoring

Each service has its own capacity limit, and a slow service can drag down everything that calls it, so test both single services and the whole call chain. A load test shows where throughput flattens and which service hits its limit first; LoadFocus runs JMeter and k6 tests from 25 cloud regions, and the free plan includes up to 10 virtual users. In production, API monitoring checks each service endpoint for status, body and response time on a schedule (every 5 minutes on the free plan), and observability tooling ties the signals together. See LoadFocus API monitoring. For a step-by-step approach, read the guide to load testing microservices in the cloud. If you design service contracts first, API-first design fits well.

FAQ: Microservices

What is the difference between microservices and a monolith?

A monolith ships all features as one deployable unit. Microservices split them into separately deployed services with their own data. Microservices give independent scaling and releases but add network calls, distributed data and more operational work.

When should I use microservices?

When several teams need to release independently, parts of the system have very different scaling needs, and you already have solid CI/CD and monitoring. For a small team or an early product, start with a modular monolith.

How do microservices communicate?

Synchronously over HTTP APIs (REST or gRPC), or asynchronously through messages and events on a broker or queue. Asynchronous messaging reduces coupling and suits workflows that do not need an immediate answer.

How do you handle data in microservices?

Each service owns its data and exposes it through an API. Changes that span services use eventual consistency, for example with events, rather than one ACID transaction.

How do you test microservices?

Combine unit tests per service, contract tests that check the agreement between caller and provider, integration tests for key flows, and load tests on both single services and the full chain.

Are microservices the same as an API?

No. An API is an interface. A microservice is a deployable service that exposes one, and a microservices system is made of many of them.