Free lesson · Microservices Interview
What Microservices Actually Are (And What They Are Not)
What Microservices Actually Are (And What They Are Not)
Every candidate who walks into a system design interview can say the word "microservices." Most of them cannot define it precisely. They use it as a synonym for "not a monolith," which is like defining a house as "not a tent" - technically not wrong, but useless for architecture.
This lesson gives you a precise, opinionated definition of what microservices are, grounded in where they came from and what properties they must have to earn the name. By the end, you will be able to define microservices in a way that demonstrates architectural depth in the first 60 seconds of an interview - before you have drawn a single box on the whiteboard.
The Definition That Actually Matters
A microservices architecture is a collection of small, independently deployable services, each owning its own data, organised around business capabilities, communicating through well-defined interfaces, and operated by small teams that own the full lifecycle from development through production.
Every word in that definition carries weight. Let me break it down.
Independently Deployable
This is the single most important property. If you take nothing else from this lesson, take this: if your services cannot be deployed independently of each other, you do not have microservices. You have a distributed monolith.
Independent deployability means that a change to Service A can go to production without requiring a simultaneous change to Service B, Service C, or any other service. The deployment unit is the individual service, not the system. This requires that services communicate through stable, versioned interfaces rather than sharing code, databases, or in-memory state.
At Amazon, this property is non-negotiable. Every service team owns their deployment pipeline. They deploy when they are ready, not when every other team is ready. The consequence is radical: Amazon deploys changes to production every 11.7 seconds on average. That velocity is only possible because each deployment is scoped to a single service with a well-defined blast radius.
Interview: When an interviewer asks "what are microservices," lead with independent deployability. It is the property that unlocks every other benefit - team autonomy, technology heterogeneity, independent scaling, fault isolation. If you define microservices as "small services," the interviewer learns nothing about your understanding. If you define them as "independently deployable services, each owning their own data," the interviewer immediately knows you understand the architectural implications.
Owns Its Own Data
Each service owns a private data store that no other service can access directly. No shared databases. No direct SQL queries across service boundaries. If Service B needs data that Service A owns, it requests it through Service A's API - it does not reach into Service A's database.
This is the property that creates the most pain and the most architectural complexity. It is also the property that makes independent deployability possible. If two services share a database, a schema change in one can break the other. Their deployments are coupled through the data layer even if their code is separate. Shared databases are the most common way teams accidentally build a distributed monolith.
graph LR
subgraph Wrong["Shared Database - Distributed Monolith"]
A1["Order Service"] --> DB1["Shared DB"]
B1["Inventory Service"] --> DB1
C1["Payment Service"] --> DB1
end
subgraph Right["Database Per Service - True Microservices"]
A2["Order Service"] --> DB2["Orders DB"]
B2["Inventory Service"] --> DB3["Inventory DB"]
C2["Payment Service"] --> DB4["Payments DB"]
A2 <-->|"API"| B2
A2 <-->|"API"| C2
end
This diagram contrasts two architectures. On the left, three services - Order, Inventory, and Payment - all connect to a single shared database, creating a distributed monolith. On the right, each service has its own private database, and services communicate through APIs instead of through the database. The right-side architecture is true microservices with data ownership.
We will spend an entire module on data management (Module 05) because the consequences of this property - distributed transactions, eventual consistency, sagas, the outbox pattern - are where the real engineering complexity lives. For now, understand that data ownership is not a nice-to-have. It is a defining characteristic.
Organised Around Business Capabilities
Services are not organised around technical layers (a "database service," a "logging service," a "authentication service"). They are organised around business capabilities - the things the organisation does. An order service. A payment service. A shipping service. An inventory service.
This distinction matters because business capabilities are stable over time in a way that technical layers are not. The business will always need to process payments, even if the payment processing technology changes from credit cards to cryptocurrency. Organising around the capability means the service boundary survives technology changes. Organising around the technology means the boundary breaks every time the stack evolves.
This principle comes directly from Domain-Driven Design, which we cover in depth in Module 02. The connection is important: DDD provides the tools (bounded contexts, aggregates, context maps) for identifying what the business capabilities actually are. Microservices provide the deployment architecture for making each capability independently operable.
Communicating Through Well-Defined Interfaces
Services interact through explicit contracts - REST APIs, gRPC interfaces, message schemas, event formats. The contract is the boundary. Everything behind the contract is an implementation detail that the consuming service should not know about and does not depend on.
This is how independent deployability is maintained over time. As long as Service A continues to honour its published contract, Service B does not care whether Service A rewrote its internals in a different language, migrated to a different database, or restructured its codebase. The contract is the stable point. Everything else can change.
Important: The interface contract is the most important artifact in a microservices architecture. More important than the code. More important than the database schema. If the contract is well-designed and stable, teams can work independently. If the contract is poorly designed or changes frequently, every downstream service is in constant catch-up mode, and independent deployability becomes fiction.
Operated by Small Teams
This is the organisational property that most definitions underemphasise. Microservices are not just a technical architecture - they are an organisational model. Each service is owned by a team small enough to be fed by two pizzas (Amazon's original framing) or, more precisely, small enough that every team member understands the full service: its code, its data model, its operational behaviour, its failure modes, its SLOs.
The team owns the service end-to-end. They build it, they test it, they deploy it, they operate it in production, they get paged when it breaks at 2 AM. This ownership model - sometimes called "you build it, you run it" - is what aligns incentives. A team that gets paged for their own bugs writes different code than a team that throws code over the wall to an operations group.
What Microservices Are Not
Equally important is being clear about what does not qualify, because candidates frequently conflate microservices with adjacent but distinct concepts.
Not Just "Small Services"
The name "microservices" is actively misleading. The "micro" suggests that size is the defining characteristic. It is not. A service with 500 lines of code that shares a database with three other services is not a microservice - it is a small piece of a distributed monolith. A service with 50,000 lines of code that owns its data, deploys independently, and is operated by a single team is a microservice.
Size is a secondary property that emerges from good decomposition, not a goal in itself. When we discuss service granularity in Module 02, we will see that making services too small creates as many problems as making them too large - the "nanoservice" anti-pattern where you end up with hundreds of tiny services that cannot do anything useful without calling five other services first.
Not a Distributed Monolith
A distributed monolith is a system that has been broken into separate deployable units but retains the coupling characteristics of a monolith. The services share a database, or they must be deployed together because of tightly coupled APIs, or a change in one service requires coordinated changes across multiple other services.
Distributed monoliths carry the costs of both architectures - the operational complexity of distributed systems and the coupling constraints of a monolith - while delivering the benefits of neither. They are the most common failure mode of microservices adoption, and they happen when teams decompose their codebase without decomposing their data model and their deployment pipeline.
graph TD
subgraph DM["Distributed Monolith - Worst of Both Worlds"]
S1["Service A"] --> DB["Shared DB"]
S2["Service B"] --> DB
S3["Service C"] --> DB
S1 -->|"Synchronous\nChain"| S2
S2 -->|"Synchronous\nChain"| S3
Deploy["Must Deploy\nAll Together"]
Deploy -.-> S1
Deploy -.-> S2
Deploy -.-> S3
end
This diagram shows a distributed monolith where three services share a single database and are connected by synchronous call chains. A deployment box shows that all three services must be deployed together, illustrating how the system has the complexity of distribution but the coupling of a monolith.
Warning: The distributed monolith is not a stepping stone toward microservices. It is a failure state. Teams that say "we will share the database for now and split it later" almost never split it later. The coupling calcifies. New features are built on cross-service database queries. Splitting later becomes a multi-quarter migration project. If you are going to do microservices, do database-per-service from day one. If that cost is too high, stay with a monolith until you are ready.
Not SOA with Smaller Services
Service-Oriented Architecture and microservices are related but not identical. We cover the full taxonomy in a dedicated lesson later in this module. The short version: SOA typically involves larger services, an Enterprise Service Bus (ESB) for communication, and centralised governance. Microservices involve smaller services, lightweight communication (REST, gRPC, async messaging), and decentralised governance where each team makes its own technology choices.
The distinction that matters for interviews is not the historical taxonomy. It is the governance model. SOA centralises. Microservices decentralise. That single difference drives most of the other differences - deployment independence, technology heterogeneity, team autonomy, and the operational complexity that comes with all three.
Not a Silver Bullet
Microservices solve specific problems - scaling development teams, enabling independent deployment, isolating failures, allowing technology heterogeneity. They create other problems - distributed data management, network latency, operational complexity, debugging difficulty, eventual consistency, and significantly higher infrastructure costs.
The honest framing is this: microservices are an organisational scaling strategy that trades operational simplicity for team independence. If you have a small team (under 20 engineers), a monolith is almost certainly the right architecture. The coordination overhead of microservices is not worth paying when ten people can fit in a room and communicate directly.
This is not a theoretical position. It is what I have observed across 16 years and four companies. The companies where microservices created the most value - Amazon, Netflix, Uber - are companies with hundreds or thousands of engineers working on the same product. The microservices architecture allowed those teams to work independently. A ten-person startup does not have that problem.
The Amazon Origin Story
You cannot fully understand microservices without understanding where they came from, and the most important origin point is Amazon.
In 2002, Jeff Bezos sent an internal memo - now famous as the "Bezos API Mandate" - that required every team at Amazon to expose their functionality through service interfaces. No direct database reads. No shared-memory access. No back-door communication. Every piece of data, every capability, every function had to be available through an API. The mandate ended with: "Anyone who doesn't do this will be fired."
The mandate was not about technology. It was about organisation. Bezos understood that as Amazon grew, the monolithic codebase would become a coordination bottleneck. Every feature change required understanding the entire system. Every deployment was a company-wide event. Every team was blocked by every other team.
The solution was to make each team's work accessible only through an API - which meant each team could change their implementation without breaking anyone else, deploy on their own schedule, and own their service end-to-end. The technical architecture (services communicating through APIs) was a consequence of the organisational goal (team independence at scale).
Interview: The Amazon origin story is powerful in interviews because it illustrates a principle: microservices are fundamentally an organisational solution, not a technical one. If an interviewer asks you why microservices exist, the strongest answer is not "because they scale better" (monoliths can scale). It is "because they allow large engineering organisations to ship independently." That framing immediately signals that you understand microservices at the architectural level, not just the implementation level.
This is also why Conway's Law - the idea that system architecture mirrors organisational communication structure - is so central to microservices thinking. We dedicate a full lesson to Conway's Law and organisational readiness later in this module.
The Properties That Matter for Interviews
When you walk into a system design interview, you need a mental model of microservices that is both precise and practical. Here is the framework I recommend.
graph TD
M["Microservices\nDefining Properties"] --> ID["Independent\nDeployability"]
M --> DO["Data\nOwnership"]
M --> BC["Business Capability\nAlignment"]
M --> WI["Well-Defined\nInterfaces"]
M --> TO["Team\nOwnership"]
ID --> B1["Each service deploys\non its own schedule"]
DO --> B2["Each service owns\nits private data store"]
BC --> B3["Boundaries follow domain\nconcepts, not tech layers"]
WI --> B4["Contracts are stable\nimplementation is hidden"]
TO --> B5["Small team owns build,\ndeploy, and operate"]
This diagram shows the five defining properties of microservices. Independent Deployability means each service deploys on its own schedule. Data Ownership means each service owns its private data store. Business Capability Alignment means boundaries follow domain concepts, not technical layers. Well-Defined Interfaces means contracts are stable and implementation is hidden. Team Ownership means a small team owns the build, deploy, and operate lifecycle.
When you propose a microservices architecture in an interview, you should be able to check each of these five properties against your design. If your proposed architecture violates any of them - services sharing a database, services requiring coordinated deployments, boundaries drawn along technical layers - you either need to fix the violation or acknowledge it as a conscious trade-off with a specific reason.
The strongest candidates are not the ones who draw the most boxes on the whiteboard. They are the ones who draw fewer boxes, with clear boundaries, and who can explain why each boundary exists and what property it preserves.
Tip: A practical interview technique: After sketching your initial architecture, pause and say to the interviewer: "Let me verify my decomposition against the key microservices properties. Each of these services owns its own data - the order service uses a relational database for transactional integrity, the product catalog uses a document store optimised for reads. They communicate through defined APIs and can be deployed independently. The order team and the product team can ship on different schedules." This kind of explicit verification demonstrates disciplined architectural thinking and takes 30 seconds.
What Comes Next
This lesson gave you the definition and the properties. The next lesson puts microservices next to the architecture they are most often compared against - the monolith - and examines the real tradeoffs between them. Not "monoliths are bad and microservices are good," which is what most content implies. The actual engineering tradeoffs that determine which architecture is the right choice for a given system at a given scale with a given team.