유료 구독이 자동 만료됨

오류 시나리오

• 고객이 무료 상품 가입
• 무료 상품 취소
• 무료 상품 만료
• 유료 상품 구독
• 유료 상품이 자동 만료 (무료 상품의 만료 event가 한번 더 온 것으로 추정)

 

에러 케이스 분석

• 1단계: 에러 데이터 찾기(voc 인입)
• 2단계: 해당 고객분의 영수증 정보 찾기
  
  • 먼저 온 무료의 만료 이벤트
  • 나중에 온 유료의 만료 이벤트
• 3단계: 만료 요청이 온 영수증 구글 api로 호출
• 4단계: 호출 결과로만 비교/분석하기는 불가능

 

해결을 위한 가설 세우기

• 만료 event가 들어왔을 때 이전과 동일한 purchase-token과 만료 notification type(13)이 들어온 경우라면 무시한다
• 유료가 정상적으로 만료된 회원의 정보를 찾아 탐색해보자

 

정상 케이스 분석

시나리오

• 무료를 취소하지 않고 유료로 전환되어 사용하다가 취소한 케이스 (문제없음)
• 무료 구독 → 취소 요청 → 무료 만료 → 유료 구독 → 유료 취소 → 유료 만료 (무료 상품의 만료 event가 한번 더 들어와서 만료 발생)

 

만료 요청이 2건이지만 무료/유료에 따라 금액 지불일이 다르다.

 

SQL활용하여 분석

SELECT count(*), id_key
FROM 영수증
WHERE id_key in (SELECT id_key
                 FROM 영수증
                 WHERE 이벤트 = '만료'
                 GROUP BY id_key
                 HAVING count(*) = 2)
AND 이벤트 = '만료'
GROUP BY id_key
HAVING COUNT(*) = COUNT(DISTINCT 금액 지불일);

 

금액 지불일이 동일한 건으로 만료 evnet가 들어오면 이를 중복으로 판단하도록 변경

 

 

가설 검증하기

• 바로 production code에 배포하기는 위험하다.
• 예를 들어 예상하지 못한 영역으로 금액 지불일이 동일한 건으로 만료 event가 들어왔지만 만료가 발생해야 하는 경우가 있을 수도 있다
• try-catch를 통해 production code에 남기고, logging을 통해 alert 알람을 받습니다.
• 만약 alert 알림을 받은 회원이 유료를 구독하였으나 자동으로 만료가 되었다면 빠르게 데이터 보정을 실시합니다.
• 엣지 케이스가 보이지 않는다면 production code에 반영하여 중복 event를 validation 하도록 변경합니다.