[과제] Spring 플러스 프로젝트 Day 2

오늘은 팀원들과 같이 설계를 진행하였으며, 아래와같이 설계 내용을 간단히 요약하였다.

 

 

1. 회원 관리 및 보안 아키텍처
가입 전처리 및 데이터 정합성

이메일과 닉네임에 UNIQUE 제약 조건을 설정하여 데이터 중복을 원천 차단함

birth_at 필드를 기반으로 가입 시점의 만 나이를 계산하며, 미성년자의 경우 비즈니스 정책에 따라 가입 프로세스를 즉시 중단함

추천인 메커니즘:

회원 테이블(members)이 고유 코드를 소유하고, 이를 입력받아 recommended_person 테이블에 이력을 남김

이는 단순 연결이 아닌 '누가 누구를 추천했는지'에 대한 시간 흐름상의 이력을 남겨 포인트 지급의 근거 자료로 활용함

로그인 보안 강화:

연속적인 로그인 실패 시 계정 혹은 IP 단위의 임시 차단(30초)을 적용하여 무차별 대입 공격(Brute Force)의 효율을 무력화함

보안과 편의성을 고려하여 세션 유지 시간은 30분으로 고정함

2. 리뷰 시스템 및 데이터 조회 최적화
읽기 성능을 위한 비정규화

리뷰 목록 조회 시마다 좋아요 수나 조회수를 집계(Count)하면 DB 부하가 급증함

이를 방지하기 위해 reviews 테이블에 great(좋아요), view_count(조회수), rating(평점) 필드를 직접 포함시켜 단일 테이블 스캔으로 조회를 끝냄 

리뷰 정렬 전략:

상단(Best): 특정 상품 내 좋아요가 많은 상위 3~5개를 우선 노출하여 마케팅 효과를 유도함

하단(General): 베스트 리뷰를 제외한 나머지 데이터를 최신순으로 페이징 처리하여 데이터의 신선도를 유지함

복합 인덱스 설계:

(product_id, great DESC, created_at DESC) 인덱스를 통해 베스트 리뷰 추출 시 정렬 부하를 제거함

3. 고성능 랭킹 및 동시성 제어
실시간 주간 랭킹

매번 DB의 전체 추천 이력을 GROUP BY 하면 연산 부하가 매우 큼

Redis의 Sorted Set 자료구조를 활용해 추천 발생 시마다 점수를 업데이트하고, 조회 시에는 정렬된 데이터를 즉시 반환하여 성능을 보장함

데이터 정합성 유지:

좋아요 클릭이나 조회수 증가 시, 다수의 사용자가 동시에 접근하면 데이터가 소실될 수 있음

이를 방지하기 위해 Atomic Update를 수행하거나, 별도의 좋아요 이력 테이블(review_likes)을 두어 중복 및 어뷰징을 방어함

[전체 시스템 비즈니스 플로우]
Step 1: 입력 정보 검증 (중복, 연령, 동의 여부)

Step 2: 추천인 코드 유효성 확인 및 포인트/이력 동시 처리

Step 3: 로그인 시도 시 보안 락(Lock) 로직 가동

Step 4: 리뷰 조회 시 베스트/일반 분리 쿼리 수행 및 어뷰징 필터링 적용

 

1.피그마 수정본

 

2.ERD

 

3.플로우차트

 

 

[월요일까지 해야할것]

1.주말간 채팅 강의 완강하기

2.스프링부트4.0 레디스 내용 숙지하기

3.맞춤형 수업 과제하기