Lesson 20: Spring Boot Microservices Communication

Introduction

When you split a monolithic application into microservices, you create a fundamental challenge: how do these independent services communicate and coordinate to deliver complex business functionality? Microservices communication is the backbone that connects your distributed system, enabling services to share data, trigger workflows, and respond to events across the network. Unlike method calls within a single application, microservices communication happens over networks with inherent latency, potential failures, and varying loads. You need robust patterns for both real-time synchronous communication (like REST API calls) and asynchronous messaging (like event-driven workflows) to build resilient systems. This lesson teaches you proven communication patterns, from simple HTTP calls to sophisticated message queues and event streaming, along with essential infrastructure like API gateways, load balancers, and circuit breakers that make distributed systems reliable and scalable.

Synchronous Communication

Definition

Synchronous communication in microservices involves direct, blocking calls between services where the calling service waits for a response before continuing. This typically uses HTTP REST APIs where one service makes a request to another and waits for the result. Synchronous communication is straightforward to implement and debug, providing immediate consistency and clear request-response flows. However, it creates tight coupling between services and can lead to cascading failures if dependent services are unavailable.

Analogy

Synchronous communication is like making a phone call to get information - you dial a number, wait for someone to answer, ask your question, listen to their response, and then proceed based on what they told you. If the person you're calling doesn't answer or their line is busy, you're stuck waiting or have to try again later. This works well for urgent matters where you need an immediate answer, like calling a restaurant to check if they have availability tonight. However, if you're calling multiple places to compare prices, you're spending a lot of time waiting on hold and the entire process slows down if any one restaurant takes too long to respond. The phone conversation is synchronous because both parties are engaged simultaneously, and your plans depend on getting answers from each call before making your decision.

Examples

Simple REST API call between services:

@RestController
public class OrderController {
    public OrderResponse createOrder(@RequestBody OrderRequest request) {
        User user = userService.getUser(request.getUserId());
        return orderService.createOrder(request, user);
    }
}

Service-to-service HTTP call:

@Service
public class UserService {
    public User getUser(Long userId) {
        return restTemplate.getForObject("http://user-service/users/{id}", User.class, userId);
    }
}

Blocking call with timeout:

HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
factory.setConnectTimeout(5000);
factory.setReadTimeout(5000);
RestTemplate restTemplate = new RestTemplate(factory);

Error handling in synchronous calls:

try {
    Product product = restTemplate.getForObject("http://catalog-service/products/{id}", Product.class, productId);
} catch (ResourceAccessException e) {
    throw new ServiceUnavailableException("Catalog service is down");
}

Service Clients

Definition

Service clients are abstractions that handle the complexity of calling other microservices, providing a clean interface for service-to-service communication. Spring Cloud OpenFeign creates declarative REST clients using interfaces and annotations, automatically handling serialization, error handling, and integration with service discovery. Service clients encapsulate communication details like URLs, timeouts, and retry logic, making inter-service calls feel like local method calls while providing flexibility for configuration and testing.

Analogy

Service clients are like having a personal assistant who specializes in making business calls on your behalf. Instead of you having to look up phone numbers, dial manually, navigate phone trees, and handle busy signals, you simply tell your assistant "get me the latest inventory numbers from the warehouse" and they handle all the details. Your assistant knows the right people to call, has all the contact information, understands the proper protocols for each organization, and can handle problems like busy lines or transfers. They present you with a simple interface - you make a request and get results - while they manage all the complexity of actually making the calls, dealing with different phone systems, and following up if needed. This allows you to focus on your core work instead of the mechanics of communication.

Examples

Feign client declaration:

@FeignClient(name = "user-service")
public interface UserServiceClient {
    @GetMapping("/users/{id}")
    User getUser(@PathVariable Long id);
}

Using Feign client in service:

@Service
public class OrderService {
    private final UserServiceClient userClient;

    public Order createOrder(OrderRequest request) {
        User user = userClient.getUser(request.getUserId());
        return new Order(user, request.getItems());
    }
}

Feign client with configuration:

@FeignClient(name = "payment-service", configuration = PaymentConfig.class)
public interface PaymentServiceClient {
    @PostMapping("/payments")
    PaymentResult processPayment(@RequestBody PaymentRequest request);
}

Custom error handling in Feign:

@Component
public class CustomErrorDecoder implements ErrorDecoder {
    public Exception decode(String methodKey, Response response) {
        if (response.status() == 404) {
            return new UserNotFoundException();
        }
        return new ServiceException("Service call failed");
    }
}

Load Balancing

Definition

Load balancing distributes incoming requests across multiple instances of a service to ensure no single instance becomes overwhelmed and to provide high availability. Spring Cloud LoadBalancer automatically distributes calls among available service instances discovered through service registry. Different load balancing algorithms include round-robin (distribute evenly), random selection, and weighted distribution based on instance capacity. Load balancing is essential for scalability and resilience in microservices architectures.

Analogy

Load balancing is like how a busy restaurant manages multiple servers during peak hours. Instead of having all customers line up for one waiter who would become overwhelmed, the host distributes customers among available servers based on their current workload. Some servers might be handling fewer tables (round-robin), while others might get assigned based on their experience level (weighted), or the host might randomly assign tables to keep things fair. If one server goes on break or gets overwhelmed, customers are automatically directed to other available servers. The host monitors which servers are available and ensures no single server gets all the difficult customers or large parties. This system ensures all customers get served promptly, servers don't burn out, and the restaurant can handle much more traffic than if they relied on just one person.

Examples

Load balanced RestTemplate:

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

Service call with automatic load balancing:

@Service
public class OrderService {
    public Product getProduct(Long productId) {
        return restTemplate.getForObject("http://product-service/products/{id}", Product.class, productId);
    }
}

Custom load balancing configuration:

@Bean
public IRule loadBalancingRule() {
    return new WeightedResponseTimeRule();  // Favor faster instances
}

Feign with load balancing:

@FeignClient(name = "inventory-service")
public interface InventoryClient {
    @GetMapping("/inventory/{productId}")
    InventoryStatus checkInventory(@PathVariable Long productId);
}
// Automatically load balances across inventory-service instances

Circuit Breakers

Definition

Circuit breakers prevent cascading failures in distributed systems by automatically stopping calls to failing services and providing fallback responses. When a service starts failing, the circuit breaker "opens" and immediately returns cached responses or default values instead of attempting doomed calls. After a timeout period, it tries limited calls to test if the service has recovered. Circuit breakers protect system stability by failing fast and allowing failing services time to recover without being overwhelmed by requests.

Analogy

A circuit breaker works exactly like the electrical circuit breaker in your home. When there's an electrical problem like a short circuit or overload, the breaker immediately cuts power to prevent damage to appliances and avoid fires. Rather than continuing to send electricity through a dangerous circuit, it stops the flow entirely for safety. After some time, you can manually reset the breaker to test if the problem is fixed. If the issue persists, the breaker trips again immediately. In software, when a service starts failing (like returning errors or timing out), the circuit breaker stops sending requests to that service and instead returns a safe default response. This prevents your application from wasting time on doomed requests and gives the failing service a chance to recover without being bombarded with more traffic.

Examples

Circuit breaker with Resilience4j:

@Component
public class RecommendationService {
    @CircuitBreaker(name = "recommendation", fallbackMethod = "fallbackRecommendation")
    public List getRecommendations(Long userId) {
        return externalRecommendationService.getRecommendations(userId);
    }
}

Fallback method implementation:

public List fallbackRecommendation(Long userId, Exception ex) {
    return List.of(new Product("Default Product", "Safe fallback recommendation"));
}

Circuit breaker configuration:

resilience4j.circuitbreaker.instances.recommendation.failure-rate-threshold=50
resilience4j.circuitbreaker.instances.recommendation.wait-duration-in-open-state=30s
resilience4j.circuitbreaker.instances.recommendation.sliding-window-size=10

Circuit breaker with retry:

@Retry(name = "payment")
@CircuitBreaker(name = "payment", fallbackMethod = "fallbackPayment")
public PaymentResult processPayment(PaymentRequest request) {
    return paymentService.process(request);
}

API Gateways

Definition

API gateways provide a single entry point for client applications to access multiple microservices, handling cross-cutting concerns like authentication, rate limiting, routing, and request/response transformation. Spring Cloud Gateway routes requests to appropriate services based on path patterns, handles load balancing, and can modify requests or responses as they pass through. API gateways simplify client interactions by presenting a unified API surface while enabling independent service evolution behind the scenes.

Analogy

An API gateway is like the reception desk at a large corporate building with many different departments. Instead of visitors having to know exactly which floor, room number, and department they need, they go to the reception desk with their request. The receptionist checks their credentials (authentication), directs them to the right department (routing), might limit how many people can visit certain departments at once (rate limiting), and could even translate requests if departments speak different languages (request transformation). The receptionist also maintains a directory of all departments and their current locations, so if a department moves to a different floor, visitors don't need to know - they still go to reception and get directed properly. This single point of entry makes the building much easier to navigate while allowing departments to reorganize internally without confusing visitors.

Examples

Basic Spring Cloud Gateway configuration:

spring:
  cloud:
    gateway:
      routes:
      - id: user-service
        uri: lb://user-service
        predicates:
        - Path=/api/users/**

Gateway with filters:

spring:
  cloud:
    gateway:
      routes:
      - id: order-service
        uri: lb://order-service
        predicates:
        - Path=/api/orders/**
        filters:
        - AddRequestHeader=X-Request-Source, gateway

Custom gateway filter:

@Component
public class AuthenticationFilter implements GatewayFilter {
    public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token = exchange.getRequest().getHeaders().getFirst("Authorization");
        if (isValidToken(token)) {
            return chain.filter(exchange);
        }
        exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
        return exchange.getResponse().setComplete();
    }
}

Rate limiting in gateway:

spring:
  cloud:
    gateway:
      routes:
      - id: api-service
        filters:
        - name: RequestRateLimiter
          args:
            rate-limiter: "#{@redisRateLimiter}"
            key-resolver: "#{@userKeyResolver}"

Asynchronous Messaging

Definition

Asynchronous messaging allows services to communicate without waiting for immediate responses, using message brokers to queue and deliver messages between producers and consumers. Services send messages to queues or topics and continue processing immediately, while other services process messages when ready. This pattern enables loose coupling, better scalability, and resilience since services don't need to be available simultaneously. Asynchronous messaging is ideal for event-driven architectures and long-running workflows.

Analogy

Asynchronous messaging is like using email instead of phone calls for business communication. When you need to send information to a colleague, you compose an email and send it immediately without waiting for them to be available to receive it. The email system (message broker) stores your message and delivers it when the recipient checks their inbox. Your colleague can read and respond when convenient, and you're not blocked waiting for an immediate response. This works especially well for non-urgent communications, complex information that needs time to process, or when coordinating across different time zones. Multiple people can receive the same message (like a mailing list), and the system ensures delivery even if someone's computer is temporarily offline. You can continue working immediately after sending, making the entire communication flow much more efficient than trying to coordinate simultaneous phone calls with multiple people.

Examples

Publishing messages with Spring Cloud Stream:

@Service
public class OrderEventPublisher {
    private final StreamBridge streamBridge;

    public void publishOrderCreated(Order order) {
        streamBridge.send("order-events", new OrderCreatedEvent(order));
    }
}

Message consumer:

@Component
public class InventoryService {
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        reserveInventory(event.getOrder().getItems());
    }
}

RabbitMQ message sending:

@Service
public class NotificationService {
    private final RabbitTemplate rabbitTemplate;

    public void sendWelcomeEmail(User user) {
        rabbitTemplate.convertAndSend("email-queue", new EmailMessage(user.getEmail(), "Welcome!"));
    }
}

Message listener:

@RabbitListener(queues = "email-queue")
public void processEmailMessage(EmailMessage message) {
    emailService.sendEmail(message.getTo(), message.getSubject(), message.getBody());
}

Message Queues

Definition

Message queues provide reliable, ordered delivery of messages between services, ensuring that messages are not lost even if services are temporarily unavailable. Queues store messages until consumers are ready to process them, providing buffering during traffic spikes and enabling different processing speeds between producers and consumers. Message queues support various delivery patterns including point-to-point (one consumer per message) and publish-subscribe (multiple consumers for the same message).

Analogy

Message queues work like the order system in a busy fast-food restaurant during lunch rush. When customers place orders (messages), they're written on tickets and placed in an organized queue for the kitchen staff. The order-takers (producers) can continue taking new orders even if the kitchen is backed up, because the tickets wait safely in the queue. Kitchen staff (consumers) process orders in the correct sequence when they're ready, and if someone goes on break, other staff members can pick up where they left off. The ticket system ensures no orders are lost, even during the busiest periods, and customers can see their order number to know their position in line. Different stations might handle different parts of the order (drink station, grill, assembly), each working from their own specialized queue, but all coordinated to deliver complete meals efficiently.

Examples

RabbitMQ queue configuration:

@Configuration
public class QueueConfig {
    @Bean
    public Queue orderProcessingQueue() {
        return QueueBuilder.durable("order-processing").build();
    }
}

Sending messages to queue:

@Service
public class OrderService {
    public void processOrder(Order order) {
        orderRepository.save(order);
        rabbitTemplate.convertAndSend("order-processing", order);
    }
}

Queue consumer with error handling:

@RabbitListener(queues = "order-processing")
public void handleOrderProcessing(Order order) {
    try {
        paymentService.processPayment(order);
        inventoryService.reserveItems(order);
    } catch (Exception e) {
        rabbitTemplate.convertAndSend("order-failed", order);
    }
}

Dead letter queue configuration:

@Bean
public Queue orderQueue() {
    return QueueBuilder.durable("orders")
        .withArgument("x-dead-letter-exchange", "dlx")
        .withArgument("x-dead-letter-routing-key", "failed-orders")
        .build();
}

Event Streaming

Definition

Event streaming captures data changes as a continuous flow of events that multiple services can subscribe to and process independently. Unlike traditional message queues where messages are consumed once, event streams maintain a log of events that can be replayed and processed by multiple consumers at different times. Event streaming is ideal for building event-driven architectures, real-time analytics, and systems that need to maintain consistency across multiple data stores through event sourcing patterns.

Analogy

Event streaming is like a live news feed or social media timeline that multiple people can follow and react to simultaneously. When something newsworthy happens (an event), it gets published to the stream where anyone interested can see it. Unlike a private message that only one person receives, the news story stays in the timeline for everyone to read, comment on, and share at their own pace. Different people might react differently to the same news - some might share it, others might fact-check it, and some might use it for research. New followers can catch up by reading the timeline history, and the same news can trigger multiple different responses across various platforms and audiences. The stream maintains a permanent record of what happened when, allowing people to understand the sequence of events and their relationships to each other.

Examples

Kafka event streaming setup:

@Component
public class OrderEventStream {
    @KafkaListener(topics = "order-events")
    public void handleOrderEvent(OrderEvent event) {
        logger.info("Received order event: {}", event.getType());
    }
}

Publishing events to stream:

@Service
public class OrderService {
    private final KafkaTemplate kafkaTemplate;

    public void publishOrderCreated(Order order) {
        OrderEvent event = new OrderEvent("ORDER_CREATED", order);
        kafkaTemplate.send("order-events", event);
    }
}

Multiple consumers for same stream:

// Analytics service
@KafkaListener(topics = "order-events", groupId = "analytics-group")
public void trackOrderMetrics(OrderEvent event) {
    metricsService.recordOrderEvent(event);
}

// Notification service
@KafkaListener(topics = "order-events", groupId = "notification-group")
public void sendNotification(OrderEvent event) {
    if (event.getType().equals("ORDER_CREATED")) {
        notificationService.sendOrderConfirmation(event.getOrder());
    }
}

Event sourcing with streams:

@EventHandler
public void on(OrderCreatedEvent event) {
    this.orderId = event.getOrderId();
    this.status = OrderStatus.CREATED;
    this.items = event.getItems();
}

Distributed Tracing

Definition

Distributed tracing tracks requests as they flow through multiple microservices, providing visibility into the complete journey of each transaction across your distributed system. Tracing systems like Zipkin or Jaeger assign unique trace IDs to requests and track spans (individual service calls) within each trace. This enables developers to understand performance bottlenecks, debug issues across service boundaries, and analyze the behavior of complex distributed workflows that span multiple services and external dependencies.

Analogy

Distributed tracing is like following a package's journey through a complex shipping network using a tracking number. When you ship a package, it gets a unique tracking ID that follows it through every step: pickup from your location, sorting at local facility, transport to regional hub, routing through distribution centers, final delivery truck, and arrival at destination. At each step, the system records when the package arrived, how long it stayed, and where it went next. If the package is delayed, you can see exactly where the bottleneck occurred - maybe it sat too long at a particular distribution center, or the final delivery truck was overloaded. Similarly, distributed tracing follows a user request through multiple microservices, recording timing and dependencies at each step, so if a web page loads slowly, you can pinpoint whether the delay was in the user service, payment processing, or external API calls.

Examples

Adding tracing to Spring Boot:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

Custom span annotation:

@Service
public class PaymentService {
    @NewSpan("payment-processing")
    public PaymentResult processPayment(@SpanTag("amount") BigDecimal amount) {
        return externalPaymentProvider.charge(amount);
    }
}

Manual span creation:

@Autowired
private Tracer tracer;

public void complexOperation() {
    Span span = tracer.nextSpan().name("complex-operation").start();
    try (Tracer.SpanInScope ws = tracer.withSpanInScope(span)) {
        // Your operation here
        span.tag("operation.type", "data-processing");
    } finally {
        span.end();
    }
}

Trace correlation across services:

@RestController
public class OrderController {
    public Order createOrder(@RequestBody OrderRequest request) {
        // Trace ID automatically propagated through service calls
        User user = userServiceClient.getUser(request.getUserId());
        PaymentResult payment = paymentServiceClient.process(request.getPayment());
        return orderService.create(user, payment, request.getItems());
    }
}

Service Mesh

Definition

A service mesh is a dedicated infrastructure layer that handles service-to-service communication using a network of lightweight proxies deployed alongside each service. Service meshes like Istio or Linkerd provide features like traffic management, security, observability, and policy enforcement without requiring changes to application code. The mesh handles concerns like load balancing, circuit breaking, mutual TLS, and traffic routing at the infrastructure level, allowing developers to focus on business logic while getting enterprise-grade networking capabilities.

Analogy

A service mesh is like having a sophisticated traffic management system for a complex highway network connecting multiple cities. Instead of each driver having to figure out the best route, handle toll payments, and navigate traffic themselves, there's an intelligent infrastructure that guides every vehicle. Smart traffic lights coordinate flow, automated toll systems handle payments, GPS systems provide real-time routing, and traffic monitors ensure no single road gets overwhelmed. If an accident blocks one highway, the system automatically reroutes traffic through alternate paths. Emergency vehicles get priority lanes, and the system can enforce different rules for different types of vehicles. Drivers just focus on getting to their destination while the infrastructure handles all the complexity of traffic management, security (checking vehicle registration), and monitoring (tracking traffic patterns). The mesh ensures smooth, secure communication between all the cities without requiring each driver to become a traffic expert.

Examples

Istio service mesh configuration:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
  - order-service
  http:
  - route:
    - destination:
        host: order-service
        subset: v1
      weight: 90
    - destination:
        host: order-service
        subset: v2
      weight: 10

Traffic splitting for canary deployment:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Mutual TLS policy:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

Service mesh observability:

// No code changes needed - mesh provides automatic:
// - Request tracing
// - Metrics collection
// - Error tracking
// - Traffic visualization

Communication Best Practices

Definition

Effective microservices communication requires following established patterns to ensure reliability, performance, and maintainability. Best practices include using asynchronous messaging for non-critical operations, implementing proper timeout and retry policies, designing for idempotency, using correlation IDs for request tracking, implementing graceful degradation when services are unavailable, and choosing appropriate consistency models for different business scenarios. Following these practices helps build resilient distributed systems that handle failures gracefully.

Analogy

Communication best practices for microservices are like the protocols and procedures that make international business relationships work smoothly. When companies in different countries want to collaborate, they don't just start calling each other randomly - they establish proper communication channels, agree on common languages and standards, set up backup communication methods for when primary channels fail, and create clear procedures for handling misunderstandings or delays. They use written contracts with clear terms (service contracts), establish regular check-ins (health checks), maintain detailed records of all transactions (audit logs), and have contingency plans when partners are unavailable (fallback strategies). Successful international business requires understanding cultural differences (service boundaries), using appropriate communication channels for different types of messages (sync vs async), and building trust through consistent, reliable interactions over time.

Examples

Idempotent operations:

@PostMapping("/orders")
public ResponseEntity createOrder(@RequestBody OrderRequest request,
                                       @RequestHeader("Idempotency-Key") String key) {
    Order existing = orderService.findByIdempotencyKey(key);
    if (existing != null) {
        return ResponseEntity.ok(existing);  // Return existing instead of creating duplicate
    }
    return ResponseEntity.status(HttpStatus.CREATED).body(orderService.create(request, key));
}

Correlation ID tracking:

@Component
public class CorrelationIdFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        String correlationId = getOrGenerateCorrelationId(request);
        MDC.put("correlationId", correlationId);
        // Pass correlation ID to downstream services
        chain.doFilter(request, response);
    }
}

Timeout and retry configuration:

@Retryable(value = {TransientException.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000))
@TimeLimiter(name = "user-service", fallbackMethod = "fallbackUser")
public CompletableFuture getUser(Long userId) {
    return CompletableFuture.completedFuture(userServiceClient.getUser(userId));
}

Graceful degradation:

@Service
public class RecommendationService {
    public List getRecommendations(Long userId) {
        try {
            return externalRecommendationService.getPersonalized(userId);
        } catch (Exception e) {
            logger.warn("Recommendation service unavailable, using popular products");
            return productService.getPopularProducts();
        }
    }
}

Summary

You've now mastered the essential patterns and technologies for microservices communication, from simple synchronous REST calls to sophisticated asynchronous event streaming. Understanding when to use synchronous vs asynchronous communication, how to implement resilience patterns like circuit breakers and retries, and how to manage complexity through API gateways and service meshes enables you to build robust distributed systems. Communication is the backbone of microservices architecture - getting it right determines whether your system is resilient and scalable or fragile and unreliable. These patterns and tools provide the foundation for building production-ready microservices that can handle real-world complexity and scale. In the final lesson, you'll explore advanced microservices topics including distributed data management, deployment strategies, and organizational patterns that complete your journey to microservices mastery.

Programming Challenge