Givemeticon

판단 근거

락이 풀려도 재고와 중복 발급 규칙은
DB에서 지켜져야 했습니다.

• 경합 제어: stockId 기준 Redisson 분산락으로 같은 재고의 동시 진입을 제어했습니다.
• 재고 보호: 조회 후 차감 사이의 경쟁을 없애기 위해 remain > 0인 경우에만 DB가 원자적으로 차감하게 했습니다.
• 중복 보호: (user_id, stock_id) UNIQUE와 변경 행 수 확인으로 발급 성공을 판단했습니다.

UPDATE coupon_stock
SET remain = remain - 1
WHERE id = #{id} AND remain > 0;

int updatedRows = couponStockMapper.decreaseStockIfEnough(stockId);
if (updatedRows != 1) {
    throw new NotEnoughCouponStockException();
}
// UNIQUE(user_id, stock_id)를 가진 테이블에 INSERT IGNORE
int insertedRows = couponMapper.saveIfNotIssued(coupon);
if (insertedRows != 1) {
    throw new AlreadyIssuedCouponException();
}

재고·쿠폰 서비스의 검사 부분을 모았습니다. 락 획득 후 AopForTransaction이 발급 흐름을 REQUIRES_NEW로 감싸며, 예외 시 함께 롤백하는 구조입니다.

판단 근거

20개를 보여주기 위해 매번 전체를
집계하는 비용에 주목했습니다.

• 시행착오: 좋아요 테이블에 인덱스를 추가했지만, GROUP BY + COUNT + ORDER BY의 반복 계산은 남았습니다.
• 원인 판단: LIMIT 20이어도 상위 상품을 찾기 위한 집계·정렬 비용이 먼저 발생하는 구조였습니다.
• 구조 전환: 쓰기 시점에 메타 테이블의 집계값을 갱신하고, 인기순 커버링 인덱스로 집계값 조회의 I/O를 줄였습니다.

SELECT i.id,
       i.brand_id,
       i.name,
       i.price,
       m.like_count,
       m.view_count
FROM item_favorite_meta m
JOIN item i
  ON i.id = m.item_id
ORDER BY m.like_count DESC, m.item_id DESC
LIMIT #{limit};

좋아요를 실시간 COUNT하지 않고 저장된 like_count로 정렬합니다. 같은 좋아요 수는 item_id로 순서를 결정합니다.