Microservices Architecture

Microservices is one of the most asked topics in PRA and Sprints 3-4. The questions are mostly conceptual — understanding the architecture, components, and when to use what. You won't be asked to build a full microservices system, but you need to know Spring Cloud annotations and the role of each component.

1. What are Microservices?

Microservices is an architectural style where an application is built as a collection of small, independent services, each running in its own process and communicating via lightweight mechanisms (usually HTTP/REST).

Each service does ONE thing well — it has a single responsibility, its own database, and can be deployed independently.

2. Monolithic vs Microservices (ALWAYS ASKED)

This is the most frequently asked comparison in TCS ILP exams. Memorize this table — at least 1-2 questions will come from here.

Monolithic Architecture

The entire application is built as a single deployable unit. All features — UI, business logic, data access — are in one codebase, one project, one WAR/JAR file.

Microservices Architecture

Each feature is its own independently deployable service. User management is one service, payment is another, notifications is another. Each has its own codebase, database, and deployment pipeline.

When to use Monolith?

• Small application with limited functionality
• Small development team
• Quick prototype / MVP
• No need for independent scaling

When to use Microservices?

• Large, complex application
• Multiple teams working in parallel
• Need to scale specific features independently
• Different parts need different technologies
• High availability is critical

3. Key Characteristics of Microservices

These are the defining features of microservices architecture. Exam asks "which of the following is a characteristic of microservices?"

4. Microservices Architecture Components

A microservices system isn't just services — it needs supporting infrastructure. Know each component's role.

         ┌──────────────┐
         │    Client     │  (Browser / Mobile App)
         └──────┬───────┘
                │
         ┌──────▼───────┐
         │  API Gateway  │  (Single entry point)
         └──────┬───────┘
                │
    ┌───────────┼───────────┐
    │           │           │
┌───▼───┐ ┌────▼────┐ ┌────▼────┐
│ User  │ │ Order   │ │ Payment │  (Microservices)
│Service│ │ Service │ │ Service │
└───┬───┘ └────┬────┘ └────┬────┘
    │          │           │
┌───▼───┐ ┌────▼────┐ ┌────▼────┐
│User DB│ │Order DB │ │Pay DB   │  (Each owns its DB)
└───────┘ └─────────┘ └─────────┘

    All services register with:
    ┌────────────────────┐
    │  Service Registry  │  (Eureka Server)
    │  (Eureka)          │
    └────────────────────┘

    Config loaded from:
    ┌────────────────────┐
    │   Config Server    │  (Centralized config)
    └────────────────────┘

5. Communication Between Services

Services need to talk to each other. There are two main approaches:

Synchronous Communication

Service A calls Service B and waits for the response before continuing.

• REST APIs (HTTP) — most common, uses JSON over HTTP. Service A makes a GET/POST request to Service B.
• gRPC — faster than REST, uses Protocol Buffers (binary format). Used for high-performance internal communication.
• Feign Client — Spring Cloud tool that makes REST calls between services look like simple method calls.

Asynchronous Communication

Service A sends a message and doesn't wait. Service B processes it later.

• Message Queues — RabbitMQ, ActiveMQ. Producer sends message to queue, consumer picks it up.
• Event Streaming — Apache Kafka. Services publish events to topics, other services subscribe.

6. API Gateway

The API Gateway is the single entry point for all client requests. Instead of clients calling individual services directly, they call the gateway, and it routes the request to the right service.

  Without API Gateway:
  Client → User Service    (port 8081)
  Client → Order Service   (port 8082)
  Client → Payment Service (port 8083)
  (Client needs to know every service's address!)

  With API Gateway:
  Client → API Gateway (port 8080) → routes to correct service
  Client only knows ONE address!

What API Gateway Does:

• Request Routing — forwards /api/users/** to User Service, /api/orders/** to Order Service
• Authentication & Authorization — validates JWT tokens before forwarding
• Rate Limiting — prevents too many requests from one client
• Load Balancing — distributes across multiple instances of a service
• Request/Response Transformation — modifies headers, aggregates responses
• SSL Termination — handles HTTPS, forwards HTTP internally

Spring Cloud Gateway Config (Know the Format)

# application.yml for API Gateway
spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://USER-SERVICE
          predicates:
            - Path=/api/users/**
        - id: order-service
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/api/orders/**

7. Service Discovery (Eureka)

The Problem

In microservices, services run on dynamic IPs and ports. If Order Service needs to call User Service, how does it know where User Service is running? Hardcoding IPs breaks everything when services scale or restart.

The Solution: Service Registry

A Service Registry (like Netflix Eureka) acts as a phone book for services:

1. Register — When a service starts, it registers itself with Eureka ("I'm User Service, running at 192.168.1.5:8081")
2. Discover — When Order Service needs User Service, it asks Eureka ("Where is User Service?")
3. Call — Order Service gets the address and makes the call

Client-Side vs Server-Side Discovery

Eureka Setup (Know These Annotations)

// Eureka SERVER — the registry itself
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

// Eureka CLIENT — any microservice that registers
@SpringBootApplication
@EnableEurekaClient
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

# Eureka Server — application.properties
server.port=8761
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false

# Eureka Client — application.properties
spring.application.name=user-service
eureka.client.service-url.defaultZone=http://localhost:8761/eureka/

8. Spring Cloud for Microservices

Spring Cloud provides tools to implement microservices patterns on top of Spring Boot. Know the mapping:

Feign Client — Service-to-Service Calls

Instead of writing RestTemplate boilerplate, Feign lets you call other services like calling a local method:

// Enable Feign in main class
@SpringBootApplication
@EnableFeignClients
public class OrderServiceApplication { ... }

// Define a Feign Client interface
@FeignClient(name = "USER-SERVICE")
public interface UserClient {

    @GetMapping("/api/users/{id}")
    User getUserById(@PathVariable Long id);
}

// Use it in Order Service — just inject and call!
@RestController
public class OrderController {

    @Autowired
    private UserClient userClient;

    @GetMapping("/orders/{id}")
    public Order getOrder(@PathVariable Long id) {
        User user = userClient.getUserById(id);  // Calls User Service via Eureka!
        // ...
    }
}

9. Circuit Breaker Pattern

The Problem

If Order Service calls Payment Service, and Payment Service is down, Order Service keeps trying and waiting. Meanwhile, requests pile up, Order Service runs out of resources, and crashes too. Now User Service calls Order Service which is also down — cascading failure. One service going down takes everything down.

The Solution: Circuit Breaker

Like an electrical circuit breaker — when it detects too many failures, it "opens" the circuit and stops calling the failing service. Instead, it returns a fallback response immediately.

Three States

  CLOSED (all good)
     │
     │ failures exceed threshold (e.g., 5 failures in a row)
     ▼
  OPEN (stop calling, return fallback)
     │
     │ wait timeout (e.g., 30 seconds)
     ▼
  HALF-OPEN (try a few requests)
     │
     ├── success → back to CLOSED ✓
     └── failure → back to OPEN ✗

Resilience4j Example (Know the Concept)

@RestController
public class OrderController {

    @GetMapping("/orders/{id}")
    @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
    public String getOrder(@PathVariable Long id) {
        // calls Payment Service — may fail
        return restTemplate.getForObject("http://PAYMENT-SERVICE/pay/" + id, String.class);
    }

    // Fallback — runs when circuit is OPEN
    public String paymentFallback(Long id, Throwable t) {
        return "Payment service is currently unavailable. Please try later.";
    }
}

10. Docker & Containers (Brief)

Docker packages your microservice + all its dependencies into a container — a lightweight, portable unit that runs the same everywhere.

Key Concepts

Dockerfile Basics

# Dockerfile for a Spring Boot microservice
FROM openjdk:17-jdk-slim
COPY target/user-service.0.0.1.jar app.jar
EXPOSE 8081
ENTRYPOINT ["java", "-jar", "app.jar"]

Common Docker Commands

# Build an image from Dockerfile
docker build -t user-service .

# Run a container from the image
docker run -p 8081:8081 user-service

# List running containers
docker ps

# Stop a container
docker stop <container-id>

# List images
docker images

11. Microservices Design Patterns

Database Per Service

Each microservice has its own database. Order Service uses its own Order DB, User Service uses User DB. They never access each other's database directly — only through APIs.

Why: Loose coupling, independent deployment, each service can choose its own database type (SQL, NoSQL).

Saga Pattern (Distributed Transactions)

In monolith, you have one database transaction. In microservices, an "order" might involve Order Service, Payment Service, and Inventory Service — each with its own DB. How do you keep them consistent?

Saga = a sequence of local transactions. If one step fails, compensating transactions undo the previous steps.

Two types of Saga:

• Choreography — each service publishes events, next service listens and reacts. No central controller.
• Orchestration — a central orchestrator tells each service what to do and when.

CQRS (Command Query Responsibility Segregation)

Separate the write model (commands: create, update, delete) from the read model (queries: get, search). Different databases or models for reads vs writes. Useful when read and write patterns are very different.

Event-Driven Architecture

Services communicate by publishing and subscribing to events. When Order Service creates an order, it publishes an "OrderCreated" event. Payment Service subscribes to this event and processes payment. Decouples services completely.

12. Advantages vs Disadvantages

Advantages

Disadvantages

13. Real-World Example: E-Commerce App

Let's see how a real e-commerce application would be split into microservices:

  ┌─────────────────────────────────────────────┐
  │              API Gateway (:8080)             │
  └──────┬──────┬──────┬──────┬──────┬──────────┘
         │      │      │      │      │
    ┌────▼──┐ ┌─▼────┐ ┌▼─────┐ ┌───▼───┐ ┌────▼────────┐
    │ User  │ │Produc│ │Order │ │Payment│ │Notification │
    │Service│ │tServ.│ │Serv. │ │Service│ │  Service    │
    │ :8081 │ │:8082 │ │:8083 │ │ :8084 │ │   :8085     │
    └───┬───┘ └──┬───┘ └──┬───┘ └───┬───┘ └─────────────┘
        │        │        │        │
    ┌───▼───┐ ┌──▼───┐ ┌──▼───┐ ┌──▼────┐
    │UserDB │ │Prod  │ │Order │ │PayDB  │
    │(MySQL)│ │DB    │ │DB    │ │       │
    └───────┘ │(Mongo│ └──────┘ └───────┘
              │ DB)  │
              └──────┘

How a Customer Places an Order:

1. Client sends request to API Gateway
2. Gateway routes to Order Service
3. Order Service calls User Service (via Feign) to validate user
4. Order Service calls Product Service to check stock
5. Order Service calls Payment Service to process payment
6. Payment Service publishes "PaymentCompleted" event
7. Notification Service listens to the event and sends confirmation email
8. Order status updated to CONFIRMED

14. Practice MCQs