What Is a Microservice? Architecture, Benefits, and Trade-offs
Leslie Tsang
December 14, 2022
A microservice is a small, independently deployable service that owns a specific business capability and communicates with other services through APIs or messaging. Microservices can improve team autonomy and scalability, but they also introduce operational complexity around networking, observability, security, and versioning.
To be clear, there is no one-size-fits-all architecture; there is no best and worst architecture as well, only the most suitable one for your business.
What Is a Microservice?
Microservices architecture structures an application as services that can be developed and deployed independently around business capabilities. It can make selected changes and scaling decisions more independent, but it does not automatically make a system easier to operate.
The fundamental idea behind microservices is to split a large software system into multiple, relatively independent services and each service focuses on a single functionality.
Services in a microservice architecture are often processes that communicate over a network to fulfill a goal using technology-agnostic protocols such as HTTP or gRPC, which makes it possible for different services to be combined on demand to meet various business needs.
Evolution of Software Architecture
Let's start with using the monolithic architecture as a startup architecture. See what problems are encountered with different architectures as the business grows over time.
Monolithic Architecture
In a monolithic architecture, an application is delivered as one primary deployment unit. Its internal modules can be well separated or tightly coupled; a modular monolith preserves explicit boundaries without introducing a network call between every capability.
A single deployment unit can simplify local development, testing, transactions, and operations for one team. The trade-off is that independently changing or scaling one capability may require releasing or scaling the whole unit. Rolling updates are possible when the runtime and deployment platform support them, but the release blast radius can be larger.
In-process calls can avoid network overhead, while one process can be easier to debug end to end. Actual throughput and test complexity depend on the language, framework, module boundaries, data access, and workload.
Because the deployment unit is shared, a change normally passes through the monolith's release pipeline even when only one module changes. Incremental builds, modular tests, and automated rolling or canary deployment can keep that workflow fast; a poorly structured codebase or slow pipeline can make changes more coupled.
Maintaining module boundaries requires deliberate ownership and architecture tests. Horizontal scaling typically replicates the deployment unit, which can waste resources when only one capability is hot; vertical scaling or selective extraction may be sufficient before adopting many distributed services.
Service-Oriented Architecture
Service-oriented architecture (SOA) organizes business capabilities behind service contracts so they can be composed and reused across applications or an enterprise. Implementations may use HTTP, SOAP, messaging, an enterprise service bus (ESB), or other integration patterns; an ESB is not a requirement that defines SOA.
SOA can reduce point-to-point integration and establish shared contracts, but its deployment independence and coupling depend on service boundaries, governance, shared infrastructure, and data ownership. A service boundary alone does not make an update risk-free or a system more reliable.
Potential SOA benefits include reusable contracts, clearer integration boundaries, and parallel work where services have independent ownership and delivery. Those benefits are conditional: shared schemas, centralized middleware, coordinated releases, or a shared database can still couple teams and failures.
Microservice Architecture
Microservice architecture is a service-oriented style that organizes an application around small, bounded services intended to be changed and deployed independently. Services communicate over explicit network contracts, but they can use synchronous APIs, asynchronous messages, or both.
SOA and microservices overlap; neither architecture is defined by one protocol, middleware product, or database layout. In practice, SOA programs often emphasize enterprise integration and shared governance, while microservice programs tend to emphasize bounded contexts, decentralized ownership, and independent delivery. These are tendencies, not universal rules.
Additional differences, are summarized in the chart below:
| Dimension | SOA tendency | Microservice tendency |
|---|---|---|
| Scope | Enterprise integration and reusable business services | One product or domain divided into bounded capabilities |
| Service boundary | Often broader services shared by several applications | Smaller services aligned with bounded contexts and team ownership |
| Deployment | Can be independent or coordinated around shared middleware and contracts | Independent deployment is a central design goal |
| Governance | More centralized standards and shared integration governance | More decentralized technology choices within organization-wide guardrails |
| Communication | HTTP, SOAP, messaging, ESB, or other integration patterns | HTTP, gRPC, events, or messaging, chosen per interaction |
| Data ownership | Shared or service-owned data, depending on the design | Service-owned data is preferred, with explicit consistency trade-offs |
| Team model | Enterprise integration or capability teams | Cross-functional teams owning build and operation of a bounded service |
Overview of a typical microservice's deployment
Scaling strategies for monolithic architecture and microservice architecture
For a deeper description of the architectural characteristics, see Martin Fowler's article on microservices.
Compared with a monolith, well-bounded microservices can let teams test, deploy, and scale selected services independently. Those benefits depend on clear contracts, service ownership, automation, and operational maturity. Not every service needs its own database, and distributing an application adds network and consistency failure modes.
Why Microservices Are Needed
Microservices are useful when independent teams need to change, deploy, or scale different business capabilities at different rates. They can also help isolate some failures when service boundaries, timeouts, retries, and degradation paths are designed deliberately.
They are not a default upgrade from a monolith. Every remote call introduces latency and another failure mode; data consistency, debugging, testing, and security become distributed concerns. A modular monolith is often the simpler starting point when one team owns the system or when boundaries are still changing quickly.
The Benefits of Microservices
Potential benefits of microservices include the following. Each one requires supporting engineering practices rather than following automatically from the architecture.
- Modularity: A large software system is split into several relatively independent services, each of which is responsible for accomplishing a specific function. This allows different services to be combined on demand to meet different business needs.
- Scalability: An important advantage of microservices architecture is scalability. Because each service is relatively independent, it is possible to dynamically scale up or down each service according to actual needs. This makes it possible to better cope with fluctuations in business traffic.
- Deployability: The microservices architecture allows each service to be deployed independently and in a flexible manner. This allows new features to be deployed more quickly and allows for rapid iteration without affecting the overall system.
- Failure isolation: A failure can be contained to one service when dependencies have bounded timeouts and callers can degrade safely. Poor coupling can still create cascading failures.
- Focused ownership: A smaller service can be easier for one team to understand, but a large number of services increases platform and coordination costs.
- Technical choice: Teams may choose different implementation technologies behind stable contracts. Limit unnecessary variation because every runtime adds maintenance, security, and observability work.
Microservices Trade-offs
| Trade-off | Operational implication |
|---|---|
| Network communication | Design timeouts, retries, idempotency, and backpressure; assume partial failures occur |
| Distributed data | Decide where consistency is required and how events or compensating actions recover failures |
| Independent releases | Maintain compatible contracts, versioning rules, and automated deployment checks |
| More deployable units | Standardize logs, metrics, traces, secrets, configuration, and incident ownership |
| Team autonomy | Keep service and data ownership explicit to avoid a distributed monolith |
Choose microservices when these costs are justified by independent ownership, release cadence, or scaling needs. Choose a modular monolith when simpler deployment and transactions are more valuable than independent service operation.
Microservice Architecture Checklist
| Area | What It Means | Why It Matters |
|---|---|---|
| Service boundary | Own one business capability and data model | Avoids distributed monoliths |
| API contract | Define clear REST, gRPC, or event contracts | Keeps teams independent |
| Gateway and observability | Manage traffic, auth, rate limits, metrics | Makes distributed systems operable |
For gateway patterns, see what is an API gateway and API gateway vs load balancer.
FAQ
What is a microservice?
A microservice is an independently deployable service focused on a specific business capability.
How do microservices communicate?
Microservices communicate through APIs such as REST or gRPC, asynchronous messages, events, or queues.
Why do microservices use API gateways?
An API gateway can centralize supported routing, authentication, rate limiting, transformation, and telemetry policies at a shared traffic boundary. Services still own business authorization, data validation, and domain behavior.
Summary
Microservices are an organizational and operational architecture choice, not only a way to split code. Start with clear business boundaries and ownership, then prove that independent deployment or scaling is worth the cost of a distributed system. If a shared traffic boundary is part of the design, review what an API gateway does and which responsibilities must remain in each service.
