Direct answer: A microservice is a small, independently deployable service that handles one business capability, owns its own data, and talks to other services over a network through defined APIs. An application built from many such services is said to use a microservices architecture. Teams use them to release, scale, and fix parts of a system separately.
By [AUTHOR NAME, credentials]. Last updated: October 16, 2026.
Table of Contents
- Key Takeaways
- What does “microservice” actually mean?
- How do microservices work?
- Microservices vs. monolith vs. modular monolith
- The 5-Question Microservice Test
- A worked example: splitting an online bookstore
- Why did Prime Video simplify its design?
- Benefits and costs
- Should you use microservices? A readiness scorecard
- Common mistakes
- Best practices
- Common tools
- FAQ
- Conclusion and next steps
- Sources
Key Takeaways
- A microservice is defined by independent deployability and a single business focus, not by lines of code.
- Each microservice should own its data. Shared databases are the most common way teams accidentally build a distributed monolith.
- Microservices trade code complexity for operational complexity: network calls, monitoring, and data consistency become your problem.
- A modular monolith is often a better first step for small teams or unproven products.
- Size is a poor guide. Ownership, boundaries, and release independence are better ones.
- Even Amazon’s Prime Video team simplified one microservices-based tool when its cost and scaling limits bit.
What does “microservice” actually mean?
A microservice is one self-contained program that does one business job and can be released without redeploying anything else. Examples of such jobs are checking inventory, charging a card, or sending a receipt.
There is no single official definition. James Lewis and Martin Fowler wrote the influential 2014 article on the style precisely because the term lacked one, and they chose to describe common characteristics instead. Sam Newman’s Building Microservices (2nd edition, O’Reilly, 2021) boils it down to services that can be released independently and are modeled around a business domain.
How is a microservice different from a “service” or an “API”?
- Service: any program that provides functionality to other programs.
- API: the interface through which others request that functionality.
- Microservice: a service that is deliberately small in responsibility, independently deployable, and usually owns its data.
An API is how you talk to a microservice. It is not the microservice itself.
What traits do most definitions share?
Based on the Fowler/Lewis article, Microsoft’s Azure Architecture Center, and a Manning excerpt on .NET microservices, the recurring traits are:
- Built around one business capability
- Deployed on its own, ideally automatically
- Owns its own data store
- Communicates through well-defined interfaces
- Small enough for a small team to understand and maintain
- Replaceable without rewriting its neighbors
How do microservices work?
Each microservice runs as its own process, and services cooperate by sending requests or messages across a network. The application you see is the combined result.
What does a request look like?
- A user action reaches an entry point, often an API gateway.
- The gateway routes it to the right service.
- That service may call others synchronously (a direct request, such as HTTP) or asynchronously (a message left on a queue).
- Each service reads and writes only its own data.
- The results are combined and returned to the user.
What infrastructure usually surrounds them?
Containers package services, an orchestrator runs them, and observability tools trace requests across them. Microsoft’s guidance names Azure Kubernetes Service, Azure Container Apps, and Azure Functions as compute options. AWS’s whitepaper names Amazon ECS, EKS, Fargate, EC2, and Lambda.
Microservices vs. monolith vs. modular monolith
A monolith deploys as one unit, a microservices system deploys as many independent units, and a modular monolith is one deployable unit with strictly enforced internal boundaries.
| Factor | Monolith | Modular monolith | Microservices |
| Deployment | One unit | One unit | Many independent units |
| Internal boundaries | Often informal | Enforced in code | Enforced by the network |
| Calls between parts | In-process | In-process | Over the network |
| Data | Usually one shared database | One database, separated by module | Each service owns its data |
| Team fit | Small teams | Small to mid-size teams | Multiple teams |
| Main cost | Tangling over time | Needs discipline to keep boundaries | Operations and distributed-systems complexity |
Sources for the comparison logic: Martin Fowler’s talk as reported by InfoQ, and engineering write-ups on modular monoliths by Milan Jovanović and FullStack.
A useful nuance from the modular-monolith camp: if modules reach directly into each other’s database tables, you do not have a modular monolith, you have a monolith with folders.
The 5-Question Microservice Test
This is an original heuristic from iTechPulseHub, not an industry standard.
Run any candidate “microservice” through these questions. Fewer than four yeses suggests you have a module, not a microservice.
- Can it be released alone? If a change forces a coordinated release of other services, it fails.
- Does it own its data? If another service reads its tables directly, it fails.
- Does it map to a business capability? “Payments” passes. “Utility functions” does not.
- Can one small team understand and run it? If it takes a committee, it is too large or too tangled.
- Can it fail without taking everything down? If one outage cascades through tight call chains, it is not isolated.
A worked example: splitting an online bookstore
This example is fictional and illustrative.
Imagine a small bookstore app, one codebase, one database. Orders slow down every Friday evening, but the catalog and blog stay quiet.
- Spot the pressure. Checkout needs more capacity than anything else. That is a concrete driver, not a fashion choice.
- Draw the boundary. Checkout and payment become a candidate service. Catalog and accounts stay put.
- Separate the data. Move payment records to their own store. The main app asks the payment service for results instead of querying its tables.
- Automate release. Give the payment service its own deployment pipeline and monitoring.
- Stop. The app is now a monolith plus one microservice, which is a legitimate, common outcome.
The lesson: extraction should be driven by a specific need such as scaling, team ownership, or fault isolation. A desire to “use microservices” is not a need.
Why did Prime Video simplify its design?
Amazon’s Prime Video team reported cutting infrastructure costs by over 90% after consolidating one monitoring tool into a single process.
In a March 2023 post, engineer Marcin Kolny described the team’s video-quality inspection tool. It had been built from serverless components coordinated by AWS Step Functions. The team said it ran into hard scaling limits at roughly 5% of the expected load, and that the cost of the building blocks was too high for large-scale use (as reported by The Stack). Per InfoQ’s summary, the fix was to move the workload onto EC2 and ECS.
Two cautions keep this story honest:
- It is one tool, not all of Prime Video. One analysis noted that the wider platform is still built on microservices.
- The label is disputed. Amazon’s own Adrian Cockcroft framed the outcome as a long-running microservice scaled horizontally, and The Stack noted it may be one large microservice rather than a true monolith.
Kolny himself stressed that choosing between microservices, serverless, and a monolith has to be decided case by case. The takeaway is that granularity is a cost decision, not a virtue.
Benefits and costs
What do microservices do well?
- Independent releases: teams ship their own service on their own schedule.
- Targeted scaling: add capacity only where demand is.
- Fault isolation: one service can fail while others keep working, if designed for it.
- Technology choice: different services can use different languages or databases.
What do they cost?
- Network problems: calls can be slow or fail, unlike in-process calls.
- Data consistency: there are no simple cross-service transactions.
- Operational load: many deployables to monitor, secure, and version.
- Debugging difficulty: one user action may touch a dozen services.
Should you use microservices? A readiness scorecard
Original iTechPulseHub heuristic. Score 1 point per “yes.”
- Do you have more than one team that needs to release independently?
- Do you have a specific scaling or isolation problem a monolith cannot solve?
- Is deployment already automated (CI/CD)?
- Do you have centralized logging, metrics, and tracing?
- Are your domain boundaries reasonably stable?
- Is someone on the team experienced with distributed systems?
| Score | Suggestion |
| 0-2 | Stay with a well-structured monolith |
| 3-4 | Try a modular monolith; extract one service if a clear driver appears |
| 5-6 | Microservices are a reasonable option |
Martin Fowler has said he leans toward starting with a monolith when unsure and evolving later, according to a conference-talk write-up by Juri Strumpflohner.
Common mistakes
- Splitting too early, before boundaries are understood.
- Sharing one database across services.
- Chatty call chains, where one request triggers many sequential calls.
- Splitting by technical layer (a “database service,” a “UI service”) instead of by business capability.
- Skipping observability, then being unable to trace failures.
- Building a distributed monolith, where services must still be deployed together.
Best practices
- Model services around business domains. Domain-driven design helps find stable boundaries.
- Give each service its own data and a stable, versioned API.
- Automate build, test, and deployment from day one.
- Design for failure: timeouts, retries, and graceful fallbacks.
- Extract services one at a time, from a modular monolith where possible.
- Document who owns each service.
Common tools
| Need | Examples |
| Packaging | Docker |
| Running containers | Kubernetes, Amazon ECS/EKS, Azure AKS |
| Serverless option | AWS Lambda, Azure Functions |
| Traffic and security | Istio, Linkerd, Consul |
| Tracing | Jaeger, Zipkin |
Sources: AWS whitepaper Implementing Microservices on AWS; Microsoft Azure Architecture Center; Virtana glossary.
Conclusion
A microservice is best understood by what it lets you do: release, scale, and replace one business capability without touching the rest. If you cannot do that, the label does not apply, however many services you have.
