타임딜 서비스 개발기

모름지기 잘 된 서비스들은 할인 이벤트를 만들어 사용자들의 접속을 유도한다. 여담으로 배민에서는 빼배로데이와 치킨데이가 있는데 이 때 참가하는 접속자가 많아서 치킨 디도스라고 불린다. 나의 서비스에도 이런 기능이 있으면 사용자들의 접속을 유도할 수 있겠다 싶어서 만들어야 겠다는 생각이 들었고, 아래의 글을 읽어봤는데 꽤나 재밌게 보였다.
https://techblog.woowahan.com/2514/

누군가에게는 빼빼로데이. 누군가에게는? | 우아한형제들 기술블로그

 먼저 비지니스 규칙은 다음과 같다.

1.  사용자는 이벤트 당 한번만 쿠폰을 발급 받을 수 있다.
2. 이벤트 상태가 오픈 중이 아니라면 이벤트에 참여할 수 없다.
3. 이벤트에서 발행된 쿠폰의 개수보다 발급된 쿠폰의 개수가 더 많을 수 없다.
4. 사용자는 발급받은 쿠폰을 확인할 수 있어야 한다.

도메인 지식

1. 관리자 계정만 이벤트 생성과 이벤트에서 발행할 쿠폰의 개수를 정할 수 있다.
2. 여러 관리자가 동시에 Event에 대한 설정 정보를 변경하지 않는다.
3. Event의 정보 수정으로 인해 User의 쿠폰 발급을 막으면 안된다.

엔터티 설계

최초 설계는 다음과 같이 생성했다. 하지만 문제가 생겼는데 그 이유는 쿠폰의 사용 요청이 들어왔을 때 쿠폰이 실제로 User에게 있는지, 쿠폰이 사용됐는지를 검색하기 위해선 User엔터티에 속해있는 Copon 엔터티를 모두 조회해야 한다는 단점이 생겼다.

 

따라서 아래와 같이 분리해서 진행했다,

 

서비스  순서도

• 사용자의 발급 요청 수신: 사용자가 쿠폰 발급을 요청합니다.
• 이벤트 확인: DB에 접근하여 사용자가 요청한 이벤트가 실제로 존재하는지 확인합니다.
• 이벤트가 존재하지 않는 경우: 사용자에게 Bad Request 응답을 보냅니다.
• 이벤트가 존재하는 경우: 사용자가 해당 이벤트에서 쿠폰을 발급받은 이력이 있는지 확인합니다.
• 쿠폰 발급 이력 확인: 사용자가 해당 이벤트에서 쿠폰을 발급받은 이력이 있는지 확인합니다.
• 이력이 있는 경우: 사용자에게 이미 쿠폰을 발급받았다는 응답

서비스  ERD

서비스 ERD (Entity-Relationship Diagram)에 대해 간단히 설명드리겠습니다. 현재 정의된 쿠폰 서비스는 다음과 같은 테이블들로 구성되어 있습니다:

테이블: Coupon

1. 할인 금액 (discount_amount): 쿠폰을 사용하여 적용될 할인 금액을 나타냅니다.
2. 발급 일자 (issued_at): 쿠폰이 발급된 날짜를 기록합니다.
3. 쿠폰 번호 (coupon_code): UUID V4 형식으로 생성된 고유한 쿠폰 번호를 저장합니다.
4. 사용 유무 (is_used): 쿠폰이 사용되었는지 여부를 나타내는 boolean 타입의 값입니다.

테이블: Time_Deal_Event

1. 발급된 쿠폰의 개수 (total_coupons_issued): 이벤트를 통해 발급된 전체 쿠폰의 수를 기록합니다.
2. 사용자에게 전달된 쿠폰 개수 (coupons_distributed_to_users): 각 사용자에게 몇 개의 쿠폰이 전달되었는지를 기록합니다.

관계

• Time_Deal_Event (1) -> Coupon (N): 하나의 Time_Deal_Event가 여러 개의 쿠폰을 발급할 수 있는 일대다 관계입니다.

이를 통해 쿠폰 서비스에서의 주요 기능과 데이터 구조를 이해할 수 있습니다. 쿠폰은 특정 이벤트를 통해 여러 개가 발급되며, 각 쿠폰은 고유한 코드와 함께 사용 여부 및 발급 날짜 등의 정보를 포함합니다. 이벤트 테이블은 이러한 쿠폰 발급 내역과 사용자에게 배포된 쿠폰 수를 추적합니다.

PK전략 정의

2024.07.25 - [개발] - 최적의 PK를 찾아서

최적의 PK를 찾아서

 

락 없이 요청을 보내면 어떻게 될까?

2024.07.23 - [TroubleShooting] - 발급 가능한 쿠폰의 개수보다 사용자에게 전달한 쿠폰의 개수가 더 많다....

발급 가능한 쿠폰의 개수보다 사용자에게 전달한 쿠폰의 개수가 더 많다....

DB의 락은 필요할까?

https://bjwan-career.tistory.com/293

Redis가 제안한 분산락(feat.Redlock)

비관적 락을 개선해 TPS를 높이자

2024.07.24 - [TroubleShooting] - In-memory- database를 사용해 TPS를 높이자

In-memory- database를 사용해 TPS를 높이자

1000TPS를 향하다

https://bjwan-career.tistory.com/308

TPS 2에서 TPS 10,000까지의 험난한 과정