Lesson 21: Spring Boot Microservices Advanced Topics

Introduction

Building microservices that work in development is just the first step - creating production-ready distributed systems that scale to millions of users requires mastering advanced patterns and practices that address the complex challenges of distributed computing. You need sophisticated strategies for managing data consistency across services, deploying updates without downtime, maintaining observability across dozens of services, and ensuring security in a distributed environment where traditional perimeter-based approaches don't work. Advanced microservices topics cover the patterns and practices that separate toy applications from enterprise-grade systems: distributed transaction management through sagas, eventual consistency with event sourcing, zero-downtime deployments with blue-green and canary strategies, comprehensive observability through distributed tracing and metrics, and organizational patterns that enable teams to work effectively with microservices at scale. This final lesson completes your journey from Spring Boot basics to enterprise microservices mastery, providing the advanced knowledge needed to build and operate world-class distributed systems.

Distributed Data Management

Definition

Distributed data management addresses the challenge of maintaining data consistency and integrity across multiple microservices, each with their own databases. Unlike monolithic applications where ACID transactions ensure consistency, microservices require new approaches like eventual consistency, distributed transactions, and data synchronization patterns. Key strategies include database-per-service patterns, shared data anti-patterns, and techniques for handling cross-service data dependencies while maintaining service autonomy.

Analogy

Distributed data management is like coordinating inventory across a large retail chain with multiple warehouses and stores, each maintaining their own stock records. In a single-store operation, you can instantly check inventory and update quantities in one system, but with multiple locations, you need sophisticated coordination. When a customer orders online, you might reserve items from different warehouses, coordinate shipping, and update inventory across multiple systems. Each location maintains its own inventory database for operational efficiency, but they need to synchronize information for accurate availability and prevent overselling. Sometimes you accept that inventory counts might be slightly off between locations for a few minutes (eventual consistency) rather than locking all systems during every transaction. The key is designing processes that maintain overall system integrity while allowing each location to operate independently and efficiently.

Examples

Database per service pattern:

// Each service owns its data
@Entity
@Table(name = "users")
public class User {
    // User service database
}

@Entity
@Table(name = "orders")
public class Order {
    private String userId;  // Reference by ID, not entity
    // Order service database
}

Data synchronization events:

@EventListener
public void onUserUpdated(UserUpdatedEvent event) {
    // Sync user data to order service's read model
    userReadModel.updateUser(event.getUser());
}

Eventual consistency handling:

@Service
public class OrderService {
    public Order createOrder(CreateOrderRequest request) {
        // Create order immediately, validate user asynchronously
        Order order = new Order(request.getUserId(), PENDING_VALIDATION);
        publishEvent(new OrderCreatedEvent(order));
        return order;
    }
}

Data anti-corruption layer:

@Component
public class UserDataAdapter {
    public LocalUser adaptExternalUser(ExternalUser externalUser) {
        // Transform external user format to local domain model
        return LocalUser.builder()
            .id(externalUser.getIdentifier())
            .name(externalUser.getFullName())
            .build();
    }
}

Saga Pattern

Definition

The Saga pattern manages distributed transactions by breaking them into a series of local transactions, each with a compensating action that can undo the work if later steps fail. Instead of traditional two-phase commit protocols that don't scale well in microservices, sagas coordinate long-running transactions through choreography (event-driven) or orchestration (centrally managed) approaches. Sagas maintain eventual consistency while providing mechanisms to handle failures and ensure system integrity across service boundaries.

Analogy

The Saga pattern is like planning a complex wedding where multiple vendors must coordinate their services, but if one vendor fails, you need a way to cancel or modify all the other arrangements. When booking a wedding, you might reserve the venue, book catering, hire photographers, and arrange flowers as separate transactions. If the venue cancels at the last minute, you need to systematically undo or modify all the other bookings - cancel catering, reschedule photography, and adjust flower delivery. Each vendor has their own booking system and policies, so you can't use a single "master transaction" that locks everything until confirmed. Instead, you coordinate through a series of individual bookings, each with a clear cancellation policy. The wedding planner (saga orchestrator) tracks the overall progress and executes the compensation plan if anything goes wrong, ensuring you don't end up with flowers for a cancelled wedding or catering for a venue you don't have.

Examples

Saga orchestrator pattern:

@Component
public class OrderSagaOrchestrator {
    public void processOrder(Order order) {
        try {
            reserveInventory(order);
            processPayment(order);
            shipOrder(order);
            order.complete();
        } catch (Exception e) {
            compensate(order, e);
        }
    }
}

Choreography-based saga:

@EventListener
public void onOrderCreated(OrderCreatedEvent event) {
    try {
        inventoryService.reserve(event.getItems());
        publishEvent(new InventoryReservedEvent(event.getOrderId()));
    } catch (Exception e) {
        publishEvent(new InventoryReservationFailedEvent(event.getOrderId()));
    }
}

Compensation actions:

@Service
public class PaymentService {
    public void processPayment(PaymentRequest request) {
        // Process payment
    }

    public void refundPayment(String paymentId) {
        // Compensation action for payment
    }
}

Saga state management:

@Entity
public class OrderSaga {
    private String orderId;
    private SagaState state;
    private List completedSteps;

    public void addCompletedStep(SagaStep step) {
        completedSteps.add(step);
    }
}

Event Sourcing

Definition

Event sourcing stores the state of applications as a sequence of events rather than current state snapshots. Every change to application state is captured as an event that is appended to an event store. Current state is derived by replaying events from the beginning or from a snapshot. This approach provides a complete audit trail, enables temporal queries, supports event replay for debugging, and facilitates building multiple read models from the same event stream for different use cases.

Analogy

Event sourcing is like keeping a detailed bank account ledger that records every transaction instead of just showing your current balance. Traditional banking systems might only show "Current Balance: $1,543.21," but event sourcing keeps the complete history: "Started with $1,000, deposited $500 on Monday, paid $50 for groceries Tuesday, received $200 salary Wednesday, paid $106.79 for utilities Thursday." You can reconstruct your current balance by replaying all transactions, and more importantly, you can answer questions like "What was my balance last Tuesday?" or "How much did I spend on groceries this month?" The ledger becomes an authoritative history that enables you to build different views: monthly summaries, spending categories, or tax reports - all derived from the same underlying transaction history. If there's ever a dispute about a transaction, you have the complete, immutable record of exactly what happened and when.

Examples

Event store implementation:

@Entity
public class EventStore {
    private String aggregateId;
    private String eventType;
    private String eventData;
    private Long sequence;
    private LocalDateTime timestamp;
}

Domain events:

public class OrderCreatedEvent implements DomainEvent {
    private final String orderId;
    private final String customerId;
    private final List items;
    private final LocalDateTime timestamp;
}

Event-sourced aggregate:

public class Order {
    private String id;
    private OrderStatus status;
    private List changes = new ArrayList<>();

    public void apply(OrderCreatedEvent event) {
        this.id = event.getOrderId();
        this.status = OrderStatus.CREATED;
    }

    public static Order fromHistory(List events) {
        Order order = new Order();
        events.forEach(order::apply);
        return order;
    }
}

Event replay for reconstruction:

@Service
public class EventSourcingRepository {
    public Order findById(String orderId) {
        List events = eventStore.getEvents(orderId);
        return Order.fromHistory(events);
    }
}

CQRS Pattern

Definition

Command Query Responsibility Segregation (CQRS) separates read and write operations into different models, allowing each to be optimized independently. Commands handle state changes and business logic, while queries provide optimized read models for different use cases. CQRS works particularly well with event sourcing, where events update multiple read models asynchronously. This pattern enables high-performance reads, complex reporting capabilities, and independent scaling of read and write workloads.

Analogy

CQRS is like how a modern newspaper operation separates news gathering and reporting from news reading and distribution. The newsroom (command side) focuses on investigating stories, conducting interviews, and writing articles - optimized for accuracy, fact-checking, and editorial workflow. Meanwhile, the distribution system (query side) creates different formats for different audiences: a website optimized for quick browsing, a mobile app for commuters, a print edition for detailed reading, and social media summaries for sharing. Each reading format is specifically designed for its audience and use case, but they all derive from the same underlying news content. The newsroom doesn't worry about website performance or mobile layouts - they focus on creating quality content. The distribution systems don't handle news gathering - they focus on presenting information effectively. This separation allows each side to excel at what it does best while serving the same overall purpose.

Examples

Command and query separation:

// Command side - handles writes
@RestController
public class OrderCommandController {
    @PostMapping("/orders")
    public void createOrder(@RequestBody CreateOrderCommand command) {
        orderCommandService.handle(command);
    }
}

// Query side - handles reads
@RestController
public class OrderQueryController {
    @GetMapping("/orders/{id}")
    public OrderView getOrder(@PathVariable String id) {
        return orderQueryService.findById(id);
    }
}

Command handler:

@Component
public class CreateOrderCommandHandler {
    public void handle(CreateOrderCommand command) {
        Order order = new Order(command);
        orderRepository.save(order);
        eventPublisher.publish(new OrderCreatedEvent(order));
    }
}

Read model projection:

@EventListener
public void on(OrderCreatedEvent event) {
    OrderSummaryView summary = new OrderSummaryView(
        event.getOrderId(),
        event.getCustomerName(),
        event.getTotalAmount()
    );
    orderSummaryRepository.save(summary);
}

Specialized query models:

public class CustomerOrderHistory {
    private String customerId;
    private int totalOrders;
    private BigDecimal totalSpent;
    private LocalDate lastOrderDate;
}

Container Orchestration

Definition

Container orchestration manages the deployment, scaling, networking, and availability of containerized microservices across clusters of machines. Kubernetes is the dominant orchestration platform, providing automated deployment, service discovery, load balancing, rolling updates, and self-healing capabilities. Orchestration transforms individual containers into resilient, scalable distributed systems that can automatically respond to failures, traffic changes, and resource demands without manual intervention.

Analogy

Container orchestration is like having an intelligent logistics system for managing a fleet of food trucks across a large city. Instead of manually telling each truck where to go and what to do, the orchestration system (Kubernetes) automatically assigns trucks to locations based on demand, weather, events, and traffic patterns. If a truck breaks down, the system automatically dispatches a replacement. During lunch rush, more trucks are automatically deployed to business districts. If there's a festival in the park, the system scales up ice cream trucks in that area. The system handles all the complex coordination: tracking which trucks are where, routing customers to nearby trucks, balancing the workload across trucks, and ensuring there's always adequate coverage. Truck operators focus on serving customers while the orchestration system handles the logistics of where to be, when to scale up or down, and how to maintain service during equipment failures or maintenance periods.

Examples

Kubernetes deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    spec:
      containers:
      - name: user-service
        image: user-service:latest

Service discovery and load balancing:

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8080

Auto-scaling configuration:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

Health checks and self-healing:

livenessProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080

Blue-Green Deployment

Definition

Blue-green deployment maintains two identical production environments (blue and green), with only one serving live traffic at any time. When deploying updates, the new version is deployed to the inactive environment, tested thoroughly, then traffic is switched over instantly. This approach enables zero-downtime deployments, instant rollbacks if issues are discovered, and the ability to test the complete system under production conditions before going live. Blue-green deployments reduce deployment risk and provide confidence in release processes.

Analogy

Blue-green deployment is like how airlines manage aircraft maintenance and operations to ensure continuous service. An airline might have two identical aircraft serving the same route - while one plane (blue) carries passengers, the other (green) undergoes maintenance, upgrades, or testing. When it's time to introduce a new in-flight entertainment system or safety equipment, they install and test everything on the green aircraft while the blue aircraft continues normal operations. Once the green aircraft passes all safety checks and testing, they simply swap the aircraft assignments - passengers now board the upgraded green aircraft while the blue aircraft goes offline for its updates. If any problems are discovered with the upgrades, they can instantly switch back to the blue aircraft. This ensures passengers always have reliable service while allowing the airline to introduce improvements safely and test them thoroughly under real operating conditions before committing to the change.

Examples

Blue-green infrastructure setup:

# Blue environment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-blue
  labels:
    version: blue
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: user-service
        version: blue

Traffic switching service:

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
    version: blue  # Switch to green when ready
  ports:
  - port: 80
    targetPort: 8080

Deployment script automation:

# Deploy to green environment
kubectl apply -f user-service-green.yaml

# Wait for green to be ready
kubectl wait --for=condition=available deployment/user-service-green

# Run smoke tests
./run-smoke-tests.sh green

# Switch traffic to green
kubectl patch service user-service -p '{"spec":{"selector":{"version":"green"}}}'

Rollback capability:

# Instant rollback if issues detected
kubectl patch service user-service -p '{"spec":{"selector":{"version":"blue"}}}'

Canary Releases

Definition

Canary releases gradually roll out new versions to a small subset of users before full deployment, allowing real-world validation with limited blast radius. Traffic is gradually shifted from the old version to the new version while monitoring key metrics like error rates, response times, and business KPIs. If metrics remain healthy, the rollout continues; if problems are detected, traffic is immediately routed back to the stable version. This approach provides early warning of issues while minimizing user impact during deployments.

Analogy

Canary releases are like how a restaurant tests new menu items before adding them permanently. Instead of immediately offering a new dish to all customers, the chef might offer it as a "chef's special" to just a few adventurous diners each night. They carefully watch customer reactions, ask for feedback, monitor how quickly it sells, and observe if it affects kitchen workflow or ingredient costs. If early customers love the dish and kitchen operations run smoothly, they gradually offer it to more customers each night. If customers complain or the dish creates kitchen problems, they can quickly stop offering it without affecting the regular menu. This gradual rollout lets them validate the new dish with real customers under real conditions while limiting the risk - if something goes wrong, only a small number of customers are affected, and they can quickly return to the proven menu items that they know work well.

Examples

Canary deployment with traffic splitting:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: user-service
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10  # 10% traffic to canary
      - pause: {}
      - setWeight: 50  # 50% traffic to canary
      - pause: {}
      - setWeight: 100 # Full rollout

Metric-based canary validation:

@Component
public class CanaryMetricsValidator {
    public boolean validateCanaryHealth() {
        double errorRate = metricsService.getErrorRate("canary");
        double responseTime = metricsService.getAvgResponseTime("canary");

        return errorRate < 0.01 && responseTime < 200;
    }
}

Feature flag integration:

@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        if (featureToggle.isEnabled("new-user-lookup", getCurrentUser())) {
            return newUserService.findUser(id);  // Canary implementation
        }
        return userService.findUser(id);  // Stable implementation
    }
}

Automated rollback triggers:

analysis:
  templates:
  - templateName: error-rate
  args:
  - name: service-name
    value: user-service
  successCondition: result[0] < 0.01
  failureLimit: 3

Observability Patterns

Definition

Observability in microservices requires comprehensive monitoring across three pillars: metrics (quantitative measurements), logs (detailed event records), and traces (request flow across services). Advanced observability includes distributed tracing to follow requests across service boundaries, correlated logging for debugging, alerting on business and technical metrics, and dashboards that provide actionable insights. Effective observability enables rapid incident response, proactive problem detection, and data-driven optimization decisions.

Analogy

Observability in microservices is like the comprehensive monitoring system in a modern smart city that helps city officials understand what's happening across all neighborhoods and infrastructure. The city has thousands of sensors collecting metrics (traffic flow, air quality, power consumption), detailed logs from various systems (police reports, emergency calls, maintenance records), and tracking systems that follow specific incidents from start to finish (following an ambulance from emergency call through hospital admission). When something goes wrong - like a power outage or traffic jam - officials can quickly correlate data from multiple sources to understand the scope, identify the cause, and coordinate response efforts. They don't just wait for citizens to complain; they proactively monitor trends and patterns to prevent problems. The system provides dashboards for different stakeholders: traffic managers see road conditions, utility managers monitor power grids, and city planners analyze long-term trends. This comprehensive visibility enables effective management of a complex, distributed system where problems in one area can cascade to others.

Examples

Distributed tracing setup:

@NewSpan("order-processing")
public Order processOrder(@SpanTag("orderId") String orderId) {
    User user = userService.getUser(order.getUserId());
    Payment payment = paymentService.process(order.getPayment());
    return orderRepository.save(order);
}

Structured logging with correlation:

@Component
public class StructuredLogger {
    public void logOrderEvent(String event, Order order) {
        logger.info("Order event: {} for order: {} customer: {} amount: {}",
            event, order.getId(), order.getCustomerId(), order.getAmount());
    }
}

Custom business metrics:

@Component
public class BusinessMetrics {
    private final Counter ordersCreated = Counter.builder("orders.created")
        .tag("service", "order-service")
        .register(meterRegistry);

    private final Timer orderProcessingTime = Timer.builder("orders.processing.time")
        .register(meterRegistry);
}

Alerting configuration:

# Prometheus alerting rules
groups:
- name: microservices
  rules:
  - alert: HighErrorRate
    expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "High error rate in {{ $labels.service }}"

Security in Microservices

Definition

Microservices security requires a zero-trust approach where every service interaction is authenticated and authorized. Key patterns include service-to-service authentication with mutual TLS, token-based authorization with JWT, API gateway security enforcement, secrets management, and security scanning in CI/CD pipelines. Unlike monolithic applications with perimeter security, microservices implement security at every layer and service boundary, assuming that the network and internal systems could be compromised.

Analogy

Security in microservices is like implementing security for a large corporate campus with multiple buildings, departments, and contractors working together. Instead of just having security guards at the main entrance (perimeter security), every building has its own access controls, employees verify each other's identities when sharing sensitive information, and even internal communications use encrypted channels. Visitors need special badges for each building they visit, and these badges expire regularly. Contractors have limited access that's automatically reviewed and updated. Security cameras monitor interactions between buildings, and there are protocols for securely sharing documents between departments. If one building's security is compromised, it doesn't automatically give access to other buildings. Each department maintains its own sensitive files in secure locations, and there are automated systems that detect unusual access patterns or unauthorized attempts to move between areas. This comprehensive approach ensures that security is maintained even if individual components are compromised.

Examples

Service-to-service authentication:

@Component
public class ServiceAuthenticationFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        String serviceToken = extractServiceToken(request);
        if (validateServiceToken(serviceToken)) {
            chain.doFilter(request, response);
        } else {
            response.sendError(HttpStatus.UNAUTHORIZED.value());
        }
    }
}

JWT token validation:

@Component
public class JwtTokenValidator {
    public boolean validateToken(String token) {
        try {
            Claims claims = Jwts.parserBuilder()
                .setSigningKey(secretKey)
                .build()
                .parseClaimsJws(token)
                .getBody();
            return !isTokenExpired(claims);
        } catch (JwtException e) {
            return false;
        }
    }
}

Secrets management:

# Kubernetes secrets
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: 
  password: 

Security policy enforcement:

@PreAuthorize("hasRole('ADMIN') or @orderService.isOwner(#orderId, authentication.name)")
@DeleteMapping("/orders/{orderId}")
public void deleteOrder(@PathVariable String orderId) {
    orderService.delete(orderId);
}

Testing Strategies

Definition

Microservices testing requires a layered approach: unit tests for individual components, integration tests for service interactions, contract tests to ensure API compatibility, and end-to-end tests for complete user journeys. Advanced strategies include consumer-driven contract testing, service virtualization for isolating dependencies, chaos engineering for resilience testing, and continuous testing in production. The testing pyramid shifts in microservices to emphasize integration and contract testing while minimizing expensive end-to-end tests.

Analogy

Testing microservices is like quality assurance for a complex manufacturing supply chain with multiple suppliers, assembly plants, and distribution centers. You can't just test the final product - you need quality checks at every stage. Individual component testing is like inspecting parts from each supplier to ensure they meet specifications. Integration testing verifies that parts from different suppliers work together correctly when assembled. Contract testing ensures that when Supplier A promises to deliver parts with specific dimensions, they actually do, so Supplier B's assembly process doesn't break. End-to-end testing follows a complete product from raw materials through final delivery to ensure the entire supply chain works together. You also need chaos testing - deliberately introducing problems like supplier delays or equipment failures to ensure the supply chain can adapt and continue operating. This comprehensive testing approach ensures that even though the supply chain is complex and distributed, the final products consistently meet quality standards.

Examples

Contract testing with Pact:

@ExtendWith(PactConsumerTestExt.class)
class OrderServiceContractTest {
    @Pact(consumer = "order-service", provider = "user-service")
    public RequestResponsePact getUserPact(PactDslWithProvider builder) {
        return builder
            .given("user exists")
            .uponReceiving("get user by id")
            .path("/users/123")
            .method("GET")
            .willRespondWith()
            .status(200)
            .body(LambdaDsl.newJsonBody(o -> o.stringValue("name", "John")).build())
            .toPact();
    }
}

Integration test with test containers:

@SpringBootTest
@Testcontainers
class OrderIntegrationTest {
    @Container
    static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:13");

    @Test
    void shouldCreateOrder() {
        OrderRequest request = new OrderRequest("user123", items);
        Order order = orderService.create(request);
        assertThat(order.getId()).isNotNull();
    }
}

Chaos engineering test:

@Test
void shouldHandleUserServiceFailure() {
    // Simulate user service being down
    userServiceStub.stubFor(get(urlMatching("/users/.*"))
        .willReturn(aResponse().withStatus(500)));

    // Order service should gracefully degrade
    OrderRequest request = new OrderRequest("user123", items);
    assertThatThrownBy(() -> orderService.create(request))
        .isInstanceOf(ServiceUnavailableException.class);
}

Performance testing:

@Test
void shouldHandleHighLoad() {
    List> futures = IntStream.range(0, 1000)
        .mapToObj(i -> CompletableFuture.supplyAsync(() ->
            orderService.create(createTestOrder())))
        .collect(toList());

    CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
    // Verify all orders created successfully
}

Organizational Patterns

Definition

Microservices success requires organizational changes that align team structure with service architecture. Conway's Law states that organizations design systems that mirror their communication structure, so effective microservices require autonomous teams, clear ownership boundaries, and decentralized decision-making. Key patterns include two-pizza teams, cross-functional teams that own services end-to-end, DevOps practices that enable teams to deploy independently, and platform teams that provide shared infrastructure and tools.

Analogy

Organizational patterns for microservices are like restructuring a large traditional company into autonomous business units that operate like small startups within the larger organization. Instead of having separate departments for design, engineering, marketing, and operations that all work on every project, you create small, cross-functional teams where each team has its own designers, engineers, marketers, and operations people focused on a specific product or customer segment. Each team can make decisions quickly without requiring approval from multiple departments, choose their own tools and processes, and deploy their products independently. The corporate headquarters provides shared services like legal, HR, and IT infrastructure, but doesn't micromanage how each business unit operates. This structure enables rapid innovation and adaptation because teams can respond to market changes without coordinating with dozens of other teams. However, it requires careful attention to how teams communicate and coordinate to ensure the overall company strategy remains coherent.

Examples

Service ownership model:

# RACI matrix for user service
user-service:
  responsible: user-team
  accountable: user-team-lead
  consulted: [platform-team, security-team]
  informed: [product-owner, architecture-team]

Team API contract:

/**
 * User Service API
 * Owner: User Team (user-team@company.com)
 * SLA: 99.9% uptime, <100ms response time
 * On-call: user-team rotation
 * Documentation: https://wiki.company.com/user-service
 */
@RestController
public class UserController {
    // Service implementation
}

Platform capabilities:

# Platform team provides
infrastructure:
  - kubernetes-clusters
  - monitoring-stack
  - logging-platform
  - ci-cd-pipeline
  - security-scanning

self-service:
  - deployment-templates
  - monitoring-dashboards
  - alerting-rules

Team autonomy guidelines:

# Team Decision Authority
## Can decide independently:
- Technology stack within service
- Deployment frequency and timing
- Database schema for owned data
- Internal API design

## Must coordinate:
- Public API changes
- Breaking changes to dependencies
- Security policy changes
- Infrastructure capacity planning

Migration Strategies

Definition

Migrating from monolithic to microservices architecture requires careful planning and incremental approaches to minimize risk and maintain business continuity. Effective strategies include the strangler fig pattern (gradually replacing monolith functionality), database decomposition techniques, API extraction patterns, and branch-by-abstraction for safe transitions. Successful migrations balance the benefits of microservices with the complexity of distributed systems, often taking months or years to complete while maintaining system functionality throughout the process.

Analogy

Migrating from a monolith to microservices is like renovating a busy airport while keeping flights operating normally. You can't shut down the entire airport and rebuild it from scratch - passengers need to keep traveling, airlines need to maintain schedules, and revenue must continue flowing. Instead, you renovate terminal by terminal, gate by gate, and system by system. You might start by building a new terminal (extracting a service) while keeping the old one operational, then gradually redirecting passengers (traffic) to the new facilities as they're completed and tested. Some services like baggage handling (shared data) require careful coordination between old and new systems. You need temporary bridges and tunnels (integration patterns) to connect old and new infrastructure during the transition. The renovation might take years, but throughout the process, passengers experience minimal disruption and might not even notice the changes. The key is meticulous planning, incremental changes, and always having fallback plans if something goes wrong during the transition.

Examples

Strangler fig pattern implementation:

@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        if (featureToggle.isEnabled("new-user-service")) {
            return newUserService.getUser(id);  // New microservice
        }
        return legacyUserService.getUser(id);   // Legacy monolith
    }
}

Database decomposition strategy:

// Phase 1: Extract service with shared database
@Service
public class UserService {
    public User createUser(User user) {
        // Still uses shared database during transition
        return sharedDatabase.save(user);
    }
}

// Phase 2: Migrate to dedicated database
@Service
public class UserService {
    public User createUser(User user) {
        return userDatabase.save(user);  // Own database
    }
}

API facade for gradual migration:

@Component
public class UserServiceFacade {
    public User getUser(Long id) {
        try {
            return newUserService.getUser(id);
        } catch (Exception e) {
            logger.warn("New service failed, falling back to legacy", e);
            return legacyService.getUser(id);
        }
    }
}

Migration progress tracking:

@Component
public class MigrationMetrics {
    private final Counter newServiceCalls = Counter.builder("migration.new.service.calls").register(registry);
    private final Counter legacyServiceCalls = Counter.builder("migration.legacy.service.calls").register(registry);

    public void recordServiceCall(boolean useNewService) {
        if (useNewService) {
            newServiceCalls.increment();
        } else {
            legacyServiceCalls.increment();
        }
    }
}

Summary

You have now completed your comprehensive journey from Spring Boot fundamentals to advanced microservices mastery. This final lesson has equipped you with the sophisticated patterns and practices needed to build enterprise-grade distributed systems: managing data consistency across services through sagas and event sourcing, implementing zero-downtime deployments with blue-green and canary strategies, ensuring comprehensive observability across complex distributed systems, and organizing teams effectively to support microservices at scale. You understand how to migrate from monolithic applications incrementally, secure distributed systems with zero-trust principles, and test complex service interactions effectively. These advanced topics represent the culmination of modern software architecture practices, enabling you to build systems that can scale to serve millions of users while maintaining reliability, security, and development velocity. The patterns and practices you've learned form the foundation for building the next generation of cloud-native applications that power today's most successful digital businesses. Your journey from Spring Boot basics to microservices expertise prepares you to tackle the most challenging distributed system problems and architect solutions that can grow with your organization's needs.

Programming Challenge