마이크로서비스 설계 — 서비스 경계, 통신 패턴, 데이터 소유권

잘못된 서비스 경계의 증상:
- 하나의 기능을 수정하려면 3~4개 서비스를 동시에 배포해야 함
- 서비스 A가 서비스 B의 DB를 직접 조회함
- 서비스 간 API 호출이 거미줄처럼 얽혀 있음
- "분산된 모놀리식" — 모놀리식의 단점 + 분산 시스템의 단점

이커머스 도메인 예시:

[주문 Context]        [결제 Context]        [배송 Context]
- 주문 생성           - 결제 처리            - 배송 추적
- 주문 취소           - 환불 처리            - 배송 상태 관리
- 주문 이력           - 결제 수단 관리       - 배송지 관리

각 Context가 하나의 마이크로서비스 후보

좋은 경계:
✅ 높은 응집도 — 관련된 기능이 한 서비스 안에 있음
✅ 낮은 결합도 — 다른 서비스 변경에 영향을 적게 받음
✅ 독립 배포 가능 — 이 서비스만 바꿔서 배포할 수 있음
✅ 팀 하나가 소유 — 한 팀이 전체를 책임지는 규모

나쁜 경계:
❌ 기술 레이어로 나눔 (API 서비스, DB 서비스, 로직 서비스)
❌ 하나의 유스케이스가 5개 서비스를 걸침
❌ 서비스 간 양방향 의존이 존재

❌ 기술 기준으로 나눈 서비스:
  - user-api-service (API만 담당)
  - user-logic-service (비즈니스 로직만)
  - user-data-service (DB 접근만)
  → 사용자 관련 변경이 3개 서비스에 동시에 영향

✅ 비즈니스 기준으로 나눈 서비스:
  - user-service (사용자 관련 전부)
  - order-service (주문 관련 전부)
  → 각 서비스가 독립적으로 변경 가능

[주문 서비스] ──HTTP/gRPC──→ [재고 서비스]
     ↑                           |
     └────── 응답 대기 ───────────┘

// REST 기반 동기 호출
@Service
public class OrderService {
    private final RestClient inventoryClient;

    public Order createOrder(CreateOrderRequest request) {
        // 재고 서비스에 동기 호출 — 응답이 올 때까지 대기
        InventoryResponse inventory = inventoryClient
            .get()
            .uri("/api/inventory/{productId}", request.getProductId())
            .retrieve()
            .body(InventoryResponse.class);

        if (!inventory.isAvailable(request.getQuantity())) {
            throw new OutOfStockException("재고 부족");
        }

        return orderRepository.save(Order.from(request));
    }
}

[주문 서비스] ──이벤트 발행──→ [메시지 브로커] ──→ [재고 서비스]
                              (Kafka, RabbitMQ)  ──→ [알림 서비스]
                                                 ──→ [포인트 서비스]

// 이벤트 기반 비동기 통신
@Service
public class OrderService {
    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public Order createOrder(CreateOrderRequest request) {
        Order order = orderRepository.save(Order.from(request));

        // 이벤트만 발행하고 끝 — 소비자가 누군지 모름
        kafkaTemplate.send("order-events",
            new OrderCreated(order.getId(), order.getItems()));

        return order;
    }
}

// 재고 서비스에서 이벤트를 소비
@Service
public class InventoryEventHandler {
    @KafkaListener(topics = "order-events")
    public void handleOrderCreated(OrderCreated event) {
        inventoryService.reserve(event.getItems());
    }
}

// 서킷 브레이커 — 연속 실패 시 호출을 차단
@CircuitBreaker(name = "inventory", fallbackMethod = "fallback")
public InventoryResponse checkInventory(String productId) {
    return inventoryClient.get(productId);
}

// 폴백 — 서킷이 열리면 대체 로직 실행
public InventoryResponse fallback(String productId, Exception e) {
    // 캐시된 재고 정보 반환 또는 "잠시 후 다시 시도" 응답
    return InventoryResponse.unavailable();
}

❌ 공유 데이터베이스
  [주문 서비스] ──→ [공유 DB] ←── [결제 서비스]
  → 스키마 변경이 모든 서비스에 영향
  → 서비스 간 독립성이 사라짐

✅ 서비스별 데이터베이스
  [주문 서비스] ──→ [주문 DB]
  [결제 서비스] ──→ [결제 DB]
  → 각 서비스가 자신의 스키마를 독립적으로 변경

방법 1: API 호출
  주문 서비스가 사용자 이름이 필요 → 사용자 서비스 API 호출
  장점: 항상 최신 데이터
  단점: 서비스 의존성 발생, 지연 추가

방법 2: 이벤트로 데이터 복제
  사용자 서비스가 "이름 변경" 이벤트 발행
  → 주문 서비스가 이벤트를 받아 자체 DB에 사용자 이름 저장
  장점: 다른 서비스 호출 없이 조회 가능
  단점: 데이터 동기화 지연 (결과적 일관성)

방법 3: API Composition
  게이트웨이나 BFF가 여러 서비스의 데이터를 모아서 응답 구성
  장점: 서비스 간 데이터 복제 없음
  단점: 조합 로직 필요, 지연 증가

주문 생성 Saga:

1. 주문 서비스: 주문 생성 (PENDING)
2. 결제 서비스: 결제 처리
3. 재고 서비스: 재고 차감
4. 주문 서비스: 주문 확정 (CONFIRMED)

만약 3단계에서 실패하면?
→ 보상 트랜잭션 실행:
  2. 결제 서비스: 결제 취소 (환불)
  1. 주문 서비스: 주문 취소 (CANCELLED)

// 주문 ID를 파티션 키로 사용 → 같은 주문의 이벤트는 순서 보장
kafkaTemplate.send("order-events", order.getId(), event);

1단계: 같은 DB, 다른 스키마 (schema per service)
2단계: 읽기 전용 뷰를 통한 접근
3단계: 완전히 분리된 DB