3. 거래 상태 조회 API 개선

배경

Third Party(결제사) 응답 지연 시 POS가 거래 상태 확인을 위해 1초 단위 최대 2분간 Polling(최대 120회) 호출

동시 다수 거래 요청 시 DB 커넥션 풀 고갈 위험

문제

• 동일 거래 상태를 최대 120회 중복 DB 조회
• 매 호출마다 단일 트랜잭션 실행으로 커넥션 최대 300ms 점유
• Third Party 응답 완료 후에도 캐싱 없이 반복 DB 조회

AS-IS

TO-BE

---
config:
  theme: mc
  sequence:
    diagramMarginY: 30
    boxMargin: 10
    noteMargin: 20
    messageMargin: 80
---
sequenceDiagram
    participant POS
    participant Server
    participant MySQL

    Note over POS,MySQL: ❌ 매 Polling마다 RDB 직접 조회 발생 <br> 1번의 거래 요청당 최대 120번 RDB 조회
    POS->>Server: 거래 상태 조회 요청
    Server->>MySQL: RDB 조회
    MySQL-->>Server: 데이터 응답
    Server-->>POS: 거래 상태 응답
    Note over POS,MySQL: ❌ Cache 부재로 인한 DB 부하 누적

---
config:
  theme: mc
  sequence:
    diagramMarginY: 20
    boxMargin: 10
    noteMargin: 10
    messageMargin: 50
---
sequenceDiagram
    participant POS
    participant Server
    participant Redis
    participant MySQL

    POS->>Server: 0. 거래 요청
    Server->>Redis: Cache Put (Key:거래번호, Value:거래상태)

    alt Cache Hit ✅
        rect rgb(220, 255, 220)
            POS->>Server: 1. 거래 상태 Polling
            Server->>Redis: 2. 캐시 조회
            Redis-->>Server: 3. 캐시 응답 (Hit)
            Server-->>POS: 4. 거래 상태 응답
        end
    else Cache Miss ❌
        rect rgb(255, 220, 220)
            POS->>Server: 1. 거래 상태 Polling
            Server->>Redis: 2. 캐시 조회 (Miss)
            Server->>MySQL: 3. RDB 조회
            MySQL-->>Server: 4. 데이터 응답
            Server->>Redis: 5. Cache Update
            Server-->>POS: 6. 거래 상태 응답
        end
    end

해결 1: Redis Cache-Aside 패턴 도입

• 거래 요청 시 Redis에 상태 선 저장 (Cache Put)
• 첫 번째 Polling부터 Cache Hit 보장
• TTL 180초 설정으로 Polling 종료 후 자동 만료 처리
• Cache Hit → DB 접근 없이 즉시 클라이언트 응답
• Cache Miss 시 DB 조회 후 Redis 업데이트 (이후 동일 거래 조회 시 Cache Hit 보장)

해결 2: 트랜잭션 경계 최적화

• Cache Hit 구조 활용하여 트랜잭션 진입 없이 즉시 Early Return
• 불필요한 DB 커넥션 점유 완전 제거, Cache Miss 경우에만 트랜잭션 실행