Skip to main content
System Design Interview
CHAPTER 09 Beginner

Microservices Architecture

Updated: May 18, 2026
5 min read

# CHAPTER 9

Microservices Architecture

1. Chapter Introduction

For the first 20 years of the web, almost every application was a "Monolith"—a single massive codebase containing the UI, business logic, and database access. Today, FAANG companies and modern startups utilize "Microservices." In an interview, confidently explaining *why* and *when* to break a monolith into microservices demonstrates senior architectural maturity. This chapter covers the tradeoffs of microservices, independent scaling, and the nightmare of distributed data.

2. The Monolithic Architecture

A Monolith is an application where all components (Authentication, Billing, User Profiles, Notifications) are bundled into a single deployable unit (e.g., one massive Node.js app or one giant Java .war file).

*Pros of a Monolith:*

  • Easy to develop, test, and deploy (one codebase).
  • Fast internal communication (function calls in memory, not network requests).
  • Perfect transactional consistency (one database).

*Cons (The Scaling Wall):*

  • The "Spaghetti" Problem: As 100 developers add code, it becomes an unmaintainable, tightly coupled mess.
  • Scaling Inefficiency: If the "Billing" module requires massive CPU, you cannot scale just Billing. You must duplicate the *entire* massive monolith across 10 servers.
  • Fragility: A memory leak in the "Notifications" module crashes the entire application, taking down "Billing" with it.

3. The Microservices Architecture

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services.
  • User Service (Owns user data, runs in Node.js, uses MongoDB)
  • Billing Service (Owns payments, runs in Java, uses PostgreSQL)
  • Notification Service (Owns emails/SMS, runs in Python)

*Pros of Microservices:*

  • Independent Scaling: If Billing needs more power, you scale the Billing Service to 10 nodes while leaving the Notification Service at 2 nodes.
  • Technology Agnosticism: Each service can be written in a different language and use a different database optimized for its specific task.
  • Fault Isolation: If the Notification Service crashes, users can still log in and pay for items.

4. The Tradeoffs (Microservices are hard)

*“Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.” - Martin Fowler*

Microservices solve organizational and scaling problems, but they introduce massive operational complexity:

  • Network Latency: Internal function calls are replaced by HTTP/gRPC network requests, adding milliseconds of latency to every action.
  • Distributed Transactions: If creating a user requires updating the User DB and the Billing DB, and the network fails in the middle, rolling back a distributed transaction is incredibly difficult (requires patterns like Saga).
  • Deployment Nightmare: You are no longer deploying 1 app; you are deploying, monitoring, and orchestrating 50 independent apps using tools like Kubernetes.

5. Service Discovery

If you have 10 nodes running the Billing Service, and they are dynamically scaling up and down based on traffic, their IP addresses are constantly changing. How does the User Service know what IP address to call? *Solution:* Service Discovery (e.g., Consul, Zookeeper, Eureka). It acts as an internal phonebook. When a new Billing node boots up, it registers its IP with the Service Discovery registry. When the User service needs to call Billing, it asks the registry for a healthy IP address.

6. Data Segregation (The Golden Rule)

The most critical rule of Microservices: Every Microservice must own its own Database. The User Service should NEVER execute a SQL query directly against the Billing Database. If it needs billing data, it must make an API request to the Billing Service. *Why?* If multiple services access the same database, they become tightly coupled. If you change a table schema for Billing, you will accidentally break the User Service.

7. Real-World Scenario: Breaking the Monolith

*Interview Prompt:* You have a monolithic E-commerce app. The marketing team sends an email blast. 100,000 users log in just to browse products. The massive CPU load of browsing causes the Checkout system to lag, and active buyers cannot pay. *The Microservice Fix:* Break the monolith. Extract the "Product Catalog" into a read-heavy microservice (scaled to 50 nodes with a NoSQL DB). Extract "Checkout/Billing" into a separate, highly secure microservice (scaled to 5 nodes with a SQL DB). Now, heavy browsing traffic completely bypasses the Checkout servers.

8. Visual Explanation: The Architecture Shift

text
12345678910111213 
MONOLITH:
[ API Gateway ]
       |
[ Giant App (Auth + Catalog + Billing) ] ---> [ One Giant MySQL DB ]

MICROSERVICES:
[ API Gateway ]
       |
  +----+----+----+
  |         |    |
[Auth] [Catalog] [Billing]
  |         |    |
[DB 1]   [DB 2] [DB 3]

9. Mini Project: Map the Services

Think of Netflix. Break the system down into at least 4 distinct microservices. *Example:*
  1. 1. User/Authentication Service
  1. 2. Video Metadata/Search Service
  1. 3. Recommendation Engine Service
  1. 4. Video Streaming/CDN Routing Service

10. Common Mistakes

  • The Distributed Monolith: Breaking the code into 5 services, but having them all point to the exact same MySQL database. You gain the network latency of microservices but keep the tight coupling of a monolith. This is the worst of both worlds.
  • Microservices too early: Starting a tiny side-project with 15 microservices and Kubernetes. You will spend 90% of your time managing infrastructure instead of building features. Always start with a well-structured Monolith.

11. Best Practices

  • Idempotency: Because network calls fail, services will often retry requests. Ensure your APIs are idempotent (calling "Charge User $10" twice due to a network retry should only charge them once).

12. Exercises

  1. 1. Explain why Microservices allow teams to deploy code faster than in a Monolith environment.
  1. 2. If the Billing Service goes offline, how should the User Service handle a request to view a user's invoice history? (Hint: Graceful degradation).

13. MCQs

Question 1

What is the defining characteristic of a Monolithic architecture?

Question 2

What is the primary scalability benefit of a Microservices architecture?

Question 3

Which of the following is a major tradeoff (negative) of adopting Microservices?

Question 4

What is the Golden Rule of database design in a Microservices architecture?

Question 5

In a distributed architecture where servers are constantly scaling up and down, how do microservices find each other's IP addresses?

Question 6

What is a "Distributed Monolith"?

Question 7

Why is "Fault Isolation" a benefit of microservices?

Question 8

What does making an API "Idempotent" mean, and why is it crucial in microservices?

Question 9

When should a startup absolutely AVOID using microservices?

Question 10

How does Technology Agnosticism benefit teams in a microservices environment?

14. Interview Questions

  • Q: "You are designing Uber. If the 'Driver Location' microservice goes down, how should the 'Ride Request' microservice handle it? Explain graceful degradation."

15. FAQs

  • Q: Are containers (Docker) related to Microservices?
A: Yes. Microservices are an architectural concept. Docker is the tool used to package each microservice so it can be easily deployed and scaled independently across a cluster (using Kubernetes).

16. Summary

Microservices solve the organizational and scaling bottlenecks of massive monolithic applications. By splitting the app into independent, stateless services that own their own databases, teams can scale specific functions and deploy code rapidly. However, this introduces the complexity of network latency, service discovery, and distributed transactions. In an interview, always start with a monolithic design and explicitly state the bottlenecks that justify extracting a microservice.

17. Next Chapter Recommendation

When microservices talk to each other directly via HTTP, the system becomes tightly coupled. What if we want them to talk asynchronously? In Chapter 10: Message Queues and Event-Driven Systems, we will explore Kafka, RabbitMQ, and how to decouple your architecture.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter API Design and Communication Protocols
Next Chapter Message Queues and Event-Driven Systems

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

🗺️ Related Roadmaps 1