Microservices refer to an architectural style in which an application is not built as a single, coherent block (monolith), but as a collection of many small, clearly delineated 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, shopping cart, 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 in contrast to the monolith
To understand microservices, it helps to look at what they are replacing: 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 has worked well for a long time and in many cases still does today - 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 start with the size. As the monolith grows, so do the dependencies between its parts. A small change to the checkout can unintentionally influence the search. Every release affects the entire system, so everything has to be tested and rolled out together. Only the whole system can be scaled, even if only a small part is under load. Microservices break this coupling by splitting the application into independent units along functional boundaries.
Core features of a microservice architectureNot every distributed application is automatically a microservice architecture. It is characterised by a few recurring principles:
- Bounded context: Each service encapsulates a business capability, ideally according to the principles of domain-driven design. The cut follows the technicality, not the technology. Own data storage: Each service has its own database or at least its own data schema. A service never accesses another service's database directly, but only via its API. This prevents hidden coupling via the data model.Independent deployment: One service can be rolled out without the others having to be deployed as well. This is perhaps the most important practical advantage.Centralised responsibility: Small, autonomous teams are each responsible for one or a few services over the entire life cycle - "you build it, you run it".
- Technological freedom: As 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. Failure tolerance by design: As calls are made via the network, every service must expect another to be unavailable. Patterns such as timeouts, retries, circuit breakers and fallbacks are part of the trade.
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 terms of time: the calling service waits for the response and is dependent on the availability of the called service. Asynchronous communication via message brokers such as Apache Kafka or RabbitMQ decouples the services: one service publishes an event ("order placed"), others respond to it without the sender having to know who is listening. Event-driven architectures are more robust against failures, but are more difficult 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 the front end, catalogue, shopping cart, checkout, promotions and search in a single package, modern platforms rely on interchangeable building blocks connected via APIs. Each building block - the search, the price engine, the loyalty system - can be a separate service or a purchased SaaS.
The benefits are tangible: the checkout service can be scaled up for Black Friday without blowing up the entire platform. A new payment method can be rolled out in the payment service without jeopardising the product search. A search provider can be replaced with a better one because only one API boundary is affected. This flexibility is the main reason why large retailers are taking this step.
Important for Shopware merchants: Shopware 6 is not a pure microservice stack at its core, 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, this middle ground - 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-life example of microservices on a large scale is Netflix. In 2009, the company migrated from a monolithic application to an architecture consisting of several hundred services in the AWS cloud after a database failure paralysed shipping for days. Netflix has produced numerous open source tools from this migration (such as Hystrix for circuit breaking or the "Chaos Monkey" tool, which shoots down specific services during operation in order to test failure tolerance). The example shows both: the enormous scaling gain and the price in terms of operational complexity, which requires specialist knowledge.
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 difficult to debug |
| Small, autonomous teams | Network latency and partial failures are 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 common misconception is that "more services" automatically means "better". Services that are cut too fine - sometimes pejoratively referred to as "nanoservices" - generate more network overhead and coordination effort than they bring in terms of benefits. A second misconception is that microservices are a purely technical decision. In fact, the architecture reflects the organisation (Conway's Law) - without appropriately tailored, autonomous teams, microservices quickly become 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 first and only cut out where the pressure becomes real.
Tools and operation
Microservices today are almost always packaged in containers (Docker) and operated via orchestrators such as Kubernetes. In addition, there are building blocks for service discovery, API gateways, centralised logging, metrics (Prometheus/Grafana) and distributed tracing (OpenTelemetry, Jaeger) in order to be able to track a request across multiple services. This "operating apparatus" is the real effort: anyone who introduces microservices inevitably invests in platform and DevOps expertise.
OutlookThe hype surrounding microservices in 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 a high scaling load clearly benefit, while smaller projects often fare better and faster with a well-structured module monolith. In parallel, intermediate forms such as "self-contained systems" and "modular monoliths" are emerging, which offer some of the advantages without the full operational burden. For e-commerce, the decisive lever remains less the sheer number of services and more the ability to develop and exchange individual capabilities - search, checkout, payment - independently.
The basic definition by Martin Fowler and James Lewis, which has significantly shaped the style, offers a detailed, vendor-neutral categorisation of the term.
FAQ
What is the difference between microservices and a monolith?
A monolith is a single, coherent application with one deployment. A microservice architecture breaks down 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 - as offered by Shopware 6 - is usually the more economical choice.
Are microservices the same as headless commerce?
No, but they are related. Headless separates frontend and backend via APIs; microservices break down the backend itself into services. You can work headless without using microservices.
Which technologies typically belong to this group?
Containers (Docker), orchestration (Kubernetes), API gateways, message brokers (Kafka, RabbitMQ) as well as tools for monitoring, logging and distributed tracing.