hee-commerce

🙇‍♀️ 프로젝트 개요

• hee-commerce는 티몬 과 같은 이커머스 서비스에서 운영될 수 있는 타임딜 서버로, 10분동안 TPS 3000를 감당할 수 있도록 구현 중입니다.
• 서버 시나리오를 구글 Docs에 상황을 구체화한 후 프로젝트를 시작하였고, 특히 “주문 API”에 집중하여 프로젝트를 진행했습니다.

🚀 기술 스택

• JAVA 17, SpringBoot 3, MyBatis 3.5, MySQL 8, Redis 7.0, Flyway 9.5.1, RestDocs, Docker

✨ 문제 해결 및 개선 사례

1. Redis 저장 구조 변경(딜 상품과 재고 통합형 -> 분리형), DECR 명령어와 사후 검증 로직으로 재고 차감에 대한 동시성 문제 해결 (관련 상세 내용 링크)

2. 영속성이 불필요한 필드 제거로 재고에 따라 상품의 상태 변경에 대한 동시성 이슈 해결 및 TX 필요없는 로직으로 개선 (관련 상세 내용 링크)

3. 비정규화, 컬럼명 변경 및 Null 허용으로 로직 및 테이블 구조 단순화 (Tx 또는 Join 필요 O -> X) (관련 상세 내용 링크)

🍏 기타 포인트

(1) 테스트 코드 작성

• RestDocs를 이용하여 API 개발 시 TDD 원칙 적용 (초기 주문 완료 API, 주문 사전 저장 API, 주문 승인 API, 딜 상풍 목록 조회 API, 딜 상품 상세보기 API)
• 테스트 코드로 비즈니스 로직의 문서화를 위해 서비스 클래스가 아닌 도메인 모델에게 비즈니스 로직 책임 변경(#167)
• 가독성과 유지보수성을 고려해서 fixture 과 함수 활용해서 테스트 코드 리팩토링(#146)

(2) 유지보수성을 고려한 코드

• 유지보수성을 고려해서 재고 증가/감소 및 재고 히스토리 저장 로직을 응집력 있게 묶어서 관리(#158)
• 유지보수성을 고려해서 RedisUtils 클래스를 만들어서 Redis의 key를 한 곳에서 응집력있게 관리 (#153)
• 유연한 코드를 위해 의존성 주입을 활용하여 인증 로직 구현(#171)
• int 대신 Integer 사용하여 동적쿼리를 단순한 정적 쿼리로 변경(#133, #144)

(3) 고가용성을 고려한 시스템 설계 (진행 중)

• 시스템 설계 구조

(4) 비동기로 진행되는 리뷰 상황에 대해 효율적인 소통을 위해 Github의 다양한 기능(이슈, 주석, 코멘트, PR)을 활용하여 문서화

• PR에 이 작업이 무엇인지, 왜 그렇게 했는지 등 맥락을 전달하기 위해 노력했습니다. (예시 : #72)

🎈 DB 스키마

• DB 스키마

🎁 API 문서

• 주문 API 문서

🍿 주문 API WorkFlow