배경

ThirdParty 장애 시 수동 CS 반복, 신규 결제사 추가마다 여러 GW서버가 수정이 반복되는 구조적 한계를 체감하여 개선

문제

Third Party 단일 장애점 및 자동 복구 불가 및 확장성 제한

• ThirdParty 장애 발생 시 재시도/복구 로직 부재 → 실패 건 즉시 유실, 수동 CS로만 대응 가능
• 신규 결제사 추가 시마다 GW 내부 분기 로직 증가, 강결합 구조로 단일 변경이 전체 서비스 배포 유발

의사결정 근거: Kafka를 메시지 브로커로 선택한 이유

• 기존 Kafka 인프라 활용으로 신규 도입 비용 없이 메시지 영속 보관 및 DLQ 체계 구성 가능
• GW와 Worker 사이에 Kafka를 두어 직접 의존 제거 → 결합도 제거로 독립적 배포/확장 가능
• 단, Request-Reply로 인한 스레드 블로킹은 인지된 트레이드오프
  • → 처리량 개선은 향후 Virtual Thread 도입으로 대응 예정

AS-IS

TO-BE

---
config:
  theme: mc
---
sequenceDiagram
    autonumber

    participant C as Client
    participant DGW as Domestic GW
    participant OGW as Overseas GW
    participant TP as Third Party

    C->>DGW: QR 요청

    note right of DGW: 국내 GW -> 해외 GW 직접 동기 호출

    DGW->>OGW: QR 생성 요청
    note right of OGW: 해외 GW가 Third Party 직접 동기 호출

    OGW->>TP: QR 생성 요청
    TP-->>OGW: QR 생성 응답

    OGW-->>DGW: 응답

    DGW-->>C: 응답

---
config:
  theme: mc
---
sequenceDiagram
    autonumber

    participant C as Client
    participant DGW as Domestic GW
    participant K as Kafka
    participant OW as Overseas Worker
    participant TP as Third Party

    C->>DGW: QR생성 요청

    DGW->>K: 이벤트 발행 <br>(payment-request-topic)

    OW->>K: 메시지 Poll <br>(payment-request-topic)

    OW->>TP: QR 생성 요청

    alt          ✅ QR 생성 성공
        TP-->>OW: QR 생성 응답
        OW->>K: 결과 이벤트 발행 (payment-reply-topic)
        K-->>DGW: QR 페이로드 응답
        DGW-->>C: 응답 (성공)

    else         ❌ QR 생성 실패
        TP-->>OW: QR 생성 실패 응답
        OW->>K: 실패 이벤트 발행 (payment-dlq-topic)

        K-->>DGW: 실패 결과 전달
        DGW-->>C: 응답 (실패)
    end

해결: Worker 분리 + 단계별 장애 대응 체계 구축

[Worker 분리]

• AS-IS: 국내GW → 해외GW 직접 동기 호출
• TO-BE: 국내 GW → Kafka 이벤트 발행 → Worker 구독하여 TP 호출
• 국내GW는 이벤트 발행 후 Reply Topic 대기, Worker는 독립적으로 처리 후 결과 발행

[1단계] @Retryable 기반 백오프 재시도 (1s→2s→4s, 최대 3회)

→ 재시도 성공 시 Client 정상 응답 반환