기존 쿠폰 발급 프로세스는 한 트랜잭션 내에서 동기적으로 처리하고 있었다.쿠폰 발급 요청 -> 쿠폰 발급 처리 -> 발급된 쿠폰 정보 반환일반적인 쿠폰 발급에는 이 방식이 충분히 단순하고 안정적이다.요청 하나가 들어오면 그 안에서 모든 처리가 끝나기 때문에, 흐름도 명

앞선 글에서는 대량의 상품 데이터(테스트용 약 20만 건)를 조회할 때,응답 시간을 개선하기 위한 첫 번째 방법으로 DB 인덱스 최적화를 진행했다.상품 목록 조회 쿼리는 다음과 같은 조건을 가지고 있다.브랜드 필터 (brand_id)노출 여부 (visibility)삭제

이번주는 실제 트래픽에서 자주 발생하는 조회 병목 문제를 해결하는 방법을 알아보기 위해 로컬 디비에 상품 데이터를 대량으로 추가 후 인덱스, 비정규화, 캐시 등의 구조적인 접근으로 해결해보려 한다. 첫 번째는, '상품 목록 조회 성능 개선'이다.브랜드 필터링 + 좋아요

오늘은 주문에 쿠폰 개념을 도입하면서 TDD를 클로드와 함께 해보았습니다. 개발을 하면 할수록 여전히 모르는 것이 많다는 걸 '알게'되어서, 오늘의 포스팅은 겸손한 마음으로 존댓말을 사용합니다. (...?) 모든 테스트 코드를 직접 짜면 좋겠지만, 시간 관계상(귀찮기

시작은 사용자의 login_id에 unique 제약을 거는 것이었다. 회원가입시 별도의 validator 클래스에서 중복 아이디에 대한 검증을 하고있다. 하지만, 로그인 아이디에 unique 제약이 없는 상태에서는 동시 요청이 왔을 때 검증과 저장 사이의 Race C

회원가입, 내 정보 조회, 비밀번호 변경하기 기능을 개발하면서클로드에게 질문하고, 혼자 생각했던 내용을 정리한 기록예전에 언젠가 봤던 테스트 코드 강의에서 TDD는 red-green-refactor 패턴으로 하는게 정석(?)이라는 말을 들어본 기억이 났다. 그래, 그럼