In short
Microservices refer to an architectural style in which an application is not built as a single, cohesive block (monolith) but as a collection of many small, clearly delimited services, each of which is developed, tested, deployed and scaled independently. Each service takes care of a delimited business capability (in e-commerce, for example, basket, catalogue, pricing, checkout or shipping) and communicates with the others via clearly defined interfaces, usually over the network via HTTP/REST, gRPC or asynchronous messages.
Microservices as opposed to the monolith
To understand microservices, it helps to look at what they replace: the monolith. In a monolithic application, the user interface, business logic and data access live in a single code base and a single deployment artefact. This worked well for a long time and still does in many cases: a monolith is easy to develop, easy to test and easy to operate, as long as the team and the domain remain manageable.
The problems begin with size. As the monolith grows, so do the dependencies between its parts. A small change to the checkout can unintentionally affect search. Every release affects the entire system, so everything has to be tested and rolled out together. Only the whole can be scaled, even if only a small part is under load. Microservices break this coupling by splitting the application into independent units along business boundaries.
Core characteristics of a microservice architecture
Not every distributed application is automatically a microservice architecture. Some recurring principles are characteristic:
- Business cut (bounded context): each service encapsulates one business capability, ideally according to the principles of domain-driven design. The cut follows the business domain, not the technology.
- Own data storage: each service has its own database or at least its own data schema. A service never accesses another's database directly, only via its API. This prevents hidden coupling via the data model.
- Independent deployment: a service can be rolled out without the others having to be deployed along with it. This is perhaps the most important practical advantage.
- Decentralised responsibility: small, autonomous teams are each responsible for one or a few services across the entire life cycle: "you build it, you run it".
- Technological freedom: since services only communicate via interfaces, each team can choose the appropriate language, database or library internally. In practice, this freedom is usually deliberately restricted for reasons of maintainability.
- Fault tolerance by design: since calls go over the network, every service must expect that another may not be reachable. Patterns such as timeouts, retries, circuit breakers and fallbacks are part of the craft.
Communication between services
Services talk to each other either synchronously or asynchronously. Synchronous communication (e.g. a REST or gRPC call) is easy to understand but couples the services in time: the calling service waits for the answer and depends on the availability of the service called. Asynchronous communication via message brokers such as Apache Kafka or RabbitMQ decouples the services: one service publishes an event ("order placed") and others react to it, without the sender needing to know who is listening. Event-driven architectures are more robust against failures but harder to trace and debug.
Why microservices are relevant in e-commerce
In retail in particular, the architectural style is closely linked to the trend towards composable and headless commerce. Instead of a closed suite that delivers front end, catalogue, basket, checkout, promotions and search in one package, modern platforms rely on replaceable building blocks connected via APIs. Each building block (search, pricing engine, loyalty system) can be a service of its own or a bought-in SaaS.
The benefit is concrete: for Black Friday, the checkout service can be scaled up without inflating the entire platform. A new payment method is rolled out in the payment service without putting product search at risk. A search provider can be replaced by a better one because only one API boundary is affected. This flexibility is the main reason why large retailers take the step.
Important for Shopware retailers: at its core, Shopware 6 is not a pure microservice stack but a modular monolith with an extensive API layer (Store API and Admin API). This allows headless operation and the connection of external services without having to split the entire platform into microservices. In practice, precisely this middle way (a solid core plus selected, outsourced services) makes more sense for most retailers than a complete microservice landscape.
A concrete example: Netflix
The best-known real-world example of microservices on a large scale is Netflix. From 2009, the company migrated from a monolithic application to an architecture of several hundred services in the AWS cloud, after a database failure had paralysed shipping for days. Netflix produced numerous open-source tools from this migration (such as Hystrix for circuit breaking or the "Chaos Monkey" tool, which deliberately kills services in production to test fault tolerance). The example shows both: the enormous gain in scalability and the price in the form of operational complexity, which requires specialist knowledge of its own.
Advantages and disadvantages at a glance
| Advantages | Disadvantages / costs |
|---|---|
| Independent deployment of individual services | High operational complexity (monitoring, logging, tracing) |
| Targeted scaling of individual components | Distributed systems are hard to debug |
| Small, autonomous teams | Network latency and partial failures as the norm |
| Technological freedom per service | Data consistency across services becomes complex (eventual consistency) |
| Better fault isolation | More infrastructure and DevOps effort |
Common misconceptions
A widespread misconception is that "more services" automatically means "better". Services that are cut too finely, sometimes pejoratively called "nanoservices", create more network overhead and coordination effort than they bring in benefits. A second misconception: that microservices are a purely technical decision. In fact, the architecture reflects the organisation (Conway's law); without correspondingly cut, autonomous teams, microservices quickly turn into a "distributed monolith" that combines the disadvantages of both worlds. Many experienced architects therefore recommend the "monolith first" approach: start with a well-structured monolith and only cut out services where the pressure becomes real.
Tools and operation
Today, microservices are almost always packaged in containers (Docker) and operated via orchestrators such as Kubernetes. On top of this come building blocks for service discovery, API gateways, central logging, metrics (Prometheus/Grafana) and distributed tracing (OpenTelemetry, Jaeger), in order to be able to follow a request across several services. This "operating apparatus" is the real effort: anyone introducing microservices inevitably invests in platform and DevOps expertise.
Outlook
The microservices hype of the 2010s has given way to a more sober view. Today, the rule of thumb is that the architecture must fit the problem: large organisations with many teams and high scaling loads clearly benefit, while smaller projects are often cheaper and faster with a well-structured modular monolith. At the same time, intermediate forms such as "self-contained systems" and "modular monoliths" are emerging that offer some of the advantages without the full operational burden. For e-commerce, the decisive lever is less the sheer number of services than the ability to develop and replace individual capabilities (search, checkout, payment) independently.
A detailed, vendor-neutral classification of the term is offered, for example, by the fundamental definition by Martin Fowler and James Lewis, which has decisively shaped the style.
FAQ
What is the difference between microservices and a monolith?
A monolith is a single, cohesive application with one deployment. A microservice architecture splits the same functionality into many small, independently deployable services with their own data storage.
Do small online shops need microservices?
As a rule, no. For small and medium-sized shops, the operating costs outweigh the benefits. A modular monolith with a good API layer, such as Shopware 6 offers, is usually the more economical choice.
Are microservices the same as headless commerce?
No, but they are related. Headless separates front end and back end via APIs; microservices split the back end itself into services. You can work headless without using microservices.
Which technologies are typically involved?
Containers (Docker), orchestration (Kubernetes), API gateways, message brokers (Kafka, RabbitMQ) and tools for monitoring, logging and distributed tracing.