microservice

advancedwidespread

A microservice is a small, independently running part of a large software system, specialized in a single task, that communicates with the other parts over a network using standardized messages.

In plain terms

Imagine a restaurant where a single chef does everything: takes the order, cooks, washes dishes, and bills. If they get sick, the whole restaurant shuts down. This is traditional, monolithic software. In contrast, a microservices architecture is like a market with separate stalls: one only serves soup, another only pastries, and a third only handles payments.

Each microservice does one thing, such as login, the shopping cart, or sending notifications. Each can be developed by a separate team, updated independently, and if one fails, the others should continue to function.

This is beneficial because large systems are easier to expand and improve this way: if the number of payments spikes before Christmas, it is enough to launch more instances of the payment component, without multiplying the entire application.

This is also why you meet it in the world of AI: an AI agent often calls small services like this as tools, and the language model itself often runs as a separate service in the background.

How it works

Developers break down the large application according to business tasks: one service is responsible for one well-defined thing.
Each service runs as a separate program, typically in its own container, and usually has its own database that others do not access directly.
Services request data and operations from each other via API or message queue, as if exchanging phone calls or letters.
Often a common entry point, the API gateway, receives the user request and routes it to the appropriate services.
An orchestration system (such as Kubernetes) monitors load and errors: if necessary, it starts new instances and restarts a service that has stopped.

An everyday example

When you order in an online store, search, cart, payment, and package tracking are likely separate microservices. This is why recommendations might not load, but you can still place your order without issues.

Who is affected

developerIt must decide where it is worthwhile to break down the system and must cope with the operational burden of many small services. → Code

entrepreneur, executiveThe architecture determines how quickly the company can release a new feature and how much the system maintenance costs.

everyoneMost large online services you use daily are built this way. This also contributes to the fact that a failure in one part less frequently paralyzes the whole, although a total outage can still occur.

A common misconception

MythA microservice is always a more modern and better solution than a monolithic application.

In realityFor a small team and smaller system, a monolithic application is often simpler, cheaper, and more reliable. Microservices become worthwhile where many teams work on a large, heavily loaded system.

Limits and risks

Operating many small components is complex: each must be monitored, updated, and protected, requiring separate expertise and tools.
Debugging is harder because a single request may pass through dozens of services and can get stuck at any point.
Networked communication is slower and more vulnerable than when program parts run in one place.
If boundaries are drawn in the wrong place, services become overly interdependent, and the system combines the drawbacks of both solutions.

Similar, but not the same

monolit – A monolith is a single, all-in-one installed program, while microservices are separate, independently running and updatable components.
API – The API is the rule system through which programs communicate with each other, while the microservice is the program itself that offers such an API.
container – A container is the packaging in which a program runs, while a microservice is an independent part of the software separated by function. A microservice can run without a container, and a monolith can be placed in a container.

Related concepts

Broader

Software architecture, elosztott rendszer, cloud computing

Narrower

–

On the edge

monolit, API, API gateway, service mesh, container, Kubernetes, serverless computing

A brief history

The term spread among software developers in the early 2010s. It became widely known through James Lewis and Martin Fowler's 2014 article, "Microservices".

Where things stand

By the end of 2026, microservices are the established architecture of large online services, but the industry treats them more soberly: many teams choose a well-structured monolith and split services only where truly necessary. With the spread of AI agents, small callable services have gained a new role as tools.

Status: 2026 November

Also known as

microservice · microservices · mikroszerviz · microservice architecture · microservice · microservices · microservice architecture · micro-service

Sources

This entry was machine-edited and has undergone machine expert review; the “In the news” section updates automatically from Agent Age stories.