Chapter 01: The Microservices Architecture

"If you can't build a monolith, what makes you think you can build microservices?" - Kelsey Hightower

Congratulations. You have mastered the Monolith. You can build a single, powerful binary that does everything. But what happens when your shop gets too big? What if the "User Management" team wants to release every day, but the "Billing" team only releases once a month?

Welcome to Microservices.

1. The Monolith vs Microservices

The Monolith (The Castle) 🏰

Everything is in one big building.

• Pros: Easy to deploy (copy 1 file), easy to debug (one stack trace), fast communication (function calls).
• Cons: If the kitchen catches fire, the whole castle burns down. If you want to upgrade the bedroom, you have to rebuild the whole castle.

Microservices (The City) 🏙️

A collection of small, independent buildings connected by roads (Network).

• Pros:
  • Independence: The Fire Station can upgrade its trucks without asking the Library.
  • Resilience: If the Bakery burns down, the Bank is still open.
  • Scaling: If lots of people want bread, we just build more Bakeries (not more Libraries).
• Cons:
  • Network: Driving between buildings takes time (Latency).
  • Complexity: You need a Map (Service Discovery) and Traffic Rules (API Gateway).
  • Failures: What if the road is blocked?

2. When to Switch?

Do NOT start with Microservices. Start with a Modular Monolith (what we built in Level 2). Switch only when:

1. Scale: You have >50 developers working on the same code.
2. Traffic: One part of your app receives 100x more traffic than the rest.
3. Complexity: The domain is too big to fit in one brain.

3. The Visual Signal (The City States) 🗺️

Concept: Distributed Systems & Autonomy. Signal: Independent City States trading with each other.

The Golden Rule of Data

In a Monolith, everyone shares the database. In Microservices, Database Sharing is Illegal.

• The User Service owns the User DB.
• If the Billing Service wants user data, it MUST ask the User Service (via API). It cannot touch the User DB directly.
• If you share the database, you still have a Monolith (a "Distributed Monolith"), but with network latency.

4. What we will build

We are going to extract the Delivery Logic into a separate service called GoTracker.

• Gopher Shop: Handles Orders.
• GoTracker: Handles Shipping.
• Communication: Kafka (Async Messaging).

Ready to be an Architect? Let's talk about Concurrency Patterns.