11/11

졸용·2025년 11월 11일

TIL

목록 보기
112/144

🔹 FeignClient 적용 과정의 고민

@FeignClient(
    name = "hubClient",
    url = "${clients.hub.url}",
    configuration = ai_service.infra.config.FeignConfig.class
)
public interface HubClient {

    @GetMapping("/v1/hubs/addresses")
    List<HubAddressForAiResponseV1> getAddresses(@RequestParam("ids") List<UUID> addressIds);
}

"여기서 ddress를 리스트 형태로 가져오지 않고, 허브 서비스 쪽에 있는 허브 주소 단건 조회를 가져오는 거로 수정하면, AiService 쪽에서 로직이 좀 더 단순화 될까?"
를 고민해봤다.

결론은, 장점보다 단점이 더 크다고 생각했다.

단건 조회로 바꾸면 AiService의 코드가 ‘약간’ 단순해질 수는 있지만, 운영 관점에서는 N+1 네트워크 호출로 성능/안정성이 악화될 가능성이 크다.
그래서 보통은 “배치 조회 유지 + 헬퍼 메서드로 의미를 드러내는 방식”을 가장 권장한다고 한다.


🔸 무엇이 단순해지나?

  • 단건 API로 바꾸면 addrResponses → toMap() 같은 변환 로직 없이, 그때그때 라벨만 뽑는 헬퍼를 쓰면 된다.
  • 예: labelOf(UUID id) 같은 메서드를 두고 shipFromvia에서 재사용.

🔸 리스크

  • N+1 호출: via 허브가 5개면 HTTP 6번(출발지 1 + 경유지 5) 왕복 → 지연시간 증가, 장애면 발화 지점 확대.
  • 부분 실패 복구가 더 어려움: 배치면 1회 응답으로 누락/실패 id를 한 번에 처리하기 쉬움.
  • 정렬/중복 처리: via 순서를 유지하며 중복 제거하려면 결국 클라이언트에서 별도 로직이 필요.
profile
꾸준한 공부만이 답이다

0개의 댓글