Round 2 회고

회고 

 

요구사항 정리는 한적 있지만

상세하게 작성한적도 없고, 다이어그램은 그려본 적이 한번도 없어서 코드 구현보다 어려운 과제였습니다. 

 

 

---

1. 좋아요 기능의 멱등성 보장

멱등성이 뭐죠? 

멱등성이란 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질을 말합니다

 

그래서 좋아요 기능의 멱등성 보장은 어떻게 하죠? 

 

멱등성이 보장된다는건 뭐지?

 

- 같은 사용자가 같은 게시물에 좋아요를 100번 눌러도, 좋아요는 딱 1개만 저장되어야 한다는 거라고 합니다. 

 

 

결론: 몇 번을 눌러도 좋아요는 1개만 저장되는 게 멱등성 보장

잘못된 경우 (멱등성 X)

사용자 A가 게시물 1번에 좋아요 3번 클릭
→ DB에 좋아요 3개 저장됨
→ 좋아요 개수 3 증가
→ ❌ 문제!

 

올바른 경우 (멱등성 O)

사용자 A가 게시물 1번에 좋아요 3번 클릭
→ DB에 좋아요 1개만 저장됨
→ 좋아요 개수 1만 증가
→ ✅ 정상!

 

 

그러면 이걸 어떻게 보장하지?

 

가장 확실한 방법:

 

1. DB에 유니크 제약

UNIQUE KEY (user_id, post_id)

 

- 이렇게 하면 같은 사용자 + 같은 게시물 조합은 절대 중복 저장 안됨

 

네트워크 지연으로 똑같은 요청이 2번 와도, 첫 번째만 저장되고 두 번째는 무시됩니다. 

 

2. 애플리케이션 레벨에서 제어 

 

- 좋아요 데이터 존재여부 확인 후 분기 처리

---

2. 재고 및 포인트 동시성 제어 

여러 사용자가 동시에 주문할 때 발생할 수 있는 문제:

상황: 상품 재고 10개, 사용자 A와 B가 동시에 각각 8개씩 주문

[동시성 제어 없이]
T1: A가 재고 조회 (10개) ✓
T2: B가 재고 조회 (10개) ✓  ← 문제: 둘 다 10개로 보임
T3: A가 재고 차감 (10 - 8 = 2개)
T4: B가 재고 차감 (10 - 8 = 2개)  ← 재앙: 실제로는 -6개여야 함!
결과: 총 16개 판매, 재고는 2개로 표시 → 데이터 정합성 깨짐 ❌

 

🧠 처리 방안

- 비관적 락 적용

[비관적 락 적용 후]
T1: A가 재고 조회 + 락 획득 (10개) 🔒
T2: B가 재고 조회 시도 → ⏳ 대기 (A의 락이 풀릴 때까지)
T3: A가 재고 차감 (10 - 8 = 2개)
T4: A의 트랜잭션 커밋 + 락 해제 🔓
T5: B가 재고 조회 + 락 획득 (2개) 🔒
T6: B가 재고 부족 확인 (2 < 8)
T7: B에게 InsufficientStockException 발생
결과: A만 주문 성공, B는 재고 부족 에러 → 정합성 보장 ✅

 

왜 비관적 락인가?

 

선택 이유:
1. 주문/재고는 충돌 가능성이 높음 (인기 상품일수록)
2. 재시도 로직보다 락으로 확실히 제어하는 것이 안전

 

---

3. 외부 시스템 연동 실패 시 트랜잭션 롤백

- 주문 생성 후 외부 시스템(배송/결제 등) 연동 필요
- 외부 시스템 장애 시 이미 차감된 재고와 포인트 처리 방법?

 

🧠 처리 방안

외부 시스템 연동을 트랜잭션 범위에 포함하여 연동 실패 시 재고 및 포인트 차감 자동 복원

---

 

 

블로그 글 작성도 조금 더 발전할 수 있을거 같은데 다음에는 좀 더 시간을 들여서 작성할 수 있도록 해야겠습니다.