## glossary
What is Microservices?
What Are Microservices?
Microservices are an architectural style that structures the application as a set of small, independent services organized by business capability. Each service has its own database, is deployed separately and communicates with the others over the network, usually via an API or messaging.
The alternative is the monolith: the whole application in a single deployable artifact. Choosing between the two is one of the most consequential — and most frequently botched — decisions in software architecture.
What microservices deliver
- Independent deploys — changing the payments service does not require republishing the entire catalog.
- Selective scaling — the search service can have twenty replicas while reporting has one.
- Technology autonomy — each service can use the language and database best suited to its problem.
- Failure isolation — a degraded service does not have to bring down the whole system, given proper containment.
- Independent teams — small teams own services end to end without constant coordination.
What they charge in return
Here lies the part that tends to be underestimated. Calls that used to be in-memory function invocations become network requests, with latency, partial failures and the need for retries. Transactions the database guaranteed with a COMMIT start requiring distributed coordination. Debugging stops being reading a stack trace and starts requiring distributed tracing. And operations multiply: ten services mean ten pipelines, ten monitoring setups, ten sets of alerts.
// MONOLITH — the database guarantees atomicity
await db.transaction(async (tx) => {
await tx.debit(accountA, 100);
await tx.credit(accountB, 100);
}); // failed? nothing happened
// MICROSERVICES — no global transaction
await accounts.debit(accountA, 100);
try {
await accounts.credit(accountB, 100);
} catch (e) {
await accounts.refund(accountA, 100); // manual compensation
// and what if the refund fails too?
}When each model makes sense
The most defended recommendation today — including by those who popularized the term — is to start with the monolith. It is simpler to develop, test and operate, and most products never reach the scale that justifies the split. Microservices start paying off when the bottleneck is organizational: too many teams stepping on the same repository, deploys blocked on coordination, parts of the system with radically different scaling needs.
A widely used middle path is the modular monolith: a single deployable artifact, but with explicit internal boundaries between domains. That preserves operational simplicity and keeps service extraction viable for when it is truly justified.
## faq
Frequently asked questions
What is the ideal size of a microservice?
There is no measure in lines of code. The useful criterion is the domain boundary: the service should have a cohesive business responsibility and be comfortably maintained by a small team. If frequent changes require touching several services together, the split was made in the wrong place.
Do microservices require Kubernetes?
Not necessarily, but operating many independent services is exactly the problem Kubernetes solves. With few services, containers managed by simpler platforms do the job with far less complexity.
How do microservices communicate?
In two main ways. Synchronously, via REST or gRPC, when the response is needed immediately. And asynchronously, via queues or events such as Kafka and RabbitMQ, when processing can happen later — a model that reduces coupling and improves resilience to temporary failures.