Project/타임딜 서버 3

인덱스를 통한 목록 조회 성능 개선

https://github.com/kkumta/Time-Deal-Shop/pull/38 Closes #37 refactor: product 테이블에 closeDate 인덱스 추가 by kkumta · Pull Request #38 · kkumta/Time-Deal-Shop 상품 구매 마감일을 기준으로 하는 상품 목록 조회 성능을 개선했습니다. 구체적으로, 상품 구매 마감일을 기준으로 하는 상품 목록 조회 API의 응답 속도를 1/2 가량으로 단축했습니다. github.com 해당 작업과 관련된 회고입니다. 타임딜 서버를 개발하면서, 많은 상품이 존재하는 경우 상품 목록 조회 속도가 생각보다 느리다는 것을 확인했습니다. 그러다 이런 경우에 어떻게 조회 성능을 개선할 수 있을지 고민해봤고, 인덱스를 떠올리게..

넘블 타임딜 서버 구축하기 챌린지 회고

3주 전 금요일, 넘블 타임딜 서버 구축하기 챌린지를 시작했다. 챌린지 마감인 오늘까지도 모든 요구가 구현된 상태가 아니라 조금 부끄럽다. 그래도 마감일이 다가왔으니 회고를 작성하고, 이후에 프로젝트를 더 보충해나가는 것으로 해본다. 나는 이 챌린지에 4가지 목표가 있다고 생각한다. 그 목표는 다음과 같다. Java+Spring을 통한 쇼핑몰 API 구현, 상품 수량 동시성 문제 해결, CI/CD 구축, 성능 테스트 및 모니터링을 통한 성능 개선 이 목표들을 달성하기 위해 마일스톤을 통해 3주의 시간을 관리했다. 1주차: 설계 및 환경 구축 API 설계, ERD 설계, 와이어프레임 설계, 프로젝트 생성, CI/CD 구축 등 프로젝트를 진행하기 위한 기반을 마련했다. 첫째로, 와이어프레임을 그리면서 동시에..

deleteUser(회원 탈퇴)를 어떻게 구현할 것인가

타임딜 서버는 3개의 엔터티로 이루어져 있다. User, Order, Product가 그 엔터티이다. 이 애플리케이션에서 deleteUser를 구현하려면 어떻게 해야 할까? 이는 과거 다른 애플리케이션을 구현할 때도 고민했던 문제이다. 회원 탈퇴 구현 방식은 크게 hard delete와 soft delete로 나뉜다. 그렇다면 타임딜 서버는 어떤 delete 방식을 택하는 게 좋을까? 한국의 개인정보 보호법 제21조(개인정보의 파기)에 따르면, 개인정보처리자는 보유기간의 경과, 개인정보의 처리 목적 달성 등 그 개인정보가 불필요하게 되었을 때에는 지체 없이 그 개인정보를 파기하여야 한다. 때문에 타임딜 서버에서는 deleteUser를 hard delete 방식으로 구현하기로 했다. 단, 회원 탈퇴 이후에..