Module 13: Spring Cloud and Microservices

🎯 Module Objectives

By the end of this module, you will be able to:

• ✅ Understand microservices vs monolithic architecture
• ✅ Set up a Service Discovery with Eureka
• ✅ Centralize configuration with Spring Cloud Config
• ✅ Create an API Gateway with Spring Cloud Gateway
• ✅ Implement inter-service communication with Feign
• ✅ Apply resilience patterns with Resilience4j
• ✅ Understand patterns: Circuit Breaker, Retry, Rate Limiter

---

📋 Prerequisites

Before starting this module, make sure you master:

• ✅ Module 1-6: Basics of Spring Boot and Spring Data JPA
• ✅ Module 7: Transactions and configuration
• ✅ Module 8: Spring Security (to secure services)
• ✅ Module 12: Docker and deployment (to orchestrate services)
• ✅ REST API concepts
• ✅ Docker and Docker Compose (essential!)

---

🏗️ Module Architecture

---

📚 Module Plan

Theoretical Chapters

#	Chapter	Duration	Description
1	Introduction to Microservices	45 min	Monolith vs Microservices, patterns, 12-Factor App
2	Service Discovery - Eureka	1h	Eureka Server/Client, Load Balancing
3	Centralized Configuration	1h	Spring Cloud Config, Git backend, Refresh
4	API Gateway	1h15	Spring Cloud Gateway, Routes, Filters
5	Inter-Service Communication	1h30	Feign, Resilience4j, Circuit Breaker

Practical Work

#	Lab	Duration	Description
1	Eureka Server and Clients	1h30	Create the service registry
2	Config Server	1h	Centralized Git configuration
3	API Gateway	1h30	Gateway with routing and filters
4	Feign + Resilience4j	2h	Resilient communication

Estimated total duration: ~12 hours

---

🎬 Before / After this Module

❌ BEFORE (Monolithic Architecture)

┌─────────────────────────────────────────────┐
│              MONOLITH APPLICATION           │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│  │  Users  │ │Products │ │ Orders  │       │
│  └─────────┘ └─────────┘ └─────────┘       │
│  ┌─────────────────────────────────┐       │
│  │       SINGLE DATABASE           │       │
│  └─────────────────────────────────┘       │
└─────────────────────────────────────────────┘

Problems:
- One bug = entire app down
- Scaling: all or nothing
- Deployment: redeploy everything
- Technologies: single stack
- Teams: merge conflicts

✅ AFTER (Microservices Architecture)

┌──────────┐   ┌──────────┐   ┌──────────┐
│  Users   │   │ Products │   │  Orders  │
│ Service  │   │ Service  │   │ Service  │
│  :8081   │   │  :8082   │   │  :8083   │
└────┬─────┘   └────┬─────┘   └────┬─────┘
     │              │              │
     │    ┌─────────┴─────────┐    │
     └────┤   Eureka Server   ├────┘
          │      :8761        │
          └─────────┬─────────┘
                    │
          ┌─────────┴─────────┐
          │    API Gateway    │
          │      :8080        │
          └───────────────────┘

Advantages:
- Fault isolation
- Independent scaling
- Continuous deployment
- Polyglot (Java, Node, Python...)
- Autonomous teams

---

🧩 Spring Cloud Components

---

🏢 Use Case: E-Commerce Microservices

Throughout this module, we will build an e-commerce platform:

Services to Create

Service	Responsibility	Port	Database
eureka-server	Service registry	8761	-
config-server	Centralized configuration	8888	Git repo
api-gateway	Single entry point	8080	-
user-service	User management	8081	PostgreSQL
product-service	Product catalog	8082	PostgreSQL
order-service	Order management	8083	PostgreSQL
inventory-service	Product stock	8084	PostgreSQL
notification-service	Emails/SMS	8085	-

Order Flow

---

🔑 Key Concepts

1. Service Discovery (Why?)

Without Service Discovery:
- Hardcoded URLs: http://192.168.1.10:8081
- If the service moves → everything breaks
- Manual load balancing

With Eureka:
- Services register: "I am user-service"
- Clients ask: "Where is user-service?"
- Eureka responds with all instances
- Automatic load balancing

2. Centralized Configuration (Why?)

Without Config Server:
- Each service has its application.properties
- Changing a DB password = modify 10 files
- Redeploy all services

With Config Server:
- Configuration in Git
- One place to modify
- Refresh without restart
- Encryption of secrets

3. API Gateway (Why?)

Without Gateway:
- Client knows all services
- CORS to manage everywhere
- Auth to implement everywhere
- Rate limiting impossible

With Gateway:
- Single entry point
- Centralized auth
- Rate limiting
- Centralized logging
- Request/response transformation

4. Circuit Breaker (Why?)

Without Circuit Breaker:
- Service A calls Service B
- Service B is down
- Service A waits... timeout
- Cascade failure → everything down

With Circuit Breaker:
- Detects failures
- "Opens" the circuit
- Returns fallback immediately
- "Closes" when B is back

---

📦 Technical Stack

Maven Dependencies (BOM)

<!-- In the parent POM -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2023.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Compatible Versions

Spring Boot	Spring Cloud	Java
3.2.x	2023.0.x (Leyton)	17+
3.1.x	2022.0.x (Kilburn)	17+
3.0.x	2022.0.x (Kilburn)	17+

---

⚠️ When to Use Microservices?

✅ Good Reasons

• Large application with multiple teams
• Need for different scaling per component
• Well-defined business domains (Bounded Contexts)
• Need for resilience (fault isolation)
• Frequent and independent deployments

❌ Bad Reasons

• "It's trendy"
• Small project / small team
• MVP / Prototype
• Team without DevOps experience
• Limited infrastructure

💡 Golden Rule

"If you don't have the problems of a monolith, you don't need microservices."

— Martin Fowler

---

🗺️ Module Progression

---

🚀 Ready to Start?

This module is advanced and requires a good mastery of previous modules. If you are ready:

1. Install Docker (essential for this module)
2. Make sure you have 16GB+ of RAM (multiple services)
3. Prepare an IDE with Spring support (IntelliJ recommended)

Start Chapter 1: Introduction to Microservices →

---

Back to home