오픈마켓 여행 플랫폼의 실전 API 연동 노하우

여행 플랫폼은 지마켓 커머스 시스템과 OTA 서버의 API를 함께 엮어 동작하므로, 한 화면과 한 예약 흐름에 10개 이상의 API가 관여할 수 있다. 그래서 기능별 중요도와 응답 특성을 기준으로 연동 전략을 다르게 가져가야 한다.

여행 상품 상세 페이지는 fault tolerance가 가장 중요하다. 중요도가 낮은 API는 타임아웃을 짧게 잡아 지연 전파를 막고, 가격·재고처럼 핵심적인 API는 응답이 오래 걸리더라도 더 기다린다. 할인 가격 API처럼 장애가 나면, resilience4j의 CircuitBreaker와 fallbackMethod로 원가를 대신 보여주는 식의 fallback을 둘 수 있다.

실시간 예약은 eventual consistency와 idempotency를 보장해야 한다. 결제와 정산, 서비스 제공이 연결된 만큼 여행 플랫폼, 커머스 시스템, OTA의 상태를 같은 단계로 맞춰야 하며, 이를 위해 각 시스템의 상태를 정의하고 서로 매칭하는 state machine을 만든다.

상태가 어긋나면 오케스트레이터 성격의 대사 배치가 각 시스템의 예약 상태를 확인하고 재연동한다. 일시적 장애나 타임아웃으로 호출이 실패해도, 실제로는 서버 처리가 끝났을 수 있으므로 재시도 전에 중복 여부를 따져야 한다.

• 중복 요청 에러 코드가 명시되면 그 요청은 성공으로 간주한다.
• 에러 코드가 없으면 상태 조회 API로 진행 가능 여부를 확인한다.
• 아직 전이되지 않은 상태라면 spring-retry의 backoff로 일정 시간 뒤 재시도한다.

그래도 해결되지 않으면 보상 트랜잭션으로 원상 복구해야 한다. 되돌리기 쉬운 외부 시스템부터 먼저 연동하고, 금전 거래와 직접 연결된 OTA 실예약처럼 취소가 어렵거나 위약금이 붙는 요청은 가장 마지막에 두는 것이 안전하다.