Overview
Microservice architecture is an approach to software development in which one large application is broken down into multiple small, autonomously developable and scalable services. Each service focuses on a distinct piece of functionality and normally communicates via network protocols such as HTTP or message queues.
In modern cloud environments, microservice architecture is often combined with containerisation, continuous delivery and advanced monitoring. This architectural model is popular with organisations aiming for high agility, scalability and independent teamwork, yet it also introduces considerable complexity.
Definition and characteristics of microservice architecture
Differences between monolithic, modular monolithic and microservice architectures
Core principles such as bounded contexts, autonomy and decentralised data
Benefits and drawbacks, including operational complexity
Typical patterns for communication, data and deployment
Prerequisites such as DevOps, observability and organisational set-up
Definition and key characteristics
Microservice architecture is a software-architecture style in which an application consists of a collection of small, independent services. Every service implements a specific business capability, runs in its own process and communicates with other services via lightweight protocols, often HTTP, gRPC or asynchronous messaging.
In contrast to a monolithic architecture, where all functionality lives in one codebase and one deployment package, microservices split logic into several clearly bounded parts. A microservice typically has its own data layer, its own release cycle and can be scaled independently. A change to one microservice therefore does not necessarily require redeploying the entire application.
An important concept within microservice architecture is the bounded context. Originating from Domain-Driven Design, it denotes a clearly delimited part of the domain with its own models and terminology. In a microservice landscape, each bounded context often maps to a separate service, for example an invoicing service, an inventory service or a user-management service.
Microservices in relation to other architectures
A common distinction is made between three levels: monolithic, modular monolithic and microservices. A monolithic application has one codebase and one deployment. A modular monolith keeps that single deployment but is internally well-structured with clear module boundaries. A microservice architecture goes a step further by turning those module boundaries into physical separation between processes and deployables.
In practice, microservice architecture often emerges as the next step after a modular monolith set-up. First, clear module boundaries are defined; then critical modules are gradually extracted as separate services. This phased migration is frequently applied to limit risk and to gain experience step by step with the extra operational complexity of a distributed system.
Principles, benefits and drawbacks
Microservice architecture rests on several recurrent principles. The first is autonomy: a microservice should be able to operate as independently as possible. This implies its own data storage, codebase, configuration and release process. Teams can thus work independently and deliver functionality without waiting for others.
The second principle is loose coupling and high cohesion. Loose coupling means services know as little as possible about each other’s internal implementation and communicate via stable, explicit interfaces. High cohesion means the code within a service fits together logically and covers one functional area, supporting comprehensibility and maintainability.
Advantages of microservice architecture include targeted scalability, technological flexibility and improved team agility. A heavily used service can be scaled independently—by running more container instances, for example—without affecting the rest of the system. Teams may choose technologies that best fit the specific service as long as the agreed interface remains intact. Smaller codebases are also easier to grasp and change quickly.
Set against these benefits are clear downsides. The system inevitably becomes more complex to operate. Release pipelines must be set up for multiple services, and there is a need for service discovery, load balancing, sophisticated monitoring and logging. Network communication introduces latency, failure scenarios and security concerns such as time-outs, circuit breaking and inter-service authentication. Data consistency likewise grows more complicated when each service owns its own database; cross-service ACID transactions are usually not feasible, so patterns like eventual consistency and the outbox pattern are required.
Data consistency and transactions
Data management is a key concern in microservice architecture. In a monolithic system, a transaction across multiple tables inside one database is straightforward thanks to relational constraints and database transaction mechanisms. In a microservice landscape, each service typically maintains its own data, making it less dependent on others but rendering composite transactions harder.
Rather than a single global transaction, saga patterns and asynchronous messaging are often used. A process such as placing an order is split into a series of local transactions in different services. A coordinating mechanism tracks progress and can trigger compensating actions if a step fails. This results in eventual consistency: data is not up to date everywhere at every moment, but converges to a consistent state after a short while.
Communication, infrastructure and observability
Microservice architecture employs various communication patterns. Synchronous request-response over HTTP or gRPC is intuitive—a client sends a request to a service and receives an immediate response. This suits use-cases where direct feedback is needed, such as retrieving product details. Too much synchrony, however, can create dependency chains in which one slow service delays the entire flow.
Asynchronous patterns are therefore widely adopted. Services publish messages to queues or topics to which other services subscribe, forming an event-driven architecture. Events such as order placed or user registered are broadcast, and services process them at their own pace. This increases decoupling and makes it easier to add new functionality later by introducing new consumers.
At the infrastructure level, microservice architecture is often combined with containerisation and orchestration. Containers—Docker, for instance—provide a standardised way to package services with all their dependencies. An orchestration platform, commonly Kubernetes, handles starting, scaling, restarting and distributing containers across nodes. Service meshes such as Istio or Linkerd manage network traffic between services and centrally provide observability features such as tracing, retries and circuit breaking.
Observability is vital in a microservice landscape. Because a request may pass through several services, it is hard to spot where delays or errors originate without tracing. Modern observability solutions combine metrics, logs and distributed traces. Correlation identifiers travel along calls so that for each request path you can analyse which services were invoked. This is essential for fault diagnosis, performance optimisation and capacity planning.
Design choices, migration and organisational aspects
Microservice architecture is not solely a technical decision; it directly affects team structures and workflows. Architecture is often said to mirror the organisation. In a microservice environment, teams are usually cross-functional and end-to-end responsible for one or a few services. A team therefore handles back-end development, testing, deployment and monitoring.
A typical migration path towards microservices starts with an existing monolithic application. Rather than splitting everything at once, domain areas are first identified based on business processes. A portion of the functionality is then carved out as a separate service while the monolith temporarily remains the orchestrator. Through anti-corruption layers and API gateways, interaction between old and new is controlled.
In new systems, teams sometimes choose microservices from the outset, yet there is increasing awareness of the risks of splitting too early. Breaking a system into many small services without clear domain boundaries leads to a so-called distributed monolith: the benefits of microservices do not materialise, while the complexity of a distributed system is very much present. It is therefore common to first create a clear domain model and modular design, and only then decide which parts are sufficiently mature and stable to run as independent services.
A schematic view of a simple microservice environment might look like this.
[Client]
|
[API Gateway]
| \
[Order Service] [User Service] [Inventory Service]
| | |
[Order DB] [User DB] [Inventory DB]
\ | /
---> Event Bus / Message Broker
In this diagram, the API gateway serves as the entry point for clients. The individual services have their own databases and exchange information via an event bus or message broker.
What exactly is microservice architecture
Microservice architecture is a software-architecture style in which an application consists of multiple small, independent services, each implementing a specific business capability. These services run separately, have their own data storage and communicate through well-defined interfaces, allowing them to be developed, deployed and scaled individually.
How does microservice architecture differ from a monolithic architecture
In a monolithic architecture, all functionality is combined in one codebase and deployed as a single package. With microservices, functionality is broken down into multiple services, each with its own codebase, deployment and often its own database. This makes the structure more flexible but increases complexity in communication, monitoring and error handling.
What are the main advantages of microservices
Key advantages include targeted scalability, team independence and greater agility when making changes. Services can be updated individually without redeploying the whole application, and different technologies can be chosen per service. This is particularly attractive in large organisations with multiple teams working in parallel.
What are the biggest disadvantages of microservice architecture
The main disadvantages lie in operational complexity. There are more deployables to manage, network communication introduces latency and failure scenarios, and data consistency between services becomes more challenging. A microservice landscape also demands a mature DevOps culture, advanced observability tooling and clear agreements on interfaces and versions. Without these prerequisites, the system can become difficult to control.
When is microservice architecture an appropriate choice
Microservice architecture is most suitable for larger systems with multiple teams where scalability, flexibility and rapid iteration are critical. If the domains can be clearly separated and there is sufficient expertise and tooling for distributed systems, the model can offer significant benefits. For smaller applications or teams, a modular monolithic design is often simpler and more effective.
How are data and transactions managed in a microservice environment
In a microservice environment, each service usually has its own database. This prevents services from directly manipulating each other’s data models but makes cross-service transactions more complex. Instead of one global transaction, techniques such as sagas, eventual consistency and the outbox pattern are used. This requires a different mindset about consistency and error handling but makes services more scalable and independent.
Which infrastructure and tools are commonly used with microservices
Microservices are typically packaged in containers, with orchestration platforms automating deployment, scaling and fail-over. Service meshes are applied for traffic management and network-level security. For observability, combinations of metrics, logging and distributed tracing are employed to show, per request, which services were invoked and where any issues arose.
Is microservice architecture always better than a monolithic design
Microservice architecture is not automatically better; it is a different approach with its own trade-offs. For small to medium-sized applications, a well-structured monolith can be more efficient and easier to manage. Microservices truly shine in large, evolving systems with clear domain boundaries and multiple autonomous teams. The choice depends on context, scale and organisational maturity.
