// Trade-offs: Monolith vs Microservices

// MONOLITH — Choose when:
// ✓ Small team (< 10 developers)
// ✓ Simple domain with few bounded contexts
// ✓ Need to move fast and iterate quickly
// ✓ Shared database is acceptable
// ✓ Single deployment pipeline is manageable

// MICROSERVICES — Choose when:
// ✓ Multiple teams need to deploy independently
// ✓ Clear bounded contexts (orders, payments, inventory)
// ✓ Different services need different scaling
// ✓ Technology diversity is needed (Java for payments, Python for ML)
// ✓ Failure isolation is critical (payment down ≠ search down)

// THE WRONG REASON to choose microservices:
// ✗ "Because Netflix does it"
// ✗ "Because it is modern"
// ✗ "Because monoliths are bad"

// The right approach: Start monolith → identify boundaries → extract services

// API Gateway — Single entry point for all microservices

// Client → API Gateway → Microservices
//                      → User Service
//                      → Order Service
//                      → Payment Service

// What the API Gateway handles:
// 1. Routing — directs requests to the correct service
// 2. Authentication — validates JWT tokens before forwarding
// 3. Rate Limiting — prevents abuse (100 requests/minute per user)
// 4. Load Balancing — distributes traffic across service instances
// 5. Response Aggregation — combines responses from multiple services

// Spring Cloud Gateway example:
spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://USER-SERVICE
          predicates:
            - Path=/api/users/**
          filters:
            - StripPrefix=1
        - id: order-service
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/api/orders/**

// Popular API Gateways:
// Kong, AWS API Gateway, Spring Cloud Gateway, NGINX

// Saga Pattern — Two approaches:

// 1. CHOREOGRAPHY (event-driven, no central coordinator)
// Order Service → publishes "OrderCreated" event
// Payment Service → listens, processes payment → publishes "PaymentCompleted"
// Inventory Service → listens, reserves stock → publishes "InventoryReserved"
// Shipping Service → listens, creates shipment → publishes "ShipmentCreated"

// If Inventory fails after Payment succeeds:
// Inventory Service → publishes "InventoryFailed"
// Payment Service → listens → refunds payment (compensating transaction)
// Order Service → listens → marks order as failed

// 2. ORCHESTRATION (central coordinator manages the flow)
// Saga Orchestrator controls the sequence:
//   Step 1: Call Payment Service → success
//   Step 2: Call Inventory Service → FAILS
//   Step 3: Call Payment Service → refund (compensating transaction)
//   Step 4: Update Order → failed

// Choreography: simpler, loosely coupled, harder to debug
// Orchestration: centralized control, easier to understand, single point of failure

// SYNCHRONOUS — REST / gRPC
// Use when: caller needs immediate response
// Example: User places order → Payment must confirm before proceeding

// REST call (Spring Boot WebClient)
public Mono<PaymentResponse> processPayment(PaymentRequest request) {
    return webClient.post()
        .uri("/api/payments")
        .bodyValue(request)
        .retrieve()
        .bodyToMono(PaymentResponse.class);
}

// ASYNCHRONOUS — Message Queues / Kafka
// Use when: caller can continue without waiting
// Example: Order confirmed → Send email notification (no need to wait)

// Kafka producer (Spring Boot)
@Service
public class OrderService {
    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public void placeOrder(Order order) {
        // Process order synchronously
        orderRepository.save(order);
        // Send notification asynchronously
        kafkaTemplate.send("order-events", new OrderEvent(order.getId(), "CREATED"));
    }
}

// Sync: REST, gRPC — real-time, tight coupling, cascading failure risk
// Async: Kafka, RabbitMQ — eventual consistency, loose coupling, resilient

// Event-Driven Architecture
// Services publish events → Event bus → Other services consume events

// Example: Order placed → multiple services react independently
// Order Service publishes "OrderPlaced" event to Kafka

@Service
public class OrderService {
    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public Order createOrder(OrderRequest request) {
        Order order = orderRepository.save(new Order(request));
        // Publish event — other services react independently
        kafkaTemplate.send("order-events", OrderEvent.created(order));
        return order;
    }
}

// Payment Service listens and processes payment
@KafkaListener(topics = "order-events", groupId = "payment-service")
public void handleOrderEvent(OrderEvent event) {
    if (event.getType().equals("CREATED")) {
        paymentService.processPayment(event.getOrderId());
    }
}

// Notification Service listens and sends email
@KafkaListener(topics = "order-events", groupId = "notification-service")
public void handleOrderEvent(OrderEvent event) {
    if (event.getType().equals("CREATED")) {
        emailService.sendOrderConfirmation(event.getOrderId());
    }
}

// Advantages: loose coupling, independent scaling, resilience
// Disadvantages: eventual consistency, debugging complexity, event ordering

// DATABASE PER SERVICE (recommended)
// Each service has its own database — complete data ownership

// Order Service → orders_db (PostgreSQL)
// Payment Service → payments_db (PostgreSQL)
// Product Service → products_db (MongoDB)
// Search Service → search_index (Elasticsearch)

// Challenge: How to query across services?
// Solution 1: API Composition
// The API Gateway or a composite service calls multiple services
// and combines the results

public OrderDetails getOrderDetails(Long orderId) {
    Order order = orderService.getOrder(orderId);
    User user = userService.getUser(order.getUserId());
    Payment payment = paymentService.getPayment(orderId);
    return new OrderDetails(order, user, payment);
}

// Solution 2: CQRS (Command Query Responsibility Segregation)
// Separate read and write models
// Write: each service writes to its own database
// Read: a denormalized read database combines data from all services
// Events sync data from write databases to the read database

// SHARED DATABASE (anti-pattern)
// ✗ Services coupled through schema
// ✗ Cannot deploy independently
// ✗ Cannot scale independently
// ✗ One service's migration breaks another

// Distributed Transactions — Three approaches:

// 1. TWO-PHASE COMMIT (2PC) — Avoid in microservices
// Coordinator asks all services to prepare → then commit
// Problem: blocking, single point of failure, poor performance
// Only use for databases within the same service

// 2. SAGA PATTERN (preferred for microservices)
// Break transaction into local transactions with compensating actions
// Order: Create → Pay → Reserve Inventory → Ship
// If Reserve fails: Refund Payment → Cancel Order

// 3. EVENTUAL CONSISTENCY
// Accept that data will be consistent eventually, not immediately
// Example: Order shows "Processing" while payment is being confirmed
// The system converges to a consistent state within seconds

// CAP Theorem in practical terms:
// Consistency: every read gets the most recent write
// Availability: every request gets a response
// Partition Tolerance: system works despite network failures

// In microservices, you MUST handle partitions (network is unreliable)
// So the real choice is: Consistency OR Availability
// Most microservices choose Availability + Eventual Consistency
// Banking/payments may choose Consistency + accept some unavailability

// Circuit Breaker with Resilience4j (Spring Boot)

@Service
public class OrderService {

    private final PaymentClient paymentClient;

    @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
    public PaymentResponse processPayment(PaymentRequest request) {
        return paymentClient.charge(request);
    }

    // Fallback when circuit is OPEN (payment service is down)
    public PaymentResponse paymentFallback(PaymentRequest request, Throwable t) {
        // Queue payment for retry, show user "payment processing"
        paymentQueue.add(request);
        return new PaymentResponse("PENDING", "Payment queued for processing");
    }
}

// Circuit Breaker States:
// CLOSED → requests pass through normally
//   If failure rate > threshold (e.g., 50% of last 10 calls)
// OPEN → requests fail immediately, return fallback
//   After wait duration (e.g., 30 seconds)
// HALF-OPEN → allow a few test requests through
//   If test requests succeed → back to CLOSED
//   If test requests fail → back to OPEN

// Resilience4j configuration:
resilience4j.circuitbreaker:
  instances:
    paymentService:
      failureRateThreshold: 50
      waitDurationInOpenState: 30s
      slidingWindowSize: 10

// Service Discovery — Two approaches:

// 1. CLIENT-SIDE DISCOVERY (Eureka)
// Services register with a registry (Eureka Server)
// Clients query the registry to find service instances
// Client does the load balancing

// Eureka Server
@EnableEurekaServer
@SpringBootApplication
public class DiscoveryServer { }

// Service registers itself
@EnableEurekaClient
@SpringBootApplication
public class OrderService { }

// Client discovers and calls service by name
@FeignClient(name = "payment-service") // Eureka resolves the name
public interface PaymentClient {
    @PostMapping("/api/payments")
    PaymentResponse charge(@RequestBody PaymentRequest request);
}

// 2. SERVER-SIDE DISCOVERY (Kubernetes DNS)
// Kubernetes provides built-in service discovery
// Services are accessible via DNS names
// payment-service.default.svc.cluster.local
// Kubernetes handles load balancing via kube-proxy

// Why Kubernetes is winning:
// No need for Eureka — Kubernetes DNS handles discovery natively
// No need for client-side load balancing — Kubernetes does it
// Most Indian product companies are moving to Kubernetes

// Independent Deployment Pipeline (per service)

// Each service has its own:
// 1. Git repository (or monorepo with separate build paths)
// 2. CI/CD pipeline
// 3. Docker image
// 4. Kubernetes deployment

// Dockerfile (per service)
FROM openjdk:17-slim
COPY target/order-service.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

// Kubernetes Deployment (per service)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    spec:
      containers:
        - name: order-service
          image: registry/order-service:v2.1
          ports:
            - containerPort: 8080

// Deployment Strategies:
// Blue-Green: run old and new versions simultaneously, switch traffic
// Canary: route 5% of traffic to new version, monitor, then roll out
// Rolling: replace instances one by one (Kubernetes default)

// The key: each service can be deployed without affecting others
// Order service v2.1 deploys while Payment service stays on v1.8

// Microservices Monitoring — Three Pillars

// 1. DISTRIBUTED TRACING (Jaeger, Zipkin)
// Track a request across all services using a correlation ID
// User request → API Gateway → Order Service → Payment Service → Inventory
// All logs share the same trace ID: "trace-id: abc-123"

// Spring Boot + Micrometer Tracing
// Automatically propagates trace IDs across service calls
management.tracing.sampling.probability=1.0
management.zipkin.tracing.endpoint=http://zipkin:9411/api/v2/spans

// 2. CENTRALIZED LOGGING (ELK Stack)
// Elasticsearch + Logstash + Kibana
// All services send logs to one place
// Search by trace ID to see the full request journey
// Structured logging with correlation IDs:
logger.info("Order created", Map.of(
    "orderId", order.getId(),
    "userId", order.getUserId(),
    "traceId", MDC.get("traceId")
));

// 3. METRICS (Prometheus + Grafana)
// Collect metrics: request rate, error rate, latency (RED method)
// Set alerts: if error rate > 5% or p99 latency > 2s
// Grafana dashboards per service and system-wide

// Correlation IDs — the key to debugging:
// Generate a unique ID at the API Gateway
// Pass it through every service call (HTTP header)
// Include it in every log entry
// Search by correlation ID to trace the full request path