jungheelee/kcd-proj-jhlee0828

kcm 과제 프로젝트

kcm-proj-jhlee0828

kcm 과제 프로젝트

kcd-proj-jhlee0828's Issues

feedback: change lifetime of OAuth token

문제

• 모든 요청이 새로운 토큰을 발급해서 사용하는 비효율 발생

해결방안

• 발급 받은 토큰 재사용

포트원 API

• POST /users/getToken API키 & API secret으로 access_token을 발급받습니다.

access_token의 만료기한은 발행 시간 부터 30분입니다. 만료된 토큰으로 API 요청을 하면 401 Unauthorized 응답을 받습니다.
재발행 (만료 후 발급): 새로운 access token을 발급한다. (만료기한: 발행시간 후 30분)
재사용 (만료 전 발급): 기존 access token을 발급한다. (만료기한: 기존과 동일, 단 기존 만료시간 전 1분이내 요청 시 5분 연장 됨)

feedback: 결제 상태 검증 미흡

문제

• 격리 레벨을 Repeatable Read로 사용 중이므로 트렌젝션이 종료되기 전까지는 상태가 반영되지 않으므로 분산환경에서 상태 검증 오류 가능성이 높음
• 예: 기존 로직 savePaymentStatusWithHistory 실행 후 다른 서버에서 동일한 트랜잭션키에 validateAndGetPayment 할 경우

기존로직

@Transactional
func serviceCode(req Requset){
     if validateAndGetPayment.isValid
     then executeAndFinalizePayment
}

private fun validateAndGetPayment(transactionKey: String): PaymentEntity {
      val payment = paymentRepository.findByTransactionKey(transactionKey)

      if (payment.paymentStatus != PaymentStatus.READY) { // here
          throw PaymentFailedException("Payment is already processed")
      }
}

private fun executeAndFinalizePayment(): {
      savePaymentStatusWithHistory(payment, PaymentStatus.IN_PROGRESS)

      savePaymentStatusWithHistory(payment, finalStatus)
}

해결 방안

선택지	장점	단점
Optimistic Locking	간단하게 구현 가능, 데드락 위험 낮음	충돌 시 재시도 필요, 일부만 성공할 수 있음
Pessimistic Locking	동시성 문제를 명확하게 해결	데드락 위험 있음, 자원을 많이 사용
Distributed Lock	분산 환경에서도 잘 작동	외부 시스템 필요, 복잡성 증가, ex) Redis Zookeeper
Eventual Consistency	확장성 좋음, 복잡한 비즈니스 로직에 적합	일관성을 바로 보장하지 않음, 복잡성 증가