MICROSERVICES MENTAL MODEL

SLIDE 1: Section Intro

Section 1: Microservices Mental Model

Before learning how to design microservices, you need a clear mental model of what they actually are, what they promise, what they cost, and why they are fundamentally an organizational decision, not just a technical one.

Most engineers can say "microservices are small, independent services." That definition is incomplete and leads to poor design decisions. This section resets your understanding so that everything in the rest of the course builds on a solid foundation.

What We Will Cover:

1. What microservices actually mean (the precise definition that matters)
2. What microservices do not mean (common misconceptions that hurt you in interviews)
3. The three core promises: independent deployment, scaling, and ownership
4. The five core costs: network latency, partial failure, data inconsistency, debugging complexity, operational overhead
5. Microservices as an organizational pattern (Conway's Law)
6. How to frame microservices correctly in a system design interview

Where This Appears in Real Systems:

Every section in this course builds on the mental model established here. If you understand the promises, costs, and organizational nature of microservices, the decomposition, communication, and data ownership decisions in later sections will make intuitive sense.

SLIDE 2: What Microservices Actually Mean

A microservice is a service that meets all four of these criteria simultaneously:

1. Independently deployable - Ships without coordinating with other services
2. Owns its own data - Has a private database that no other service can access directly
3. Aligned to a business capability - Represents a real business function, not a technical layer
4. Owned by a single team - One team builds, deploys, monitors, and is on-call for it

If a service meets only two or three of these, it is not a true microservice. It might be a well-structured component, but it does not deliver the full benefits of the architecture.

Testing each property with a real example:

Consider an Order Service in a food delivery platform like DoorDash.

Common Mistake: Many teams build services that share a database. The Payments Service and the Orders Service both read from the same orders table. They can be deployed separately, but they are not truly independent because a schema change to the orders table breaks both services. This fails the "owns its own data" test.

Interview Relevance: When you say "I would use microservices" in an interview, the interviewer may ask "what makes something a microservice?" Being able to state these four properties clearly puts you ahead of most candidates.

SLIDE 3: What Microservices Do Not Mean

There are several common misconceptions about microservices that lead to poor architectural decisions, especially in interviews.

Misconception 1: "Microservices means small services"

The "micro" in microservices does not refer to lines of code. A service with 50,000 lines of code can be a well-designed microservice if it owns a single business capability end-to-end. A service with 200 lines of code can be a terrible microservice if it cannot function without calling three other services for every request.

Misconception 2: "Microservices means Docker and Kubernetes"

Docker and Kubernetes are deployment tools. You can run a monolith in Kubernetes. You can run microservices on bare metal VMs. Containers make microservices easier to operate, but they are not what makes something a microservice.

Misconception 3: "Microservices means splitting code into separate repos"

Separate repositories do not create service boundaries. You can have ten repos that are all tightly coupled and must be deployed together. That is a distributed monolith, not microservices. The boundary is about independent deployability and data ownership, not repository structure.

Misconception 4: "One microservice per database table"

This is one of the most common mistakes in interviews. If you split your User table into a User Service and your Address table into an Address Service, you have not decomposed by business capability. You have decomposed by database schema, which creates chatty services that cannot do anything useful alone.

Interview Relevance: Interviewers test whether you understand what microservices actually are. Mentioning Docker or Kubernetes as a defining trait signals a shallow understanding of the architecture.

SLIDE 4: The Core Promise of Microservices

Microservices make three promises. Every architectural benefit flows from these three properties.

Promise 1: Independent Deployment

Each service can be built, tested, and deployed without coordinating with other teams. If the Notification Service needs a bug fix, only the notifications team deploys. No release train. No waiting for the Order Service team to finish their sprint.

Promise 2: Independent Scaling

Each service scales based on its own load. In an e-commerce platform like Amazon, the Product Catalog Service handles 50x more reads than the Checkout Service. With microservices, you scale catalog reads horizontally without wasting resources on checkout infrastructure that is mostly idle.

Promise 3: Independent Ownership

One team owns one service end-to-end: the code, the data, the on-call rotation, the deployment pipeline. Ownership boundaries reduce coordination overhead. A team of 4-8 engineers can move fast because they do not need approval from six other teams to ship.

The trade-off for each promise:

• Independent deployment requires backward-compatible APIs between services
• Independent scaling requires infrastructure complexity and more moving parts
• Independent ownership requires accepting data duplication and cross-team communication overhead

Interview Tip: When an interviewer asks "why microservices?", do not just say "scalability." State all three promises and then explain which specific promise justifies the choice for the system you are designing. A system with one team and uniform load does not benefit from any of these promises.

Interview Relevance: Interviewers want to hear you justify microservices with specific architectural benefits, not repeat buzzwords. Stating the three promises and mapping them to the problem shows maturity.

SLIDE 5: The Core Cost of Microservices

Every benefit of microservices comes with a corresponding cost. These are not edge cases. These are guaranteed consequences of distributing a system across a network.

Every arrow in this diagram is a network call. Every network call can fail, time out, or return stale data. In a monolith, these would be function calls that take nanoseconds and never fail due to network issues.

The five costs:

1. Network latency - Every service call adds 1-10ms round trip. A monolith function call takes nanoseconds.
2. Partial failure - Payment succeeds but inventory reservation fails. In a monolith, a single transaction guarantees all-or-nothing.
3. Data inconsistency - The Order Service and Inventory Service can temporarily disagree about stock levels. A single database is always consistent.
4. Debugging complexity - One user request touches 5 services across 5 log streams. In a monolith, you have one process, one log file, one stack trace.
5. Operational overhead - 20 services means 20 deployment pipelines, 20 monitoring dashboards, 20 potential points of failure.

The honest math:

A monolith making 4 internal function calls to process a checkout has near-zero failure probability from those calls. The same checkout across 4 microservices making network calls, each with 99.9% availability, has a combined availability of 99.9%^4 = 99.6%. That gap of 0.4% means roughly 3.5 additional hours of downtime per year, purely from the architecture choice.

Interview Relevance: Interviewers specifically test whether candidates understand the costs of their proposals. Proposing microservices without acknowledging distributed complexity is a red flag at any level.

SLIDE 5B: Note It Down

Five Costs of Microservices (memorize these):

1. Network latency - 1-10ms per hop vs nanoseconds for in-process calls
2. Partial failure - One service can fail while others succeed
3. Data inconsistency - No shared transaction across services
4. Debugging complexity - One request, many services, many log streams
5. Operational overhead - Each service needs its own pipeline, monitoring, and on-call

When to bring these up in an interview:

Do not wait for the interviewer to challenge your microservices proposal. State the costs proactively and then explain how you will mitigate each one. This is what separates a senior-level answer from a junior-level answer.

Interview Tip: A strong pattern is: "I am choosing microservices here because [specific promise matters for this system], and I will handle the distributed complexity by [specific mitigation for each relevant cost]."

Interview Relevance: Being able to list these five costs without hesitation demonstrates practical experience with distributed systems, not just textbook knowledge.

SLIDE 6: Microservices as an Organizational Pattern (Conway's Law)

Conway's Law states: "Organizations design systems that mirror their own communication structure."

This is not a suggestion. It is an observation that has held true across decades of software engineering. If you have three teams, you will end up with three major services or three major components, regardless of what the architecture diagram says.

What this means for microservices:

Service boundaries should follow team boundaries. If the payments team and the inventory team are separate groups with separate managers, their code should live in separate services. Forcing them into one monolith creates constant merge conflicts, shared on-call rotations, and deployment dependencies that slow everyone down.

Reverse Conway Maneuver:

Smart organizations do this intentionally. Instead of letting the org chart accidentally dictate architecture, they design the ideal service boundaries first, then structure teams to match. The architecture drives the org chart, not the other way around.

Real-world example:

A company like Spotify organizes into "squads" that each own a specific product area (search, playback, recommendations). Each squad owns its own services, data, and deployment pipeline. The architecture mirrors the team structure by design, not by accident. When they need a new capability like podcast recommendations, they form a new squad and that squad builds and owns the new service.

Interview Relevance: Mentioning Conway's Law shows the interviewer you understand that microservices are an organizational decision, not just a technical one. This separates senior-level answers from junior-level answers.

SLIDE 6B: Interview Practice

Question:

You are in a system design interview. The interviewer asks you to design a food delivery platform and you immediately say "I would use a microservices architecture." The interviewer responds: "Why? Convince me."

Take 60 seconds to think about your answer before reading below.

Weak Answer:

"Microservices are the industry standard. Companies like Uber and DoorDash use them. They are more scalable and modern than monoliths."

Why this is weak: It does not explain why this specific system needs microservices. "Industry standard" and "modern" are not architectural justifications. The interviewer wants to hear reasoning specific to the problem, not an appeal to popularity.

Strong Answer:

"A food delivery platform has at least four distinct scaling profiles: restaurant search is read-heavy and spiky during meal times, order processing is write-heavy and needs strong consistency, driver dispatch is real-time and location-intensive, and payment processing has low throughput but high reliability requirements. These also map to different team specializations. Microservices let us scale each independently, deploy the dispatch system without risking the payment flow, and let specialized teams own their domain. That said, if this is an early-stage startup with one engineering team, I would start with a modular monolith and extract services as the team and load grow."

What makes this strong: The candidate identifies specific scaling profiles, maps them to independent deployment needs, acknowledges team structure, and shows maturity by not defaulting to microservices unconditionally. The closing sentence about starting with a modular monolith demonstrates real-world judgment.

SLIDE 7: Interview Framing

In a system design interview, microservices should never be your default starting point. They should be a justified design choice that you arrive at through reasoning.

The decision flow:

What interviewers look for:

• You do not jump to microservices by default
• You ask about team size, product maturity, and scaling requirements before choosing
• You can articulate which specific promise of microservices justifies the complexity
• You acknowledge the costs and explain how you will handle them
• You know that a modular monolith is a valid and often better starting point

Common Mistake: Starting every system design answer with "I would use microservices with an API gateway, message queue, and load balancer." This sounds rehearsed and shows no reasoning. The interviewer wants to see you think through the trade-offs, not recite an architecture template.

Interview Relevance: The way you frame the architecture choice in the first 2-3 minutes of an interview sets the tone. A thoughtful framing builds credibility. A default "microservices" answer without justification puts you on the defensive for the rest of the interview.

SLIDE 8: Section Summary and Interview Tips

Section 1 Summary:

Common Interview Mistakes:

Key Numbers to Remember:

How This Connects to Other Sections:

Section 2 (Monolith to Microservices) builds directly on this mental model. You will see how monoliths, modular monoliths, and distributed monoliths compare against the four properties from Slide 2. Section 3 (Service Decomposition) uses the "aligned to a business capability" property as the foundation for finding service boundaries. Section 5 (Data Ownership) expands on the "owns its own data" property and explores what happens when services need each other's data. Section 6 (Sagas and Consistency) addresses the "partial failure" cost from Slide 5 and teaches you how to handle transactions that span multiple services.