Monolith vs Microservices

// Monolith — all modules in one Spring Boot application
@SpringBootApplication
public class ShopApp { ... }

// Modules co-located in the same JVM:
// com.shop.orders    → OrderService, OrderController
// com.shop.inventory → InventoryService, InventoryController
// com.shop.billing   → BillingService, InvoiceController

// Single database — all modules query the same schema
@Service
public class OrderService {
    // Direct method call to InventoryService — in-process, no network
    public Order placeOrder(PlaceOrderRequest req) {
        inventoryService.reserve(req.getItems());   // same JVM
        billingService.charge(req.getCustomerId(), total);
        return orderRepository.save(order);
    }
}

// Pros:
// + Simple local development (one service to run)
// + ACID transactions across all modules
// + Easy debugging (single log stream, one JVM)

// Cons at scale:
// - Any change requires deploying the whole app
// - Team coordination friction — merge conflicts, slow releases
// - Can't scale individual components independently

// Microservices — separate deployments
// order-service   → owns orders DB
// inventory-service → owns inventory DB
// billing-service → owns invoices DB

// Cross-service call via HTTP (synchronous)
@Service
public class OrderService {
    private final InventoryClient inventoryClient;   // Feign/WebClient
    private final BillingClient billingClient;

    public Order placeOrder(PlaceOrderRequest req) {
        // Network call to inventory-service
        inventoryClient.reserve(req.getItems());

        // Network call to billing-service
        billingClient.charge(req.getCustomerId(), total);

        return orderRepository.save(order);
        // Problem: no distributed ACID — need Saga pattern for consistency
    }
}

// Or async via Kafka (event-driven)
public Order placeOrder(PlaceOrderRequest req) {
    Order order = orderRepository.save(order);
    eventPublisher.publish(new OrderPlaced(order.getId(), req.getItems()));
    // inventory-service and billing-service react asynchronously
    return order;
}

// Decision framework

// Favour MONOLITH when:
// ✓ Team < 10 engineers
// ✓ Domain is not yet well understood (bounded contexts unclear)
// ✓ Early-stage product — need to iterate quickly
// ✓ Simple infrastructure (no Kubernetes, service mesh overhead)

// Favour MICROSERVICES when:
// ✓ Multiple autonomous teams (each owns one or more services)
// ✓ Services have different scaling profiles (payment CPU-bound, search IO-bound)
// ✓ Different tech stacks needed per component (ML service in Python, API in Java)
// ✓ High availability requirements — independent deployments reduce blast radius

// Modular Monolith — the pragmatic middle ground
// One deployable unit BUT strong module boundaries enforced by code
// Module A cannot directly access Module B's database layer
// Easy to extract to microservice later when the boundary is proven
// Recommended migration path: Modular Monolith → Strangler Fig → Microservices