송금 요청 만료 기능

[donggi-lee-bit]

송금 요청이 생성된 후 일정 시간(3일) 이내에 수락 또는 거절되지 않으면, 해당 요청을 EXPIRED 상태로 전환하는 만료 처리 기능을 도입하고자 합니다.

요청 만료 처리 기능은 단계적으로 도입하고자 하며, 현재 고려 중인 방식은 다음과 같습니다.

• 요청 시점 검증
  사용자가 송금 요청을 수락하거나 거절하는 시점에, 만료 여부를 확인하고 조건을 만족할 경우 상태를 EXPIRED로 전환합니다.

• 스케줄러 기반 배치 처리
  일정 주기로 만료 조건에 해당하는 요청들을 조회하고, 일괄적으로 EXPIRED 상태로 변경합니다.
  요청 시점 검증만으로는 누락될 수 있는 요청을 보완합니다.

• Queue 기반 자동 만료 처리
  요청 생성 시 만료 예정 시점을 큐에 등록하고, 지정된 시간이 도래하면 만료 이벤트를 트리거하여 상태를 전환합니다.

먼저 구현 난이도가 가장 낮은 요청 시점 검증 방식으로 구현하고, 추후 점진적으로 기능을 확장하고자 합니다.

주요 기능

• 송금 요청 생성 이후 일정 시간(3일) 경과 시 만료 처리
• 수신자가 수락/거절 시점에 만료 여부 검증
• 만료 시 RemittanceRequestStatus.EXPIRED로 상태 변경
• 상태 이력(remittance_request_status_history)에 만료 기록 추가
• 만료된 요청에 대한 수락/거절 시도는 예외(ExpiredRequestException)로 처리

적용 대상

• 송금 요청 수락 API
• 송금 요청 거절 API

[f-lab-maverick]

만료 상태 갱신의 책임
3일이 지나면 만료된다는 기준이 있고, 만료가 되면 상태가 EXPIRED로 변경되어 송금을 받을 수 없는 상태가 된다고 이해했습니다.
또한, 만료가 되면 송금 홀딩 금액이 삭제되어야 하며, 송금 가능 금액 또한 변경되어야 합니다.

현재 설정하신 요청 시점 검증의 경우 아래 케이스를 고려하셔야 합니다.

1. 3일이 지났으나 아무 요청이 없는 상태. 상태는 아직 유효한 상태코드.
2. 3일이 지났고, 실제로 만료된 상태. 만료 상태코드.

1번의 경우, 논리적으로는 만료된 상태이나 아직 상태 코드가 업데이트되지 않았기 때문에 데이터 상태의 불일치가 발생합니다.
이로 인해 송금 가능 금액 또는 잔액 조회 등의 로직에서 상태 코드를 기준으로 금액을 계산하게 되면,
실제 사용자가 인지하는 송금 가능액과 시스템 내부 금액 간에 차이가 발생할 수 있습니다.
또한 송금 관련 요청이 없다면 며칠이 지나도 계속해서 유효한 상태로 남아있을 것으로 보입니다.

• 정기 배치 또는 이벤트 기반 처리를 통해 만료 시점을 지났을 때 상태를 자동으로 EXPIRED로 업데이트하는 방식을 고려해보시는 건 어떨까요?
• 또는 잔액 조회 시에도 만료 여부를 실시간으로 판단하여 반영하는 로직을 함께 넣어야 상태 불일치 문제를 줄일 수 있을 것 같습니다.

경계 조건 시나리오
만료 직전 (2일 23시간 59분)에 송금 요청이 들어올 경우
만료 직후 (3일 0분 1초) 에 들어오는 경우
상태가 EXPIRED로 갱신되지 않았지만 3일이 지난 경우의 잔액 조회
상태가 EXPIRED이나 여전히 홀딩 금액이 남아 있는 경우

위 경우 문제가 발생하지 않을까요?
특히, 만료 직전에 요청이 들어온 경우 요청은 2일 23시간 59분에 접수되었으나, DB쿼리시 3일이 지나 만료되었다고 판단할 수 있습니다. 이 경우 유효하다고 판단하실 건가요?

[donggi-lee-bit]

요청 시점 검증 방식의 한계

요청 시점 검증 방식은 송금 요청이 논리적으로는 만료되었더라도, 상태가 실제로 EXPIRED로 갱신되지 않아 실제 송금 가능 금액과 시스템 상 잔액이 달라지는 등 데이터 불일치 문제가 발생할 수 있습니다.

이에 따라 송금 요청 만료 처리 기능을 다음과 같이 수정하고자 합니다.

• 요청 시점 검증 로직은 그대로 유지하여 수락/거절 요청의 유효성은 실시간으로 보장
• 만료 상태 갱신은 배치 또는 이벤트 기반 처리로 별도 수행
  • 일정 주기마다 3일 이상 경과된 PENDING 요청을 찾아 EXPIRED로 전환
  • 상태 전환 시 홀딩 금액 해제 처리도 함께 수행

또한 사용자의 잔액 조회 시점에 송금 요청 상태를 수정하는 방식은 restful한 설계 관점에서는 어색할 수 있어, 상태 갱신은 배치나 이벤트와 같은 별도의 트리거를 통해 명시적으로 처리하겠습니다.

경계 조건 시나리오

지금과 같은 구조로 수정하게 되면 대부분의 경계 조건 시나리오는 자연스럽게 해결될 것으로 보입니다.

한 가지 예외로 다음 케이스는 명확한 기준을 정해 처리할 예정입니다.

만료 직전에 요청이 들어온 경우 요청은 2일 23시간 59분에 접수되었으나, DB쿼리시 3일이 지나 만료되었다고 판단할 수 있습니다.

이 경우 요청이 애플리케이션에 도달한 시점을 기준으로 유효성 여부를 판단하여 만료되지 않은 요청으로 간주하고 처리하고자 합니다.