Microservices Architecture

# CHAPTER 9

Microservices Architecture #

1. Introduction #

2. Learning Objectives #

• Compare the organizational and architectural differences between Monoliths and Microservices.

• Understand the concept of "Domain-Driven Design" and Bounded Contexts.

• Explain the absolute necessity of Independent Deployments and Decentralized Data.

• Identify the staggering operational complexities (Networking, Monitoring, Failure points).

• Understand the role of "Service Discovery" in dynamic cloud environments.

3. The Monolith Bottleneck #

• The Structure: The User Interface, Business Logic (Billing, Users, Inventory), and Data Access layers are all compiled into one single application communicating with one single database.

• The Organizational Bottleneck: When 100 engineers are trying to write code in the exact same codebase simultaneously, they constantly step on each other's toes. Code reviews take weeks.

• The Scalability Bottleneck: If the 'Video Processing' feature requires massive CPU power, but the 'User Login' feature requires almost none, you cannot scale them independently. You must scale the entire massive Monolith across dozens of expensive servers.

4. Microservices (The Great Decoupling) #

• The Structure: Instead of one app, you have a User Service, a Billing Service, and an Inventory Service.

• The Rules of Microservices:

1. 1. Independent Deployments: The Billing team must be able to deploy new code at 2 PM on a Tuesday without coordinating with the User team or taking the rest of the site offline.

1. 2. Decentralized Databases: This is the hardest rule. The Billing Service must have its own isolated database. It is NOT allowed to directly query the User Service database. If it needs user data, it must make a network API call to the User Service.

1. 3. Technology Agnostic: The AI team can build their service in Python, the heavy-traffic team can use Go, and the web team can use Node.js. They all communicate via standard REST/JSON APIs.

5. The Nightmare of Operational Complexity #

• The Network is Unreliable: In a Monolith, calling a function is instant. In Microservices, calling a function means sending a network request across a data center. Network cables break, routers fail, and latency spikes. You must write complex code to handle timeouts and retries.

• Distributed Tracing: If a user clicks "Buy" and the request travels through 7 different microservices before failing, how do you know which service caused the error? You need massive, complex monitoring infrastructure to trace the logs across multiple servers.

6. Service Discovery #

• The Problem: In a modern cloud, Auto-Scaling is constantly spinning up new instances of the Billing Service and destroying old ones. Their IP addresses change every 5 minutes. The User Service cannot hardcode an IP address to talk to the Billing Service.

• The Solution: Service Discovery (e.g., Consul, Eureka). A centralized registry acts like a dynamic phone book. When a new Billing Service boots up, it registers its IP address with the Service Discovery hub. When the User Service needs to talk to Billing, it asks the hub for an active IP address.

7. Diagrams/Visual Suggestions #

[ API GATEWAY ]
      |
      |--> [ User Service (Node.js) ] ------> [ User DB (PostgreSQL) ]
      |
      |--> [ Inventory Service (Go) ] ------> [ Inventory DB (MongoDB) ]
      |
      |--> [ Billing Service (Java) ] ------> [ Billing DB (PostgreSQL) ]

*(Notice how the databases are completely isolated. No service shares a database).*

8. Best Practices #

• The Strangler Fig Pattern: Never try to rewrite a Monolith into Microservices all at once (the "Big Bang" rewrite). It guarantees failure. Instead, use the Strangler Pattern: identify one small module (like 'Notifications'), build it as a new microservice, route traffic to it via the API Gateway, and delete the old code from the Monolith. Repeat over 3 years until the Monolith is gone.

9. Common Mistakes #

• The Distributed Monolith: A team breaks their code into 10 microservices, but they all still connect to the exact same massive, shared SQL database. *The Failure:* If the database goes down, all 10 services crash simultaneously. Furthermore, if one team changes a database table structure, it breaks the code for the other 9 teams. They have all the latency of microservices, with none of the independent deployment benefits.

10. Mini Project: Map an Uber Ride #

1. 1. The Request: User opens app. API Gateway routes request to Location Service to find nearby drivers.

1. 2. The Match: Matchmaking Service uses a complex algorithm to pair the user with a driver.

1. 3. The Communication: Notification Service pushes an alert to the driver's phone.

1. 4. The Trip: Mapping Service tracks the GPS coordinates in real-time.

1. 5. The Completion: Billing Service charges the credit card and communicates with the Review Service to prompt a rating.

11. Practice Exercises #

1. 1. Define the core architectural rule of "Decentralized Databases" in a Microservices architecture. Why is it an anti-pattern for two different microservices to share the exact same database?

1. 2. Explain the immense operational cost of transitioning to Microservices. What network and monitoring complexities are introduced when you replace local function calls with network API calls?

12. MCQs with Answers #

13. Interview Questions #

• Q: A startup with 3 backend developers and a 10,000-line codebase decides they want to adopt a Microservices architecture because "Netflix does it." Walk me through the arguments you would use to convince them to stick with a well-structured Monolith.

• Q: Explain the "Strangler Fig Pattern." If you are tasked with migrating a massive legacy monolithic application to a microservices architecture, how do you execute this migration safely without risking a catastrophic rewrite?

• Q: In a microservices architecture, the Order Service needs to verify user data from the User Service. Walk me through the latency and failure implications of making a synchronous HTTP call across the network to fetch this data.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #