Chapter 01: The Microservices Architecture

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

The previous chapters introduced a teaching monolith. Before attempting this optional extension, verify that you can run it, explain its data flow, and test its failure paths. 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: Separate processes can isolate some failures, but synchronous dependencies, shared infrastructure, and retries can still cause cascading failures.
  • 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. Independent deployment solves an observed team constraint.
2. A measured bottleneck benefits from separate scaling.
3. Ownership boundaries and operational capacity justify network, consistency, and deployment costs.

There is no universal developer-count or traffic-ratio threshold. A modular monolith can also have clear ownership and scale horizontally.

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, each service should have an explicit data ownership boundary. Sharing tables couples deployment and schema changes; using the same database server does not by itself determine the architecture.

• 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.