문제 상황 특정 일시에 오픈하는 예약 구매 특성상 동시에 주문처리가 많이 일어남 이 때에 실제 재고보다 더 많은 수량의 주문이 성공적으로 처리됨 문제 원인 주문 시 DB에 짧은 시간 동안 동시 접근이 일어나 여러 트랜잭션에서 동일한 데이터를 수정하려고 할 때 데이터 불일치 문제 발생 비즈니스 로직 public class StockServiceImpl implements StockService { // 기타 메소드 생략 @Override @Transactional public void decreaseStock(Long productId, int count) { log.info("재고 감소 요청 productId: {}, count: {}", productId, count); Stock stock = sto..

문제 상황 특정 일시에 오픈하는 예약 구매 특성상 동시에 주문처리가 많이 일어남 이 때에 실제 재고보다 더 많은 수량의 주문이 성공적으로 처리됨 문제 원인 주문 시 DB에 짧은 시간 동안 동시 접근이 일어나 여러 트랜잭션에서 동일한 데이터를 수정하려고 할 때 데이터 불일치 문제 발생 재고관리 프로세스 예약 구매를 하는 서비스를 만드는 것이 목표였기 때문에 메인 서비스가 잘 돌아가게 하는 것이 매우 중요하다고 생각했습니다. 이 과정을 크게 두 가지 스텝으로 나누어 생각해보면 아래와 같습니다. 특정 시간에 구매가 활성화 됨 구매가 열리면, 상품의 재고보다 많은 주문 발생할 수 있음 사례 분석 이 과정에서 비슷한 레퍼런스를 생각해보니 크게 두 가지로 나눌 수 있었습니다. 큐넷(시험 접수) 인터파크 티켓(콘서트..

문제 상황1 주문(Order)은 여러개의 주문 아이템(OrderItem)과 연결되어 있습니다. 각 주문 아이템은 상품정보를 가지고 있고, 주문과도 연관관계를 가지고 있습니다. 하나의 주문 내역을 가져오는 과정에서 2번의 쿼리문이 나왔습니다. 문제 원인 주문(Order)과 주문 아이템(OrderItem)은 ManyToOne 관계이므로 주문을 조회할때는 기본적으로 fetch.LAZY 전략을 사용합니다. 따라서 주문 아이템(OrderItem)은 프록시 객체로 저장되지만 전달하는 DTO에서 아래와 같은 코드를 사용함으로서 N+1 문제가 발생합니다. @Getter public class OrderDto { private Long orderId; private Long memberNumber; private Loc..

이전에 다른 과제에서 jwt 토큰으로 로그인을 구현해 본 적이 있습니다. -> 원티드 프리온보딩 지원 과제(github 링크) 이 때에는 단순히 토큰 기반 로그인이 많이 사용된다하여 구현했었는데요. 사용한 이후에 해당 기술에 대해 더 찾아보니 아래와 같은 이점이 있었습니다. 1. 토큰 방식은 서버가 클라이언트의 상태를 가지지 않는 stateless한 방식 2. stateless하기 때문에 언제든 token만 있으면 회원 검증가능 3. session을 사용하지 않는 앱 쪽에서도 로그인 기능 확장이 가능(전통적인 웹에선 session 기반으로 인증 값을 가지고 있어야 함) 이전에는 이러한 이해가 부족한 채로 구현했었기 때문에 로그인 시 간단히 access token만 발급하는 방식이었습니다. 그렇지만 네이버..