[백엔드]기프티콘 도메인에 대한 이해 & 정리 & 회고

기프티콘 도메인을 개발하게 되면서 알게 된 내용과 회고에 대해 작성해보려 한다.

현재 서비스에 기프티콘을 처음 도입하게 되면서 스키마 정의부터 다양한 예외 케이스 등을 알기 위해 검색을 해보았다.

하지만 인터넷에는 딱히 볼 만한 내용이 검색되지 않아서

추후 또 비슷한 도메인 업무를 할 경우 참고용이자,

기프티콘 도메인을 개발하게 될 어떤 개발자분에게 도움이 되고자 작성해 보았다.

 

참고로 너무 디테일하게 작성하게 될 경우 문제가 생길 수 있으므로 누락된 내용이 있습니다. 맥락을 봐주세요.

 

🌠 목차
✅ 도메인 테이블 설계
✅ 각 테이블의 의미
✅ API 목록 별 로직 플로우
✅ [회고] 기프티콘 도메인을 개발하며 

 

 

도메인 설계

---

* 다음 테이블 목록은 참고용이므로 내부 요구사항에 맞게 수정해야 합니다.

* 연관관계는 크게 신경 쓰지 마시기 바랍니다 

* user테이블의 정보는 작성하기 귀찮아서 생략했습니다 

* CamelCase로 작성된 이유 또한 귀찮아서 이미 작성되어 있는 코드 패널을 복붙 했습니다.

 

 

 

Table 목록 

User

ShopCoupons

ShopPurchasedLog

ShopCategoryOnShopProduct

ShopProduct

ShopCategory

 

각 테이블의 의미

---

TotalPointLog

포인트 사용 관련 로그 저장 테이블

기프티콘 도메인뿐만 아니라 자사 서비스 내 포인트를 이용하는 경우를 저장하는 로그 테이블 

 

ShopCategory

상품 카테고리를 나타내는 테이블 

관리 포인트를 DB로 둔다.

- 앱 서비스의 경우 빌드&배포의 시간이 오래 걸리기 때문

 

ShopProduct

구매 가능 & 등록된 상품에 대해 나타내는 테이블 

 

ShopCategoryOnShopProduct

ShopProduct와 ShopCategory의 연관관계를 나타내는 다대다 테이블 

 

ShopCoupons

사용가능한 기프티콘 쿠폰 테이블

 

ShopPurchasedLog

기프티콘 구매 내역 로그 테이블

 

API 목록 별 로직 플로우

---

API 목록

카테고리 조회

상품 조회

쿠폰 구매

쿠폰 조회

쿠폰 상세조회 

 

각 API의 역할은 아래를 참고하자

 

카테고리 조회(api/categories)

- DB에 저장된 카테고리 조회 

- isVisble: true만 조회

 

상품 조회(api/products)

- 페이지네이션 방식 offset 

   기존에 cursor방식을 이용하였으나, offset 방식으로 변경

   이유: 상품정렬방식 - 가격순, 이름순, 인기순 등을 반영할 경우를 고려하여 offset 이용 

- isVisble: true만 조회

- 카테고리를 query로 전달받거나, 없을 경우 전체 조회

 

쿠폰 구매(api/coupon/issue)

- 상품 Id와 구매수량을 전달받는다.

   - 상품 Id로 등록된 상품 조회 

   - 상품 code 등으로 조회하면 안 되는 이유는, 외부 업체마다 제공하는 상품 code가 있을 수도 있고, 없을 수도 있다. 

   - 상품 존재 체크

- 유저 포인트 체크

- 임시쿠폰 데이터 생성(state = PRE_ISSUE)

   - 실패 케이스에 대해 트랜잭션 처리를 해두지 않는 업체 존재.

   - 자사에서 구매 실패 케이스에 대해 처리해야 하므로 임시쿠폰 데이터를 생성하고, 배치를 만들어 실패 케이스에 대해 처리해야 한다.

- 트랜잭션 처리

  - 쿠폰 발급요청

  - 쿠폰 유효성 체크  

  - 쿠폰 번호 암호화 및 중복 체크

  - 유저 포인트 차감 

  - TotalPointLog 생성 

  - ShopPurchasedLog 생성

  - 발급받은 데이터로 임시쿠폰 데이터 업데이트(state = AVAILABLE)

- 암호화된 쿠폰번호, 구매수량, 사용 포인트, 현재 포인트, 상품정보를 넘겨주자.

 

나의 쿠폰 리스트 조회(api/coupons)

- 페이지네이션 cursor 적용

- state = PRE_ISSUE 제외하고 조회 

 

쿠폰 상세 조회(api/coupons/couponId)

- userId와 쿠폰 Id로 생성된 쿠폰 조회

- 유효성 체크

   1. 상품 테이블에 생성된 상품코드와 내 쿠폰 상품 코드 비교    

- 파트너사 API를 이용하여 쿠폰 정보 상세 조회 요청

- 파트너사 API 결과로 쿠폰 상태 업데이트(사용유무, 취소 등)

   다양한 쿠폰 상태가 존재하므로 내부적으로 정한 상태 case로 업데이트 처리 (4~6개가 적당한 듯)

- 유효 날짜 체크 

- 결과 리턴 

  암호화되어 저장된 쿠폰 번호 복호화

 

[회고] 기프티콘 도메인을 개발하며 

---

1. 외부 파트너사는 말 그대로 외부 파트너사이다. 

파트너사의 직원들도 다른 일이 있고 그들의 내부사정을 알 수 없기 때문에

그들은 나의 요구사항에 빠르게 대응해주지 못하는 경우가 발생한다.

그렇기 때문에 초기에 API 문서를 꼼꼼히 읽어 봐야 하며,

1) 설계부터 끝단까지 필요한 부분들을 모두 정리해서 초기에 메일로 요청하도록 하자.

   ex) main, qa, local IP등록, 임시 테스트용 코드, 상품 등록 리스트 등

2) 애매하거나, 잘 모르겠는 부분은 부끄러워하지 말고 물어보도록 하자.

3) 실패 케이스에 대해 트랜잭션 처리를 해두지 않는 업체가 존재하므로 위에 작성한 임시쿠폰 데이터를 생성하도록 하자.
    자사에서 구매 실패 케이스에 대해 처리해야 하므로 임시쿠폰을 발급하고 배치를 만들어 실패 케이스에 대해 처리해야 한다.

 

2. get/post 메서드에 대해 

외부 파트너사 API를 이용하며 당황했던 경험은

요청이 '상품 조회'여도 post 메서드로 보낸다. (post로 보안을 신경 쓴 건 알겠지만,,, 그러면 API 명세서에 작성이라도 해주던가)

난 조회면 당. 연. 히 get 메서드일 줄 알았으나, 계속 실패 값이 왔다.

API 문서 구석에 body 형식의 request 임시 데이터가 있었는데 

내 주관적인 생각과 경험을 버리고, 문서에 기반하여 코드를 작성하도록 하자.

기프티콘 업체뿐만 아니라 많은 외부 업체와 협력을 하면서 API규약을 지키지 않는 곳이 많았다.

(명세서에 없는 response값이 온다던가, 다른 reponse 값이 온다던가,,,)

일을 하면서 계속 혼동이 오는데, '문서' 최대한 집중해서 읽어보고, 힌트를 많이 얻어 유추하는 능력도 필요하다.

 

3. IP 화이트리스트 등록

파트너사에 화이트리스트 등록을 해야 했다. 

우리 서버는 ECS를 이용하여 글로벌액설 레이터로 고정 IP값을 뽑아주어 요청했다. 

배포 전날 QA서버에서 테스트를 하는데, API가 자꾸 실패했다. 로컬 IP - 테스트에서는 성공했는데 말이다.

AWS ECS에서 호스팅 중인  QA서버의 경우 인바운드로 오는 API 요청에 대해 IP를 제공해 주지만, 

ECS 자체에서 IP요청을 할 경우 글로벌엑설레이터를 거치지 않아 다른 IP가 나갔다. 

'글로벌엑설레이터는 고정 IP를 등록할 수 없다'라는 인사이트를 얻게 되었다. 

 

4. 서버를 터트리며

위의 문제를 해결하기 위해 급하게 방법을 고민했다. 

배포일정은 다가오고 IP는 등록되지 않는 상황에서 학습이 되지 않는 상태에서 인프라를 건드렸다. 

내가 찾아본 고정 IP를 할당해 주는 방법 2가지가 있었는데,

nat gateway를 이용하여 아웃바운드 IP를 고정으로 할당해 주거나,

EC2서버를 proxy 서버처럼 띄우는 방법이 있었다.

나는 서버비와 고정 IP 할당하는데 드는 비용을 줄이기 위해 nat gateway를 이용했으나,

2시간 동아 전체 서버가 다운되는 일을 경험했다. 

다시 롤백하고, 사수님이 EC2로 띄어서 해결하긴 했지만, 끔찍한 경험이었다.

'두 번 다시 인프라는 얕은 학습 경험으로 시도하지 않는다'는 개발 규칙을 세우게 되었다. 

이 경험으로 다음 달부터 AWS 자격증을 준비하려고 한다. 

 

5. 중간에 기프티콘을 적용하려는 업체라면 다음을 체크하세요.

기프티콘 서비스를 적용하려는 회사의 내부 사정을 생각해 보자.

카카오톡, 메시지등으로 상품 구매 정보를 제공하는 데 있어 CS의 공수가 계속 커감에 따라 

자사 서비스 내에서 확인할 수 있는 쿠폰함을 내부적으로 구현하길 원할 것이다.

자사 서비스 내 쿠폰함과 쿠폰 구매 서비스를 개발했을 때 발생할 수 있는 문제는 뭐가 있을까? 

한 번 생각해 보자.

 

그 문제는 바로,

서비스가 업데이트되기 이전 쿠폰을 구매한 유저의 경우 쿠폰함에 쿠폰이 등록되지 않는다는 것이다.

데이터 클렌징을 통해 기존의 구매한 내역에 대해 데이터를 추가해줘야 한다.

CS를 방지하기 위해 위 내용도 기억하도록 하자.

 

 

👋

쿠폰/기프티콘 도메인을 개발했던 한 달간의 일지를 작성해 보았다. 

1주일 태스크로 잡았는데 한 달이 걸리기도 했고, 커뮤니케이션에서 많은 스트레스를 받았지만, 

실제 서비스가 론칭되고 긍정적인 고객의 피드백을 받게 되어 그동안의 피로가 풀리는 것 같다.

이번 파트너사와의 협력과 기프티콘 도메인의 메인 개발자로 개발하게 되면서

얻게 된 인사이트는 앞으로 개발하는 데 있어 큰 경험이 될 것이라 생각한다. 

 

 

 

 

 

글 재미나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다