Microservices Anti-Patterns

// ANTI-PATTERN: Shared Database — OrderService and InventoryService
// both access the same "shop" database directly

// OrderService
@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    // queries shop.orders table
}

// InventoryService — WRONG: directly queries shop.orders to check order status
@Repository
public interface OrderQueryRepository extends JpaRepository<Order, Long> {
    // BAD: InventoryService depends on OrderService's database schema
    @Query("SELECT o FROM Order o WHERE o.status = 'PLACED'")
    List<Order> findPlacedOrders();
}

// SOLUTION: Each service owns its data; cross-service data via API or events
// OrderService exposes: GET /orders?status=PLACED
// InventoryService calls OrderService's API (or subscribes to order-placed events)

// Or better: InventoryService maintains its own read model
// populated by consuming "order-placed" Kafka events
@KafkaListener(topics = "order-placed")
public void onOrderPlaced(OrderPlacedEvent event) {
    // InventoryService maintains its own copy of relevant order data
    pendingOrderRepository.save(new PendingOrder(event.getOrderId(), event.getItems()));
}

// ANTI-PATTERN: Chatty API requiring N+1 round trips
// GET /orders/1 → GET /customers/42 → GET /addresses/7 → GET /products/101

// Client makes 4 serial API calls to render one order page

// SOLUTION 1: BFF (Backend for Frontend) — gateway aggregates
@RestController
public class OrderDetailBff {

    public OrderDetailResponse getOrderDetail(Long orderId) {
        // Parallel calls (not serial)
        CompletableFuture<Order> orderFuture =
            CompletableFuture.supplyAsync(() -> orderClient.getOrder(orderId));
        CompletableFuture<Customer> customerFuture =
            orderFuture.thenCompose(o ->
                CompletableFuture.supplyAsync(() -> customerClient.getCustomer(o.getCustomerId())));

        CompletableFuture.allOf(orderFuture, customerFuture).join();
        return assemble(orderFuture.join(), customerFuture.join());
    }
}

// ANTI-PATTERN: Deep synchronous call chain — A→B→C→D→E
// OrderService → InventoryService → WarehouseService → ShippingService → CarrierService
// Problems: 5x latency, 5x failure surface, tight coupling

// SOLUTION 2: Event-driven for non-blocking side effects
// OrderService publishes "order-placed" event
// InventoryService, WarehouseService, ShippingService independently react
// No direct coupling, no cascading failures

// ANTI-PATTERN: Nano-Service — service that does one trivial thing
// "TaxCalculationService" with 3 endpoints and 50 lines of code
// Requires: its own database, CI/CD pipeline, Docker image, monitoring

// TEST: Is this a microservice or a function?
// - Does it have its own data store? → NO
// - Can a separate team own it? → Unlikely (too small)
// - Does it benefit from independent scaling? → NO
// VERDICT: merge into OrderService or make it a library

// ANTI-PATTERN: Missing observability
// Incident: "Checkout is slow" — but:
// - No distributed tracing → can't pinpoint which service is slow
// - No centralised logs → grep across 20 pods manually
// - No dashboards → no baseline to compare against
// - No alerting → users report issues before engineers know

// MINIMUM OBSERVABILITY CHECKLIST (per service):
// ✓ Structured JSON logs with traceId/spanId (Loki/ELK)
// ✓ RED metrics (rate, errors, duration) on every endpoint (Prometheus)
// ✓ Distributed tracing (Jaeger via Micrometer Tracing)
// ✓ Health probes (/actuator/health/liveness + /readiness)
// ✓ Alerting on P99 latency > SLO and error rate > threshold
// ✓ Service dependency map (Kiali or Zipkin service graph)