[BE_6] Cart/CartItem (domain) / Cache 적용 기준

[pjhcsols]

어떤 기능인가요?

일반 유저의 장바구니(Cart/CartItem) 조회·수정 기능에서 발생하는 DB 조회 부하/동시성 경합/금액 정합성 문제를 줄이기 위해,

• 쓰기 경로는 정합성 우선(비관락 + 짧은 재시도 + 즉시 flush) 로 안전하게 고정하고
• 읽기 경로는 카탈로그(상품 기본정보/브랜드할인%)를 Caffeine TTL 캐시로 흡수하여
• 쿼리 수를 상한화하고 p95/p99 지연을 안정화하는 기준과 구현 원칙을 정의합니다.

---

도메인 구조

Cart (Aggregate Root)

• 의미: “유저 1명당 1개의 장바구니”

• 주요 필드(코드 기준 개념)

  • id
  • normalUserId (userId)
  • items: List<CartItem>
  • totalLines (아이템 라인 수)

• 핵심 불변조건

  • 유저당 Cart는 유일(동시 생성 레이스 발생 가능 → 안전 생성 로직 필요)
  • Cart 변경은 항상 락을 잡고(쓰기 경로), 커밋 직전 오류를 flush로 조기 감지

CartItem (Value-like Entity under Cart)

• 의미: “상품 옵션(productId + size + color) 단위 라인”

• 주요 필드(코드 기준)

  • id
  • productId
  • size (String, enum Size로 파싱)
  • color (String, enum Color로 파싱)
  • quantity
  • (서버 확정값) brandUserNumber, brandFirmName
    → 쓰기 시점에 서버가 확정 저장(프론트 신뢰 X)

정합성/정책

• 재고 검증은 쓰기 경로에서만 “실시간 옵션 재고(ProductOption.optionQuantity)”로 검증
• 조회 화면에 필요한 제품 정보(이름/가격/브랜드/할인%)는 카탈로그 스냅샷으로 취급 가능(최대 60초 지연 허용)

---

핵심 플로우(현재 코드 기준)

1) 락 + 안전 생성 + 짧은 재시도(쓰기 경합 흡수)

• withCartLock(userId, body)

  • getOrCreateLocked(userId)로 FOR UPDATE 선점

  • 처리 후 em.flush()로 유니크/락/무결성 예외 조기 감지

  • PessimisticLockException / LockTimeoutException / CannotAcquireLockException / DataIntegrityViolationException

    • 최대 3회(0,1,2) 재시도
    • 실패 시 ErrorCode.CONFLICT로 사용자 친화적 메시지 통일

• getOrCreateLocked(userId) 3단계

  1. findWithItemsByUserIdForUpdate(userId) (있으면 즉시 반환)

  2. 없으면 cartRepo.save(Cart.createFor(userId)) 시도

     • 동시 생성 유니크 충돌은 흡수(DataIntegrityViolationException 무시)

  3. 다시 findWithItemsByUserIdForUpdate로 최종 락 확보 후 반환

목적: “동시 생성 레이스/락 경합/유니크 충돌”을 사용자에게 500이 아닌 409(CONFLICT) 로 안정적으로 노출하고, 장애 비용(롤백/재시도)을 줄임.

---

DB 조회 최적화 기준(읽기 경로)

목표

• 장바구니 조회(/me)는 화면 구성에 필요한 데이터를 모아야 하지만,

  • JPA 다중 bag fetch join, N+1, 옵션/사진/할인 조회 폭증을 피해야 함

• 따라서 조회는 다음 방식으로 고정:

  • Cart + Items는 1회 조회(필요 시 for-update)
  • 카탈로그(기본정보/할인%)는 캐시 + 미스만 배치(IN)
  • 색상 사진/옵션 재고는 키 기반 IN 일괄 로딩

실제 코드에서의 일괄 로딩 구성

• 제품 기본정보: catalog.getBasicsByIdsCached(productIds)

• 브랜드 할인 퍼센트: catalog.getActivePercentsByProductIdsCached(productIds, now)

• 색상별 대표 이미지:

  • productRepo.findColorOptionsWithPhotos(productIds, colors)
  • key: productId|color

• 옵션 재고(옵션별 수량):

  • productOptionRepo.findById_ProductIdInAndId_ProductColorInAndId_ProductSizeIn(productIds, colors, sizes)
  • key: productId|color|size

기준: “연관관계 fetch join으로 한 번에 땡기려다 터지는 것” 대신
‘필요 데이터’만 쿼리 3~4방으로 고정해 성능을 예측 가능하게 만든다.

---

캐시 적용 기준(무엇을 캐시하고, 무엇을 캐시하지 않는가)

캐시 대상(YES)

아래 조건을 만족하면 캐시 적용 대상:

• 읽기 비중이 높고(조회 트래픽) DB 부하를 직접 유발
• 조회 결과가 읽기 전용 스냅샷(Projection/DTO) 로 분리 가능
• 최대 60초 내 지연 허용(즉시 반영이 필수 아님)
• 동일 productId가 반복 조회되는 “핫키” 성격

✅ 현재 적용된 캐시 값(실제 코드)

• product.basic

  • 값: BasicProjection을 BasicView(불변 래퍼)로 감싼 스냅샷
    (productId, productName, productPrice, totalQuantity, brandUserNumber, brandFirmName)
  • 키: productId (per-id)

• discount.activePercent

  • 값: 상품별 현재 브랜드 할인 퍼센트(Integer, 없으면 0)

  • 키: productId|minuteKey (per-minute)

    • minuteKey = now.truncatedTo(MINUTES)
    • TTL 60s와 자연 정합(1분 단위 갱신)

캐시 비대상(NO)

아래는 캐시하면 오히려 사고/불일치가 커짐:

• 재고/옵션 수량(실시간 정합성이 중요, 결제·예약과 엮임)
• 유저별 상태(장바구니 자체, 좋아요/쿠폰 보유 등 개인화 데이터)
• 결제 최종 금액/승인 금액(서버에서 매번 재계산 + 검증이 원칙)
• 락이 필요한 데이터(동시성 제어가 핵심인 데이터)

---

CacheManager 설정값 기준(성능 위주 비교/선정 이유)

Spring Cache + Caffeine을 택한 이유(성능/운영)

• JPA 2nd-level cache는

  • 프록시/세션/연관관계/더티체킹/무효화 전략과 얽혀,
  • “캐시 히트”여도 추가 로딩/예상 밖 동작/운영 리스크가 커질 수 있음

• 반면 여기서 캐시하려는 것은

  • 엔티티가 아니라 읽기 전용 Projection/DTO 스냅샷
  • JVM 로컬 메모리에서 O(1) 로 반환 가능
  • TTL을 짧게 두면(60s) 신선도 리스크도 상한이 명확

즉, 엔티티 캐시가 아니라 “카탈로그 읽기 스냅샷 캐시”로 격리하는 것이 더 안전하고 성능효과가 즉각적.

expireAfterWrite=60s 선택 이유(성능/신선도 균형)

• 트래픽 스파이크 시 DB 재유입(미스) 빈도를 줄여 쿼리 폭증을 억제
• 동시에 변경 반영 지연을 최대 60초로 상한 → 운영상 예측 가능
• 특히 할인 캐시는 minuteKey를 사용해 “1분 단위 자연 갱신”이라 TTL 60s와 정합이 좋음

maximumSize=20_000 선택 이유(안정성/p99)

• 핫 상품 + discount.activePercent의 per-minute 키까지 고려하면 키 수가 급증할 수 있음
• 무제한 캐시는 힙/GC 압박으로 p99 지연 스파이크를 만들 수 있으므로 상한을 둠
• 20,000은 “핫키를 담아 hit율을 유지하면서”도 “메모리 폭주를 차단”하는 안전장치

---

캐시 조회 방식 기준(쿼리 수 상한화)

per-id 캐시 + miss만 batch(IN)

• 입력 productIds는 LinkedHashSet으로 중복 제거
• Cache hit: O(1) get
• Cache miss: miss 목록만 IN 배치 조회
• 조회 결과는 불변 래퍼(BasicView) 로 감싸 캐시에 저장
• discount는 negative caching(없음=0) 까지 저장 → 반복 미스 쿼리 제거

효과: “페이지당 아이템 수”가 늘어도 DB 쿼리는 상한이 고정되고, 핫 상품에서 쿼리 스파이크가 사라짐.

---

(중요) 캐시 무효화(evict) & afterCommit 기준

왜 필요한가?

TTL 60s만으로도 “언젠가 갱신”은 되지만, 아래 케이스에서 UX/정합 리스크가 남음:

• 상품 가격/상태(ON_SALE 등)가 즉시 바뀐 경우
• 브랜드 할인율이 즉시 바뀐 경우
• 운영자가 수정 직후 바로 화면 확인/CS 대응해야 하는 경우

→ 변경 직후 해당 productId만 선택 무효화(evict) 하면, 다음 조회에서 바로 최신 값을 당겨올 수 있음(“TTL 기다림 제거”).

afterCommit이 왜 필요하나?

“트랜잭션이 롤백됐는데 캐시만 먼저 지워지는” 역전이 생길 수 있음.

예시:

1. 상품 수정 서비스에서 캐시를 먼저 evict 해버림
2. DB 트랜잭션이 롤백(실패)됨 → DB 값은 원래대로
3. 그런데 캐시는 이미 삭제됨 → 다음 조회는 DB를 다시 때리거나, 순간적으로 “불필요 미스/부하/지연”이 발생

즉, DB 변경이 확정(커밋)된 뒤에만 evict 해야 캐시/DB 상태가 같은 방향으로 움직인다.

결론: evict 자체는 “선택사항”이지만, 넣는다면 반드시 afterCommit 로 안전하게 넣는 것이 정석.

---

작업 상세 내용

• Cart/CartItem 도메인 불변조건 문서화(유저당 1 Cart, 옵션 단위 라인, 쓰기 시 서버 확정 필드)
• 동시성 제어 기준 확정(withCartLock, getOrCreateLocked 3단계, flush, retry/backoff, CONFLICT 통일)
• 조회 최적화 기준 확정(카탈로그 캐시 + 사진/옵션재고 IN 로딩, 다중 bag fetch join 회피)
• 캐시 적용 기준 정리(캐시 대상/비대상, TTL=60s, maximumSize=20_000, negative caching, per-minute 키)
• (후속) 상품/할인 변경 시점 선택 evict + afterCommit 연동 설계/구현
• 성능 검증(쿼리 수/응답시간/p95/p99, 캐시 hit ratio) 및 회귀 테스트 추가

---

참고할만한 자료(선택)

• Caffeine Cache (eviction/TTL/maximumSize 개념)
• Spring Cache 추상화(CacheManager, Cache)
• 트랜잭션 동기화(afterCommit) 패턴(TransactionSynchronization)

Cart/CartItem 테이블 인덱스 추천(유니크/조회용)과 “캐시 eviction 설계(코드 스니펫 포함)” 추후 검토 및 추가 개선

[pjhcsols]

-- src/main/resources/db/migration/VXXXX__cart_schema.sql
create table if not exists carts (
cart_id bigint auto_increment primary key,
user_number bigint not null,
created_at datetime(6) not null,
updated_at datetime(6) not null,
constraint uk_carts_user unique (user_number)
);
create index if not exists idx_carts_user on carts(user_number);
create index if not exists idx_carts_updated on carts(updated_at);

create table if not exists cart_items (
cart_item_id bigint auto_increment primary key,
cart_id bigint not null,
product_id bigint not null,
brand_user_number bigint not null,
size varchar(24) not null,
color varchar(24) not null,
quantity bigint not null,
unit_price_after_brand bigint null,
created_at datetime(6) not null,
updated_at datetime(6) not null,
constraint fk_cart_items_cart foreign key (cart_id) references carts(cart_id) on delete cascade,
constraint uk_cart_item_cart_product_option unique (cart_id, product_id, size, color)
);
create index if not exists idx_cart_items_cart on cart_items(cart_id);
create index if not exists idx_cart_items_product on cart_items(product_id);
create index if not exists idx_cart_items_brand on cart_items(brand_user_number);
create index if not exists idx_cart_items_updated on cart_items(updated_at);

[pjhcsols]

TODO: 상품/할인 변경 시점의 선택 무효화(evict) 및 afterCommit 연동은 후속 커밋에서 추가

현재 TTL 60s니까 최대 60초 정도의 낡은 값을 허용할 수 있다는 가정.
근데 **“왜 굳이 evict/afterCommit을 변경?”**는 결국 정합성 요구 수준 + 운영 리스크(캐시 스파이크) 때문.

evict를 해야 하는 이유 (TTL만으로 부족한 케이스)

1) 변경 직후 60초 동안 “틀린 가격/할인”이 노출될 수 있음

• 상품 가격/상태(ON_SALE↔STOP)/브랜드 정보/대표명 같은 product.basic
• “현재 적용 할인율” 같은 discount.activePercent
  이게 바뀌었는데 캐시는 TTL 만료 전까지 그대로면,
• 장바구니/좋아요/상품 목록에서 가격·할인 표시가 60초 동안 구버전일 수 있어.
• 특히 “할인 시작/종료”, “가격 수정”은 체감이 크고 CS 발생 포인트.

=> TTL 허용이 정책이면 OK, 아니면 evict 필요.

2) 스케줄 경계(분 단위)에서 “할인율”이 바뀌는 순간이 존재

할인 캐시 키가 productId|minuteKey(truncatedTo MINUTES)

• 할인 시작/종료가 딱 그 시각에 걸리면,
• 해당 minuteKey 기준으로 새 값으로 즉시 바뀌어야 하는데
• TTL만 쓰면 “이전 minuteKey 값이 남아” 한동안 섞여 보일 수 있다.

(물론 TTL 60s면 짧지만, “정각에 이벤트”가 많은 시스템이면 눈에 띔)

3) 캐시 갱신 타이밍이 몰릴 때 DB 스파이크를 막으려면 “변경 기반 무효화”가 더 안전

TTL만 쓰면:

• 많은 요청이 몰리는 핫 상품에서
• 만료 시점에 동시에 미스가 발생 → DB로 한 번에 몰릴 수 있어. (cache stampede)

evict를 “변경 이벤트 때만” 해주면:

• 갱신 타이밍이 자연스럽게 분산되고,
• “변경이 없으면 캐시가 계속 히트”라 더 안정적으로 가.

(이건 특히 product.basic이 핫할 때 차이가 큼)

afterCommit을 붙이는 이유

evict 자체는 “언제 하느냐”가 핵심인데, 트랜잭션 안에서 바로 evict하면:

1) 롤백되면 “DB는 안 바뀌었는데 캐시만 날아간” 상태가 됨

그럼 다음 조회가 캐시 미스 → DB 조회 → 다시 캐시 저장이 반복되면서

• 불필요한 DB 부하
• 로그/추적이 꼬이는 운영 리스크
  가 생김.

-> “DB 커밋이 확정된 다음에만” 캐시를 비우는 게 정석이야.

요약: afterCommit은 ‘정합성’보다 ‘운영 안정성/일관성’ 때문이 큼.

✅ “안 해도 됨” (TTL만으로 충분)

• 화면 가격/할인 표시가 최대 60초 늦어도 문제 없음
• 변경(가격/할인/상태)이 자주 일어나지 않음
• 트래픽이 크지 않거나, 캐시 만료 타이밍 DB 스파이크가 큰 이슈가 아님

✅ “하는 게 좋음”

• 할인 시작/종료/가격 수정이 잦거나, “즉시 반영”이 필요
• 핫 상품 트래픽이 높아서 만료 순간 스파이크가 걱정
• 장애/롤백 상황에서도 캐시/DB 상태를 깔끔히 유지하고 싶음

최소 추가 구현

• product.basic: productId 키 evict
• discount.activePercent: 현재 minuteKey + 직전 minuteKey 2개만 evict(실전에서 이게 제일 간단/효과적)
• 전부 afterCommit에서 실행

[pjhcsols]

추가로 적용 할것 (적용 여부: )

• Product 수정/상태 변경/재고 갱신, 브랜드 할인 갱신 시 해당 productId에 대해서만 product.basic / discount.activePercent 키를 선택 Evict
• 트랜잭션 커밋 이후(afterCommit)로만 evict 실행해 롤백 시 캐시만 먼저 날아가는 역전 현상 방지
• TTL 기반 캐시 + 부분 무효화를 병행해 “짧은 신선도 + 운영 안전”을 동시에 확보

[pjhcsols]

“왜 Spring Cache(Caffeine) + TTL 60s + maxSize 20_000 + 캐시 2개(product.basic / discount.activePercent) + JPA 2nd-level 미사용”을 택했는지, 성능 관점으로 비교 정리.
(코드 구조: CachedCatalogReader의 per-id 캐시 + miss만 IN 배치 조회, discount는 per-minute 키를 전제로 함)

---

1. 왜 Spring Cache(Caffeine) + 로컬 메모리 캐시인가? (성능 비교)

Caffeine(로컬 in-memory) 장점

• 히트 시 비용이 “프로세스 내부 Map 접근” 수준이라, DB/네트워크가 아예 없음 → p99 지연시간이 확 줄어듦

• CachedCatalogReader가 hit/miss 분리를 하므로, 히트가 늘어날수록 DB 쿼리 수가 상한화됨

• Redis 같은 원격 캐시 대비

  • Redis: 네트워크 RTT + 직렬화/역직렬화 + 커넥션 풀 경합
  • Caffeine: JVM 내부 접근 + 직렬화 없음(현재 코드)

즉, 지금 니가 캐시하려는 “카탈로그(가격/브랜드/할인율)”은 읽기 빈도 매우 높고, 쓰기/정합성은 “60초 정도의 지연 허용”인 성격이라 로컬 캐시가 성능상 가장 잘 맞음.

---

2. 왜 JPA 2nd-level cache를 안 쓰는가? (성능/운영 리스크 비교)

2nd-level cache는 “엔티티 캐시”

• 엔티티 그래프/연관관계/프록시/영속성 컨텍스트/동시성/캐시 무효화 등 복잡도가 커짐

• 특히 상품/옵션/색상/사진 같이 관계가 많으면

  • 캐시 히트가 나도 결국 연관 로딩에서 추가 쿼리/N+1 또는 복잡한 invalidation이 터짐

• 반대로 지금은

  • Projection 기반 단순 필드(basic, percent)만 캐시 → 캐시 효율이 아주 높고 예측 가능

성능 관점에서 결론은 이거야:

• 엔티티 캐시는 “캐시 히트가 나도 연관 로딩 비용이 남는 경우”가 많고
• 너처럼 Projection/DTO로 “딱 필요한 것만” 캐시하는 게 히트의 체감 성능이 훨씬 큼

---

3. 왜 expireAfterWrite = 60s 인가? (성능 vs 신선도 trade-off)

60s가 “성능 측면에서” 유리한 이유

• TTL이 너무 짧으면(예: 5~10s)

  • 동일 상품을 여러 요청이 계속 miss → DB로 몰림 → 캐시가 “버퍼” 역할을 못 함

• TTL이 너무 길면(예: 10~30m)

  • 데이터 변경(가격/할인) 반영이 늦고, 결국 evict 설계가 훨씬 중요해짐(운영 부담 상승)

현재 코드가 discount.activePercent를 **minuteKey(분 단위)**로 키 정규화:

• TTL 60s ↔ minuteKey(분단위) 조합이 딱 맞음

  • “이 분(minute) 동안은 같은 키로 묶어서 히트를 극대화”
  • 다음 분으로 넘어가면 키 자체가 달라져서 자연스럽게 갱신 사이클

즉, 60초는

• 트래픽을 **DB로부터 확실히 분리(흡수)**할 만큼 길고
• stale을 운영적으로 수용 가능한 수준으로 제한하는 값.

---

4. 왜 maximumSize = 20_000 인가? (성능/메모리/스파이크 방어)

maximumSize는 “성능을 위해 캐시가 너무 빨리 쫓겨나지 않게” 잡는 값.

값이 너무 작으면

• 인기 상품/할인율 키가 계속 eviction → hit율 떨어짐 → DB로 재유입 → p99 나빠짐

값이 너무 크면

• JVM 힙을 많이 먹고 GC 압박 → 오히려 지연시간 악화(p99 GC spike)

적용한 캐시 특징 :

• product.basic: productId 당 1 엔트리

• discount.activePercent: productId × minuteKey라서 같은 productId도 분마다 키가 늘어날 수 있음

  • TTL 60s라 “쌓여도 1~2분치” 수준이지만, 트래픽이 많으면 순간적으로 키가 많이 생길 수 있어
    → 그래서 20k는 “핫 상품 + per-minute 키”를 충분히 담아서 hit율을 지키면서도, 힙 폭발을 막는 현실적인 상한선.

---

5. 왜 캐시를 2개로 쪼갰나? (성능/효율)

product.basic / discount.activePercent 분리의 성능적 이점

• 갱신 주기/변경 빈도가 다름

  • basic: 상품명/가격/브랜드 등은 상대적으로 덜 변함
  • discount: 시간 조건(now) 붙고, 이벤트성 갱신이 더 잦을 수 있음

• 같이 묶으면

  • discount 때문에 eviction/갱신이 자주 일어나면서 basic까지 같이 흔들리는 구조가 됨(히트율 손해)

• 분리하면

  • 각각 최적의 키 전략(per-id vs per-minute)을 적용 가능 → cache hit 효율 극대화

---

6. “성능 관점 결론” 한 문장

설계는 (1) 캐시 히트는 JVM O(1), (2) 미스는 IN 배치로 쿼리 수 상한화, (3) per-minute 키로 할인 time-condition 캐시 효율 극대화, (4) negative caching으로 미스 스파이크 차단이라서, DB 부하/지연시간(p95/p99) 둘 다 안정화시키는 선택.

---