⚙️ Microservices Design Patterns (Complete Enterprise Guide)

Microservices Architecture Taxonomy

Microservice architecture breaks down large applications into small, independently deployable services. While this architecture increases developer velocity and scaling efficiency, it introduces complex challenges around distributed consistency, network resilience, and operational observability. Below is the full index of 32 Microservices Design Patterns grouped by domain:

Category 1: Decomposition Patterns

1. Decompose by Business Capability

Problem: Monolithic codebases group features by technical layers (Controllers, Services, DAOs). Changes in one feature risk breaking unrelated modules and force full-application redeployments.

Solution: Organize microservices around high-level business capabilities (e.g., Order Processing, Payment, Inventory Management). Each microservice encapsulates its own controllers, business logic, and storage.

Real-World Use Case: An E-Commerce platform splits into Order-Service, Payment-Service, and Inventory-Service so the payment team can deploy independently without touching order code.

@RestController
@RequestMapping("/api/v1/orders")
public class OrderController {
    private final OrderService orderService;

    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @PostMapping
    public ResponseEntity<OrderResponse> createOrder(@Valid @RequestBody OrderRequest request) {
        OrderResponse response = orderService.processOrder(request);
        return ResponseEntity.status(HttpStatus.CREATED).body(response);
    }
}

2. Decompose by Domain-Driven Design (DDD) Subdomain

Problem: Business terminology is ambiguous across different departments. A Customer entity in Sales has address and preferences, whereas in Finance it has credit limits and tax IDs.

Solution: Identify DDD Bounded Contexts. Classify subdomains into Core (competitive advantage), Supporting (business-specific helper functions), and Generic (standard non-differentiating features like Billing or Notifications).

// Order Context's view of Customer (Minimal Data Required for Order Placement)
public record OrderCustomer(
    UUID customerId,
    String name,
    ShippingAddress shippingAddress
) {}

3. Strangler Fig Pattern

Problem: Rewriting a massive legacy monolith from scratch ("Big Bang") is extremely high-risk and usually fails due to shifting business requirements during development.

Solution: Place an API Gateway in front of the monolith. Gradually replace monolithic endpoints one by one with new microservices, shifting gateway route rules over time until the monolith shrinks to zero.

spring:
  cloud:
    gateway:
      routes:
        # 1. New Microservice (Strangled Payment Route)
        - id: payment-microservice
          uri: lb://PAYMENT-SERVICE
          predicates:
            - Path=/api/v2/payments/**
        # 2. Legacy Monolith (Fallback for unstrangled endpoints)
        - id: legacy-monolith
          uri: http://monolith-cluster.internal:8080
          predicates:
            - Path=/**

4. Sidecar Pattern

Problem: Co-locating operational tasks (mTLS certificate renewal, log extraction, proxy routing) inside the main Java application pollutes code, increases memory footprint, and restricts polyglot adoption.

Solution: Deploy a separate helper container (e.g., Envoy proxy, FluentBit log collector) inside the same Kubernetes Pod, sharing network and volume storage with the application container.

Category 2: Integration & Communication Patterns

5. API Gateway Pattern

Problem: Exposing internal microservice IP addresses directly to mobile and web clients causes security vulnerabilities, CORS issues, protocol mismatches, and client-side chatty calls.

Solution: Implement a single facade entry point (Spring Cloud Gateway) that handles routing, SSL termination, JWT token verification, and global rate limiting.

@Bean
public RouteLocator gatewayRoutes(RouteLocatorBuilder builder, JwtAuthFilter authFilter) {
    return builder.routes()
        .route("order-service", r -> r.path("/orders/**")
            .filters(f -> f.filter(authFilter))
            .uri("lb://ORDER-SERVICE"))
        .build();
}

6. Aggregator Pattern

Problem: Rendering a dashboard requires data from 4 microservices. Making 4 sequential HTTP calls from a client device multiplies latency and drains battery power.

Solution: The API Gateway or an Aggregator Service invokes downstream microservices in parallel using non-blocking futures, combining the payload into a single unified JSON response.

public DashboardResponse getDashboard(String userId) {
    CompletableFuture<UserProfile> userFuture = CompletableFuture.supplyAsync(() -> userClient.getUser(userId));
    CompletableFuture<List<Order>> ordersFuture = CompletableFuture.supplyAsync(() -> orderClient.getOrders(userId));
    CompletableFuture<RewardPoints> pointsFuture = CompletableFuture.supplyAsync(() -> rewardsClient.getPoints(userId));

    CompletableFuture.allOf(userFuture, ordersFuture, pointsFuture).join();

    return new DashboardResponse(userFuture.join(), ordersFuture.join(), pointsFuture.join());
}

7. Service Discovery Pattern

Problem: In containerized cloud environments (Kubernetes, AWS ECS), instances launch and terminate dynamically, assigning random IP addresses that make static configuration impossible.

Solution: Microservices automatically register their dynamic IP/port with a Service Registry (Netflix Eureka / HashiCorp Consul) on startup. Callers look up service names rather than hardcoded IPs.

8. Asynchronous Messaging Pattern

Problem: Synchronous REST calls block web threads. If a downstream notification service is slow, the upstream checkout process hangs and fails.

Solution: The producer service publishes events to a high-throughput message broker (Apache Kafka / RabbitMQ). Consumers process events asynchronously without blocking the producer.

@Service
public class OrderEventListener {

    @KafkaListener(topics = "order-events", groupId = "notification-group")
    public void handleOrderCreated(OrderCreatedEvent event) {
        log.info("Received OrderCreatedEvent for order: {}", event.getOrderId());
        emailService.sendOrderConfirmation(event.getCustomerEmail());
    }
}

9. Asynchronous Request-Reply Pattern

Problem: Generating a monthly PDF report takes 45 seconds. Synchronous HTTP connections time out after 30 seconds.

Solution: The server immediately returns HTTP status 202 Accepted with a Location header pointing to a polling status URL (e.g., /api/reports/status/9821).

10. Webhook Pattern

Problem: Polling an external payment gateway every 5 seconds to check if a transaction completed wastes network bandwidth and server resources.

Solution: The external provider sends an HTTP POST event to the client's registered callback URL when state changes, authenticated via HMAC SHA-256 signatures.

Category 3: Data Management & Distributed Consistency

11. Database per Service Pattern

Problem: Shared databases create direct coupling. A schema change by the User team breaks the Billing team's queries, and one service's slow query locks tables for all other services.

Solution: Give each microservice its own private database. Data exchange occurs strictly via REST APIs or domain events.

12. Shared Database Pattern (Controlled Migration)

Problem: Completely splitting a legacy relational database into 20 separate databases overnight is impossible due to complex SQL joins.

Solution: Temporarily share a single database, isolating service data access using separate DB schemas and views until services can be fully migrated to Database per Service.

13. Saga Pattern (Choreography & Orchestration)

Problem: Distributed transactions spanning 3 microservices cannot use 2-Phase Commit (2PC) without severe locking overhead and availability loss (CAP Theorem).

Solution: Execute a sequence of local ACID transactions. If a step fails, trigger a sequence of Compensating Transactions in reverse order to roll back state.

@Service
public class OrderSagaOrchestrator {

    @Autowired private PaymentClient paymentClient;
    @Autowired private InventoryClient inventoryClient;

    public void executeOrderSaga(OrderRequest request) {
        String paymentId = paymentClient.charge(request.getAmount());
        try {
            inventoryClient.reserveStock(request.getItems());
        } catch (InventoryException e) {
            // Compensating Action: Undo payment charge
            paymentClient.refund(paymentId);
            throw new SagaFailedException("Stock unavailable. Refunded payment.");
        }
    }
}

14. CQRS (Command Query Responsibility Segregation)

Problem: A complex domain model optimized for write validation causes slow multi-table SQL joins when executing complex search queries.

Solution: Separate the Write Model (Commands) from the Read Model (Queries). Commands mutate a relational DB; events asynchronously update a read-optimized Elasticsearch or Redis store.

15. Event Sourcing Pattern

Problem: Overwriting database records destroys audit history. Finding out what state an account was in 3 weeks ago is impossible.

Solution: Store state changes as an immutable sequence of events in an append-only event log. Reconstruct current state by replaying events from genesis.

16. Transactional Outbox Pattern

Problem: Updating a database and publishing a Kafka message in one method can fail (Dual-Write Problem: DB commits, but Kafka crashes -> data inconsistency).

Solution: Save the entity AND an Outbox Event record in the SAME local database ACID transaction. A background poller reads outbox entries and safely publishes them to Kafka.

@Transactional
public void placeOrder(Order order) {
    orderRepository.save(order);
    
    OutboxEvent outbox = new OutboxEvent(
        "OrderService", 
        "ORDER_PLACED", 
        objectMapper.writeValueAsString(order)
    );
    outboxRepository.save(outbox); // Both saved in 1 atomic DB commit!
}

17. Change Data Capture (CDC) Pattern

Problem: Polling an outbox table continuously strains the application database.

Solution: Use tools like Debezium to read database Write-Ahead Logs (WAL) directly at the database engine level, streaming updates into Kafka with zero application performance impact.

18. Distributed Lock Pattern

Problem: Running 5 replicas of a background scheduler service causes all 5 instances to run the same batch billing job concurrently.

Solution: Use a distributed lock manager (ShedLock with Redis / ZooKeeper Redlock) to ensure only ONE instance acquires the lock and executes the job.

Category 4: Resilience & Reliability Patterns

19. Circuit Breaker Pattern

Problem: When a downstream service crashes, caller threads hang waiting for socket timeouts, eventually exhausting web server thread pools and crashing the caller (Cascading Failure).

Solution: Resilience4j monitors error rates. When failure thresholds exceed limits, the circuit trips to OPEN, immediately failing fast and calling a Fallback method without making network requests.

@Service
public class PaymentService {

    @CircuitBreaker(name = "paymentGateway", fallbackMethod = "handleFallback")
    public PaymentResponse charge(PaymentRequest req) {
        return externalGateway.process(req);
    }

    public PaymentResponse handleFallback(PaymentRequest req, Throwable t) {
        log.warn("Circuit OPEN. Triggering fallback for payment: {}", t.getMessage());
        return new PaymentResponse("QUEUED_OFFLINE", "Gateway unavailable");
    }
}

20. Bulkhead Pattern

Problem: A slow recommendation service consumes 100% of the web server's thread pool, rendering critical login and checkout endpoints unresponsive.

Solution: Isolate thread pools or semaphores per downstream target so that failure in one dependency cannot consume resources allocated to other services.

21. Rate Limiting / Throttling Pattern

Problem: Traffic spikes or malicious bots overwhelm endpoints, crashing services for all users.

Solution: Limit incoming request volume per API key, IP address, or user ID using token bucket algorithms (Bucket4j / Redis RateLimiter).

22. Retry Pattern with Exponential Backoff & Jitter

Problem: Retrying failed requests instantly with fixed intervals causes a "Thundering Herd" that completely crushes a recovering service.

Solution: Retry transient failures with exponentially increasing delays plus random jitter (e.g., 100ms, 350ms, 850ms).

23. Fallback Pattern

Problem: Downstream failures cause raw 500 error pages to display on user screens.

Solution: Provide a graceful degraded fallback experience (e.g., displaying cached recommendations or default values when recommendation service fails).

24. Timeout Pattern

Problem: Requests without explicit timeouts block worker threads indefinitely when network sockets freeze.

Solution: Enforce strict SLAs (e.g., 1200ms timeout) using Spring WebClient or Resilience4j TimeLimiter.

Category 5: Observability & Operations

25. Distributed Tracing Pattern

Problem: A single user action triggers HTTP calls across 8 microservices. Diagnosing which service caused a 5-second latency delay is impossible without context.

Solution: Inject a unique Trace-ID and Span-ID into HTTP headers (using Micrometer Tracing / Zipkin). Every microservice logs these IDs, allowing Zipkin/Jaeger to visualize the entire request trace tree.

2026-07-25 14:30:10.102 INFO [order-service,traceId=8a9f31c7d2e4,spanId=1a2b] - Received Order #442
2026-07-25 14:30:10.250 INFO [payment-service,traceId=8a9f31c7d2e4,spanId=3c4d] - Charging credit card
2026-07-25 14:30:10.410 INFO [inventory-service,traceId=8a9f31c7d2e4,spanId=5e6f] - Reserving stock items

26. Centralized Logging Pattern

Problem: SSH-ing into 40 separate server instances to inspect log files is inefficient and impossible in Kubernetes autoscaling environments.

Solution: Format logs as structured JSON to stdout. Log aggregators (Filebeat/FluentBit) ship logs to Elasticsearch / Kibana (ELK Stack) for instant global search.

27. Health Check API Pattern

Problem: Kubernetes needs to know if a Java application is alive (Liveness) and ready to receive traffic (Readiness).

Solution: Expose Spring Boot Actuator `/actuator/health` endpoints that check database connections, disk space, and queue health.

28. Metrics Aggregation Pattern

Problem: Lack of real-time operational metrics (JVM heap usage, GC pause times, HTTP 5xx rates).

Solution: Expose Micrometer metrics for Prometheus scraping; visualize real-time operational performance in Grafana dashboards.

29. Externalized Configuration Pattern

Problem: Recompiling code just to update database credentials or feature flags across Dev, Staging, and Production environments is error-prone.

Solution: Store configuration in a central Spring Cloud Config Server / Vault; dynamically update properties at runtime using @RefreshScope without service restarts.

Category 6: Security & Deployment Patterns

30. OAuth2 / OIDC Token Relay Pattern

Problem: Downstream microservices need to identify the authenticated user without forcing the user to re-authenticate on every service call.

Solution: The API Gateway authenticates the user, verifies OAuth2 JWT tokens, and forwards the Authorization: Bearer <JWT> header downstream across service hops.

31. Service Mesh Pattern

Problem: Implementing mTLS encryption, retries, and telemetry inside Java code bloats application dependencies and restricts polyglot architecture.

Solution: Deploy a Service Mesh (Istio / Linkerd) that runs Envoy sidecar proxies next to application containers, handling mTLS security and traffic control transparently.

32. Blue-Green & Canary Deployment Patterns

Problem: Deploying new code releases all at once risks application downtime and widespread user impact if bugs exist.

Solution: Blue-Green maintains two identical environments, switching 100% router traffic to the new environment instantly. Canary routes a small fraction (e.g., 5%) of live traffic to the new version first, monitoring error rates before full rollout.

Quick Reference: All 32 Patterns Summary

🎯 Frequently Asked Interview Questions