Skip to content

na0th/auction

 
 

Repository files navigation

경매 서비스 플랫폼

🧭 실시간 경매 프로젝트

6인 팀으로 진행한 웹 서비스 개발 프로젝트 [프로젝트 기간: 2024.08 ~ 2024.12] Back-End 4인 중 1인: 최건(na0th)


🛠 사용 기술 스택

공통

  • Java/Spring Boot, JPA/QueryDSL, MySQL

✨ 주요 기능 구현

기능 설명
💳 결제 결제 구현, 결제 정보 저장 실패 시 트랜잭션 롤백 및 결제 취소
🔍 경매 필터 검색 동적 쿼리를 통해 원하는 조건에 맞는 경매 검색 구현
🐢 N+1 문제 해결 Fetch Join 및 BatchSize 적용

✏️ 기능에 대해 테스트 코드 작성


🔍 문제 해결 사례

1️⃣ 결제 오류 시 복구 프로세스 경험

  • 문제 : 결제 성공 후, 결제 정보 저장을 실패하면 결제 정보가 유실되어 결제 프로세스 신뢰도가 떨어짐
  • 해결 : 결제 성공 후, 결제 정보 저장 실패 시 발생한 예외를 catch하여 결제 취소 API를 호출하고, 트랜잭션을 롤백
  • 결과 : 결제 취소를 통해 상태 불일치 없이 정상 복구

🔗 관련 PR 링크 (PaymentServiceImpl.java - 38번째 줄부터 ~ 73번째 줄)


2️⃣ N+1 문제 해결

  • 문제 : 경매 목록 조회 시 연관된 User, Product 에서 N+1개의 쿼리 발생
  • 원인 분석 : Lazy Loading으로 DTO 변환 시점에서 많은 쿼리 실행
  • 해결 : To-One 관계는 Fetch Join 사용, To-Many 관계는 Hibernate Batch Size 설정 사용
  • 결과 : 페이징 시 쿼리 기존 64개에서 3개로 감소

N+1 문제 해결 과정은 코드로는 1,2줄 밖에 안되고, 코드보다는 논리가 중요하다 생각해서 관련 글을 링크 걸었습니다.
🔗관련 기술 블로그 글 링크

🔗 프로젝트 관련 링크

  • API 문서 : [TODO: Swagger]
  • 팀 레포지터리 : 관련 링크

📝 회고

뛰어난 팀장, 팀원 분들 만나서 리뷰도 받고, 조언도 듣고, 많이 배우고, 성장한 것 같아서 정말 좋았습니다.

"특정 기술에 집착하지 말고, 시야를 넓게 보고 트레이드 오프를 고려하면서 기술을 선택하라"는 조언을 들었는데, 그전까지는 구현을 목표로만 삼아, 상황을 충분히 고려하지 않은 채 막연하게 선택한 기술을 그대로 적용했던 점을 반성하게 되었습니다.

4개월 동안 많게는 주 2회까지 회의를 하며 자신이 공부하고 적용한 기술을 발표했습니다. 설명하는 것이 익숙치 않아 처음엔 조금 떨렸지만, 돌아보면 스스로 설명할 때 명확하지 않은 부분을 짚어볼 수 있는 시간이 되었고, 덕분에 더 깊이 공부할 수 있었던 소중한 경험이었습니다.

설명하다 막힌 경험이 많아서 명확하게 설명할 수 없다면 100% 이해한 것이 아니라는 점도도 강하게 느꼈습니다.

About

팀 프로젝트 경매 플랫폼 백엔드 서버

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 99.2%
  • HTML 0.8%