What are Microservices?

What does it mean?

The historical alternative to microservices is the monolithic architecture: a single application in which all functions — catalog, cart, payments, content — share the same codebase, the same database and the same deployment process. In a monolith, a small change to the pricing module requires redeploying the entire application, including parts that did not change.

Microservices break that artificial unity. Each service has its own code, frequently its own database, and communicates with other services exclusively through well-defined APIs — never by directly accessing another service's internal database. This means one team can deploy a new version of the inventory service without coordinating with the team that maintains checkout.

The size of a microservice is not measured in lines of code, but in responsibility: a well-designed microservice does one thing, does it well, and exposes that capability through a clear interface. When a service starts accumulating multiple unrelated responsibilities, it stops being "micro" in the architectural sense, regardless of its actual size.

Why it matters

In a monolith, scaling a single function under high demand (for example, search during a campaign) forces you to scale the entire application, including parts that do not need it, which wastes resources. Microservices solve that problem: each service scales independently according to its own demand.

They also solve an organizational problem: in large teams, a monolith becomes a coordination bottleneck, because any change requires testing across the entire system. With microservices, different teams can work, deploy and fail in isolation without blocking one another.

How it works

Each microservice is typically packaged as an independent container, with its own logic and, frequently, its own database — which prevents one service from depending directly on another's internal schema. Communication happens through synchronous API calls (REST, GraphQL) or asynchronous messaging (event queues) when the operation does not require an immediate response.

A container orchestrator (usually Kubernetes, in cloud native environments) manages the deployment, scaling and recovery of each service. A service discovery layer allows each microservice to find the others without fixed addresses, and an API gateway usually centralizes external traffic entering the set of services.

Applied example in AI Commerce

A retailer separates its AI recommendation engine into a microservice independent from the rest of the platform. When the recommendation model needs updating — for example, to incorporate a new embeddings-based personalization algorithm — the team deploys that version only to the recommendations microservice. Catalog, checkout and inventory keep operating without interruption, because they share neither a process nor a deployment cycle with the updated service.

Related concepts

Microservices are one of the four conditions of MACH, and the natural deployment unit of a Cloud Native infrastructure. They depend on API First so that communication between services is stable and predictable. They are also the technical foundation of Composable Commerce, where each business capability is implemented as one or more independent microservices.

Common mistakes

"Microservice" is assumed to simply mean "service small in code size". The correct criterion is single responsibility and decoupling, not the number of lines. The operational complexity is also underestimated: moving from a monolith to dozens of microservices introduces the need for distributed observability, cascading-failure management and version coordination that did not exist before. Finally, microservices are conflated with a strictly "no shared database" architecture: in progressive migrations it is common to temporarily coexist with shared databases while the separation is completed.

Frequently asked questions about microservices

← Back to the glossary