[volume - 9] What is Popularity? #210

minor7295 · 2025-12-23T17:00:05Z

📌 Summary

Kafka Consumer를 통해 수신한 이벤트를 기반으로 Redis ZSET을 이용한 실시간 랭킹 시스템을 구현했습니다.

주요 구현 내용:

랭킹 집계 (commerce-streamer): Kafka 이벤트 수신 → Spring ApplicationEvent 발행 → 랭킹 점수 계산 및 Redis ZSET 적재
랭킹 조회 (commerce-api): Redis ZSET에서 랭킹 조회 및 상품 정보 Aggregation
이벤트별 가중치 적용: 조회(0.1), 좋아요(0.2), 주문(0.6) 가중치로 점수 계산
Graceful Degradation: Redis 장애 시 스냅샷 → 기본 랭킹(좋아요순) Fallback
ZSET 모듈 분리: Redis ZSET 조작 로직을 별도 모듈로 분리하여 재사용성 향상

구현된 기능:

GET /api/v1/rankings?date=yyyyMMdd&size=20&page=1: 랭킹 페이지 조회
상품 상세 조회 시 해당 상품의 랭킹 정보 포함

💬 Review Points

1. 랭킹은 도메인이 아닌 유스케이스로 판단

배경 및 문제 상황:
랭킹 시스템을 구현할 때, 랭킹이 도메인인지 유스케이스인지 판단해야 했습니다. 도메인으로 취급하면 별도의 도메인 레이어를 만들어야 하지만, 랭킹은 비즈니스 규칙을 갖는 독립적인 도메인이 아니라 조회용 파생 데이터(Read Model)입니다.

해결 방안:
랭킹을 도메인이 아닌 Application 레이어의 유스케이스로 판단하여, 별도의 도메인 레이어를 만들지 않고 Application 레이어에만 구현했습니다. 랭킹은 CQRS 패턴의 Read Side로 취급하여, Write Side(도메인 이벤트) → Kafka → Read Side(랭킹 집계) → Redis ZSET 구조로 설계했습니다.

관련 코드:

// apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java
/**
 * 랭킹 점수 계산 및 ZSET 적재 서비스.
 * <p>
 * Application 유즈케이스: Ranking은 도메인이 아닌 파생 View로 취급
 * CQRS Read Model: Write Side(도메인) → Kafka → Read Side(Application) → Redis ZSET
 */
@Service
public class RankingService {
    // 랭킹 점수 계산 및 ZSET 적재 로직
}

고민한 점:

랭킹을 도메인으로 취급하면 별도의 도메인 레이어를 만들어야 하지만, 랭킹은 비즈니스 규칙을 갖는 독립적인 도메인이 아니라 조회용 파생 데이터입니다. 따라서 Application 레이어에만 구현하는 것이 적절하다고 판단했습니다.
랭킹은 CQRS 패턴의 Read Side로 취급하여, Write Side(도메인 이벤트)와 분리했습니다. 이렇게 하면 도메인 로직과 랭킹 집계 로직이 독립적으로 진화할 수 있습니다.

2. 외부 이벤트와 내부 이벤트 구분: Spring ApplicationEvent 사용

배경 및 문제 상황:
Kafka Consumer에서 이벤트를 수신한 후, 랭킹 집계에 필요한 데이터를 수집하는 것과 랭킹 점수를 계산하는 것은 서로 다른 책임입니다. Kafka로 consume하는 것은 외부 시스템과의 통신(인터페이스 계층)이고, ZSET의 점수 계산은 애플리케이션 내부 로직(애플리케이션 계층)입니다.

해결 방안:
도메인의 책임을 명확히 하기 위해, Kafka Consumer는 외부 이벤트를 수신하고 Spring ApplicationEvent로 발행하는 역할만 담당하고, 랭킹 계산 로직은 ApplicationEvent를 구독하는 별도의 핸들러에서 처리하도록 분리했습니다. 이렇게 하면 Kafka Consumer는 메시지 수신/파싱만 담당하고, 비즈니스 로직은 애플리케이션 계층에서 처리할 수 있습니다.

구조:

Kafka (외부 시스템)
    ↓
RankingConsumer (인터페이스 레이어)
    ├─ Kafka 메시지 수신/파싱
    ├─ 멱등성 체크
    └─ Spring ApplicationEvent 발행
        ↓
RankingEventListener (인터페이스 레이어)
    └─ @EventListener 구독 (@Async로 비동기 처리)
        ↓
RankingEventHandler (애플리케이션 레이어)
    └─ RankingService 호출
        ↓
RankingService (애플리케이션 레이어)
    └─ Redis ZSET 적재

관련 코드:

// apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java
@KafkaListener(topics = "like-events", containerFactory = KafkaConfig.BATCH_LISTENER)
public void consumeLikeEvents(List<ConsumerRecord<String, Object>> records, Acknowledgment acknowledgment) {
    // Kafka 메시지 수신/파싱 후 Spring ApplicationEvent 발행
    LikeEvent.LikeAdded event = parseLikeEvent(record.value());
    applicationEventPublisher.publishEvent(event);
    eventHandledService.markAsHandled(eventId, "LikeAdded", "like-events");
}

// apps/commerce-streamer/src/main/java/com/loopers/interfaces/event/ranking/RankingEventListener.java
@Async
@EventListener
public void handleLikeAdded(LikeEvent.LikeAdded event) {
    rankingEventHandler.handleLikeAdded(event);
}

// apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingEventHandler.java
public void handleLikeAdded(LikeEvent.LikeAdded event) {
    rankingService.addLikeScore(event.productId(), LocalDate.now(), true);
}

고민한 점:

Kafka Consumer에서 직접 RankingService를 호출하는 방식도 가능하지만, 이렇게 하면 Kafka Consumer가 비즈니스 로직을 포함하게 되어 책임이 섞입니다. Spring ApplicationEvent를 사용하면 관심사가 명확히 분리됩니다.
@Async를 사용하여 랭킹 집계 처리를 비동기로 실행하도록 했습니다. 이렇게 하면 Kafka Consumer의 성능에 영향을 주지 않고 랭킹 집계를 처리할 수 있습니다.

3. 콜드 스타트 문제 해결: Score Carry-Over 방식

배경 및 문제 상황:
일별 랭킹을 독립적으로 계산하면, 매일 자정에 랭킹이 0점에서 시작하는 콜드 스타트 문제가 발생합니다. 예를 들어, 어제 인기 있던 상품이 오늘 자정에 갑자기 랭킹에서 사라지면 사용자 경험이 좋지 않습니다.

해결 방안 및 방식 선택:

콜드 스타트 문제를 해결하기 위해 두 가지 방식을 고려했습니다. 첫 번째는 ZUNIONSTORE 명령어를 사용하여 시간별 랭킹을 별도로 관리하고 이를 일간 랭킹으로 집계하는 방식입니다. 이 방식은 시간별 랭킹 키(ranking:hourly:yyyyMMddHH)와 일간 랭킹 키(ranking:all:yyyyMMdd)에 이중으로 점수를 적재하고, ZUNIONSTORE로 시간별 랭킹을 일간 랭킹으로 집계합니다. 이 방식의 장점은 시간 단위 랭킹 조회가 가능하고, 시간별 가중치를 적용할 수 있으며, 배치 집계가 최적화된다는 점입니다. 하지만 단점으로는 Redis 메모리 사용량이 약 2.4배 증가하고, 시간별 랭킹 적재 로직, 집계 스케줄러, 시간 단위 Carry-Over 스케줄러 등으로 인해 구현 복잡도가 크게 증가하며, 스케줄러를 3개나 관리해야 하고, 두 개의 ZSET에 적재해야 하므로 실시간성도 약간 저하됩니다.

두 번째 방식은 일간 랭킹 키에 직접 점수를 적재하고, 일간 랭킹 Carry-Over만 구현하는 방식입니다. 이 방식은 구현이 단순하고, Redis 메모리 사용량을 최소화하며, 스케줄러를 1개만 관리하면 되고, 단일 ZSET에만 적재하므로 실시간성도 우수하며, 코드 복잡도가 낮아 유지보수가 용이합니다. 다만 시간별 가중치 적용은 불가능하지만, 현재 요구사항에는 이러한 기능이 필요하지 않습니다.

실무 관점에서 ZUNIONSTORE를 사용하지 않는 두 번째 방식을 최종적으로 선택했습니다. 현재 시간별 가중치 적용이 필요하지 않으므로, ZUNIONSTORE를 사용할 때 발생하는 비용(Redis 메모리 사용량 약 2.4배 증가, 스케줄러 관리 복잡도 증가) 대비 얻는 이점이 현재 상황에서는 적다고 판단했습니다. 또한 일간 랭킹에 직접 적재하는 방식이 더 단순하고 이해하기 쉬우며, 운영하기도 쉬워 실무에서 더 적합합니다. 만약 향후 시간별 랭킹 기능이 실제로 필요하다면, 그때 추가하는 것이 더 효율적입니다.

구현 코드:

// apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java
/**
 * 점수는 일간 랭킹 키에 직접 적재됩니다.
 */
public void addViewScore(Long productId, LocalDate date) {
    String key = keyGenerator.generateDailyKey(date); // ranking:all:yyyyMMdd
    incrementScore(key, productId, VIEW_WEIGHT);
}

/**
 * Score Carry-Over: 오늘의 랭킹을 가중치를 적용하여 내일 랭킹에 반영합니다.
 */
public Long carryOverScore(LocalDate today, LocalDate tomorrow, double carryOverWeight) {
    String todayKey = keyGenerator.generateDailyKey(today);
    String tomorrowKey = keyGenerator.generateDailyKey(tomorrow);
    return zSetTemplate.unionStoreWithWeight(tomorrowKey, todayKey, carryOverWeight);
}

스케줄러 구현:

// apps/commerce-streamer/src/main/java/com/loopers/infrastructure/scheduler/RankingCarryOverScheduler.java
/**
 * 랭킹 Score Carry-Over 스케줄러.
 * 매일 자정에 전날 랭킹을 오늘 랭킹에 일부 반영하여 콜드 스타트 문제를 완화합니다.
 */
@Scheduled(cron = "0 0 0 * * ?") // 매일 자정 (00:00:00)
public void carryOverScore() {
    LocalDate today = LocalDate.now();
    LocalDate yesterday = today.minusDays(1);
    rankingService.carryOverScore(yesterday, today, DEFAULT_CARRY_OVER_WEIGHT);
}

고민한 점:

일별 랭킹을 독립적으로 계산하면 매일 자정에 랭킹이 0점에서 시작하는 콜드 스타트 문제가 발생합니다. 이를 해결하기 위해 Score Carry-Over 방식을 선택했습니다.
Score Carry-Over 가중치(예: 0.1 = 10%)는 실제 운영 환경에서 조정이 필요할 수 있습니다. 너무 높으면 오래된 랭킹이 계속 반영되어 신선도가 떨어지고, 너무 낮으면 콜드 스타트 문제가 완전히 해결되지 않을 수 있습니다.
매일 자정에 자동으로 전날 랭킹을 오늘 랭킹에 반영하는 스케줄러를 구현하여, 콜드 스타트 문제를 완화했습니다.

4. 예외 처리: Graceful Degradation 전략

배경 및 문제 상황:
Redis 장애나 네트워크 오류로 인해 랭킹 조회가 실패할 수 있습니다. 이 경우 사용자에게 에러를 반환하는 것보다, 대체 데이터를 제공하는 것이 더 나은 사용자 경험을 제공합니다.

해결 방안:
멘토링 세션에서 "DB 실시간 재계산은 위험하므로 스냅샷 서빙이 현실적"이라는 조언을 받았습니다. 따라서 Redis 장애 시 인메모리 캐시에 저장된 랭킹 스냅샷을 서빙하도록 구현했습니다. 스냅샷도 없을 경우를 대비해 기본 랭킹(좋아요순)을 최종 Fallback으로 제공하지만, 이는 랭킹을 새로 계산하는 것이 아니라 이미 집계된 좋아요 수를 단순 조회하는 것이므로 DB 부하가 크지 않습니다.

구현 세부사항:

Redis 조회 시도: 먼저 요청한 날짜의 랭킹을 조회합니다.
스냅샷 Fallback: Redis 장애 시 인메모리 캐시에 저장된 랭킹 스냅샷을 조회합니다.
전날 스냅샷 Fallback: 당일 스냅샷이 없으면 전날 스냅샷을 조회합니다.
기본 랭킹 Fallback: 스냅샷도 없으면 기본 랭킹(좋아요순)을 제공합니다. 이는 랭킹을 계산하는 것이 아니라 이미 집계된 좋아요 수를 조회하는 단순 쿼리이므로 DB 부하가 크지 않습니다.

관련 코드:

// apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingService.java
@Transactional(readOnly = true)
public RankingsResponse getRankings(LocalDate date, int page, int size) {
    try {
        return getRankingsFromRedis(date, page, size);
    } catch (DataAccessException e) {
        // Redis 장애 시 스냅샷으로 Fallback
        Optional<RankingsResponse> snapshot = rankingSnapshotService.getSnapshot(date);
        if (snapshot.isPresent()) {
            return snapshot.get();
        }
        
        // 전날 스냅샷 시도
        Optional<RankingsResponse> yesterdaySnapshot = rankingSnapshotService.getSnapshot(date.minusDays(1));
        if (yesterdaySnapshot.isPresent()) {
            return yesterdaySnapshot.get();
        }
        
        // 최종 Fallback: 기본 랭킹(좋아요순) - 단순 조회, 계산 아님
        return getDefaultRankings(page, size);
    }
}

private RankingsResponse getDefaultRankings(int page, int size) {
    // 좋아요순으로 상품 조회 (이미 집계된 좋아요 수 단순 조회)
    List<Product> products = productService.findAll(null, "likes_desc", page, size);
    // ... 상품 정보 Aggregation 및 랭킹 항목 생성
}

스냅샷 저장 및 조회 구현:

// apps/commerce-api/src/main/java/com/loopers/infrastructure/scheduler/RankingSnapshotScheduler.java
@Scheduled(fixedRate = 3600000) // 1시간마다
public void saveRankingSnapshot() {
    LocalDate today = LocalDate.now();
    try {
        // 상위 100개 랭킹을 스냅샷으로 저장
        RankingService.RankingsResponse rankings = rankingService.getRankingsFromRedis(today, 0, 100);
        rankingSnapshotService.saveSnapshot(today, rankings);
    } catch (DataAccessException e) {
        // Redis 장애 시 스냅샷 저장 스킵 (다음 스케줄에서 재시도)
    }
}

// apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingSnapshotService.java
@Service
public class RankingSnapshotService {
    private final Map<String, RankingService.RankingsResponse> snapshotCache = new ConcurrentHashMap<>();
    private static final int MAX_SNAPSHOTS = 7; // 최근 7일치만 보관

    public void saveSnapshot(LocalDate date, RankingService.RankingsResponse rankings) {
        snapshotCache.put(date.format(DATE_FORMATTER), rankings);
        cleanupOldSnapshots(); // 메모리 관리
    }

    public Optional<RankingService.RankingsResponse> getSnapshot(LocalDate date) {
        return Optional.ofNullable(snapshotCache.get(date.format(DATE_FORMATTER)));
    }
}

고민한 점:

스냅샷 저장 방식 선택: 멘토링 세션에서 "DB 실시간 재계산은 위험하므로 스냅샷 서빙이 현실적"이라는 조언을 받았습니다. 스냅샷 저장 방식으로는 인메모리 캐시와 파일 시스템 두 가지를 고려했는데, 인메모리 캐시 방식을 선택했습니다. 랭킹은 비즈니스 결정이 아닌 조회용 파생 데이터이므로, 영속성이 필수는 아니며 스냅샷이 없어도 기본 랭킹(좋아요순)으로 대체 가능합니다. 인메모리 캐시는 구현이 간단하고 성능이 우수하며, 애플리케이션 재시작 시 스냅샷이 사라지더라도 기본 랭킹으로 Fallback할 수 있어 충분하다고 판단했습니다. 향후 영속성이 필요해지면 파일 시스템이나 Redis에 별도 키로 저장하는 방식으로 확장할 수 있습니다.
스냅샷 저장 주기 선택: 스냅샷 저장 주기를 1시간으로 지정했습니다. 랭킹은 상위 10위 내에서는 상대적으로 안정적이므로, 1시간정도로 업데이트해도 사용자가 체감하기 어렵다고 판단했습니다. 또한 Redis 장애 시 1시간 전 스냅샷도 어제 랭킹보다 훨씬 신선하며, 기본 랭킹으로 최종 Fallback할 수 있어 충분해 보입니다.
기본 랭킹 Fallback의 정당성: 스냅샷도 없을 경우를 대비해 기본 랭킹(좋아요순)을 최종 Fallback으로 제공하지만, 이는 랭킹을 새로 계산하는 것이 아니라 이미 집계된 좋아요 수를 단순 조회하는 것입니다. productService.findAll(null, "likes_desc", page, size)는 인덱스가 있는 컬럼을 기준으로 정렬된 결과를 반환하는 단순 쿼리이므로, 랭킹을 실시간으로 계산하는 것과는 다르게 DB 부하가 크지 않습니다. 다만 멘토링 조언에 따라 스냅샷을 우선적으로 사용하고, 기본 랭킹은 최후의 수단으로만 사용합니다.

5. ZSET을 별도 모듈로 분리

배경 및 문제 상황:
Redis ZSET 조작 로직이 여러 곳에서 사용될 수 있으므로, 재사용성을 높이기 위해 별도 모듈로 분리하는 것이 좋습니다.

해결 방안:
Redis ZSET 조작 로직을 modules/redis 모듈의 RedisZSetTemplate 클래스로 분리하여, 다른 애플리케이션에서도 재사용할 수 있도록 했습니다.

구현 세부사항:

RedisZSetTemplate: ZSET 조작 기능을 제공하는 템플릿 클래스
- incrementScore: 점수 증가
- getTopRankings: 상위 N개 조회
- getRank: 특정 멤버의 순위 조회
- getSize: ZSET 크기 조회
- unionStore: 여러 ZSET 합치기
- unionStoreWithWeight: 가중치를 적용하여 ZSET 합치기
- setTtlIfNotExists: TTL 설정

관련 코드:

// modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java
/**
 * Redis ZSET 템플릿.
 * <p>
 * Redis Sorted Set (ZSET) 조작 기능을 제공합니다.
 * ZSET은 Redis 전용 데이터 구조이므로 인터페이스 분리 없이 클래스로 직접 제공합니다.
 * </p>
 */
@Component
@RequiredArgsConstructor
public class RedisZSetTemplate {
    private final RedisTemplate<String, String> redisTemplate;
    
    public void incrementScore(String key, String member, double score) {
        redisTemplate.opsForZSet().incrementScore(key, member, score);
    }
    
    public List<ZSetEntry> getTopRankings(String key, long start, long end) {
        Set<ZSetOperations.TypedTuple<String>> tuples = redisTemplate.opsForZSet()
            .reverseRangeWithScores(key, start, end);
        // ... 변환 로직
    }
    
    // ... 기타 메서드
}

고민한 점:

ZSET은 Redis 전용 데이터 구조이므로 인터페이스 분리 없이 클래스로 직접 제공했습니다. 이렇게 하면 불필요한 추상화를 제거하고 단순성을 유지할 수 있습니다.
RedisZSetTemplate을 @Component로 등록하여 다른 애플리케이션에서도 쉽게 사용할 수 있도록 했습니다.

✅ Checklist

Ranking Consumer

랭킹 ZSET의 TTL, 키 전략을 적절하게 구성하였다
- 키 형식: ranking:all:yyyyMMdd (일간 랭킹)
- TTL: 2일 (Duration.ofDays(2))
- apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java
날짜별로 적재할 키를 계산하는 기능을 만들었다
- RankingKeyGenerator.generateDailyKey(): 일간 랭킹 키 생성 (ranking:all:yyyyMMdd)
- apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java
이벤트가 발생한 후, ZSET에 점수가 적절하게 반영된다
- 조회: Weight = 0.1
- 좋아요: Weight = 0.2
- 주문: Weight = 0.6, Score = log(1 + orderAmount) * ORDER_WEIGHT
- apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java

Ranking API

랭킹 Page 조회 시 정상적으로 랭킹 정보가 반환된다
- GET /api/v1/rankings?date=yyyyMMdd&size=20&page=1
- apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java
랭킹 Page 조회 시 단순히 상품 ID가 아닌 상품정보가 Aggregation 되어 제공된다
- 상품 정보 배치 조회 (N+1 쿼리 문제 방지)
- 브랜드 정보 배치 조회
- apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingService.java (98-170줄)
상품 상세 조회 시 해당 상품의 순위가 함께 반환된다 (순위에 없다면 null)
- RankingService.getProductRank(): 특정 상품의 순위 조회
- apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java (랭킹 정보 포함)

-->

📎 References

Summary by CodeRabbit

릴리스 노트

새로운 기능
- 상품에 순위 정보 추가: 조회수, 좋아요, 주문을 기반으로 계산된 상품 순위가 상품 응답에 포함됩니다.
- 랭킹 API 추가: /api/v1/rankings 엔드포인트를 통해 날짜별 상품 순위를 페이지네이션과 함께 조회할 수 있습니다.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

* feat: zset 모듈 추가 zset * test: 랭킹 계산에 대한 테스트 코드 추가 * feat: 랭킹 계산 서비스 구현 * test: 랭킹 이벤트 컨슈머 테스트 로직 추가 * feat: 랭킹 컨슈머 구현 * test: 랭킹 조회 통합 테스트 코드 추가 * feat: 랭킹 조회 서비스 로직 구현 * feat: 랭킹 조회 엔드포인트 추가 * test: 랭킹 정보 포함하여 상품 조회하는 테스트 코드 작성 * feat: 랭킹 포함하여 상품 정보 조회하도록 api 수정 --------- Co-authored-by: 이건영 <>

coderabbitai · 2025-12-23T17:00:12Z

Walkthrough

상품에 랭킹 기능을 추가하는 기능 개발로, 캐시에서 상품 상세 정보를 조회한 후 런타임에 Redis ZSET에서 랭킹 데이터를 별도로 조회하여 반환하는 구조를 구현합니다. 카프카 이벤트(좋아요, 주문, 조회)를 소비하여 Redis의 정렬된 집합에 랭킹 점수를 누적합니다.

Changes

Cohort / File(s)	변경 요약
ProductInfo 및 DTO 확장 `apps/commerce-api/src/main/java/com/loopers/application/catalog/ProductInfo.java`, `apps/commerce-api/src/main/java/com/loopers/interfaces/api/catalog/ProductV1Dto.java`	`ProductInfo` 레코드에 `rank` 필드 추가; `withoutRank()`, `withRank()` 정적 팩토리 메서드 도입. API 응답 DTO인 `ProductResponse`에도 `rank` 필드 추가
캐시 및 조회 로직 개선 `apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java`, `apps/commerce-api/src/main/java/com/loopers/application/product/ProductCacheService.java`	`CatalogFacade`에 `RankingService` 주입; 캐시는 랭킹 없이 저장하되 반환 시점에 런타임 랭킹 조회. `ProductCacheService.applyLikeCountDelta()`에서 `withoutRank()` 사용
Redis 랭킹 핵심 로직 `apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingService.java`, `apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java`	API 계층에서 `RankingService`로 Redis ZSET에서 상위 랭킹 조회 및 상품 상세 정보 통합, `RankingKeyGenerator`로 일일/시간별 Redis 키 생성
Redis 랭킹 API 엔드포인트 `apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java`, `apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Dto.java`	새로운 `/api/v1/rankings` 엔드포인트로 페이지네이션과 날짜 필터링 지원; 응답 DTO 구조는 `RankingItemResponse`, `RankingsResponse`
스트리머 랭킹 서비스 `apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java`, `apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java`	스트리머 계층의 `RankingService`는 조회, 좋아요, 주문 이벤트 기반 점수 계산 및 Redis ZSET에 누적; 배치 처리 및 TTL 관리
Kafka 이벤트 소비 및 랭킹 업데이트 `apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java`	좋아요, 주문, 상품 조회 카프카 토픽 소비; 이벤트 ID 기반 멱등성 검증; 각 이벤트 타입별 점수 계산 및 `RankingService` 호출
Redis ZSET 추상화 계층 `modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java`, `modules/redis/src/main/java/com/loopers/zset/ZSetEntry.java`	`RedisZSetTemplate`으로 ZSET 점수 증가, TTL 설정, 랭크 조회, 상위 랭킹 조회, 크기 조회 기능 제공; `ZSetEntry` 레코드로 멤버와 점수 표현
API 계층 테스트 `apps/commerce-api/src/test/java/com/loopers/application/catalog/CatalogFacadeTest.java`, `apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingServiceTest.java`	`CatalogFacade` 캐시 히트/미스 시 랭킹 통합 검증; `RankingService` 상위 랭킹 조회, 페이징, 빈 결과 처리 등 검증
스트리머 계층 테스트 `apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingServiceTest.java`, `apps/commerce-streamer/src/test/java/com/loopers/interfaces/consumer/RankingConsumerTest.java`	스트리머 `RankingService`의 점수 계산 로직, 배치 처리, TTL 검증; `RankingConsumer`의 이벤트 소비, 멱등성, 예외 처리 검증

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant API as RankingV1Controller
    participant CatalogFacade
    participant Cache as ProductCacheService
    participant RankingAPI as RankingService<br/>(API)
    participant Redis as RedisZSetTemplate
    participant ProductService
    
    Client->>API: GET /api/v1/products/{id}
    API->>CatalogFacade: getProduct(productId)
    
    alt Cache Hit
        CatalogFacade->>Cache: getCachedProductDetail(productId)
        Cache-->>CatalogFacade: ProductDetail (without rank)
        CatalogFacade->>RankingAPI: getProductRank(productId, today)
        RankingAPI->>Redis: getRank(daily_key, productId)
        Redis-->>RankingAPI: Long rank
        RankingAPI-->>CatalogFacade: Long rank
        CatalogFacade-->>API: ProductInfo(detail, rank)
    else Cache Miss
        CatalogFacade->>ProductService: getProduct(productId)
        ProductService-->>CatalogFacade: Product
        CatalogFacade->>Cache: cacheProductDetail(ProductDetail without rank)
        CatalogFacade->>RankingAPI: getProductRank(productId, today)
        RankingAPI->>Redis: getRank(daily_key, productId)
        Redis-->>RankingAPI: Long rank
        RankingAPI-->>CatalogFacade: Long rank
        CatalogFacade-->>API: ProductInfo(detail, rank)
    end
    
    API-->>Client: ApiResponse<ProductResponse>

sequenceDiagram
    participant Kafka as Kafka Topics
    participant Consumer as RankingConsumer
    participant EventService as EventHandledService
    participant RankingService
    participant Redis as RedisZSetTemplate
    
    Kafka->>Consumer: ConsumerRecord (Like/Order/View Event)
    Consumer->>EventService: isAlreadyHandled(eventId)
    
    alt Not Yet Handled
        alt Like Event
            Consumer->>RankingService: addLikeScore(productId, date, isAdded)
        else Order Event
            Consumer->>RankingService: addOrderScore(productId, date, amount)
        else Product Event
            Consumer->>RankingService: addViewScore(productId, date)
        end
        
        RankingService->>Redis: incrementScore(key, productId, score)
        Redis-->>RankingService: ✓
        RankingService->>Redis: setTtlIfNotExists(key, 2days)
        Redis-->>RankingService: ✓
        
        Consumer->>EventService: markAsHandled(eventId)
        EventService-->>Consumer: ✓
    else Already Handled
        Note over Consumer: Skip processing
    end
    
    Consumer-->>Kafka: acknowledge batch

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

[volume-5] 인덱스 및 Redis 캐시 적용 #140: 상품의 좋아요 개수와 캐싱/Redis 동작을 수정했으며, 본 PR이 이를 기반으로 하여 ProductInfo, 캐시 처리, 랭킹 관련 Redis ZSET 사용법을 확장합니다.

Suggested labels

enhancement

Poem

🐰 토끼가 노래하는 랭킹 축가

Redis 점수 쌓이고, 랭킹 순위 정렬되니,
상품들 경쟁하며 최고 자리 차지하네.
좋아요, 주문, 조회가 카프카를 타고,
빠르게 ZSET에 모여 등수 매기고 나타나,
맨 위부터 펼쳐진 영광의 목록을! 🏆✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 54.67% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.
Title check	❓ Inconclusive	PR 제목 '[volume - 9] What is Popularity?'은 변경사항의 핵심인 랭킹 기능 추가를 간접적으로만 나타내며, 구체적이고 명확한 정보를 제공하지 못합니다.	제목을 'Add product ranking feature with Redis-backed ZSET scoring' 같은 구체적인 표현으로 변경하여 변경사항의 주요 내용을 명확히 드러내도록 권장합니다.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	PR 설명이 템플릿의 모든 필수 섹션(📌 Summary, 💬 Review Points, ✅ Checklist)을 포함하고 있으며, 내용이 구체적이고 상세합니다.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

minor7295 · 2025-12-23T17:00:17Z

@coderabbitai review

coderabbitai · 2025-12-23T17:00:24Z

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

coderabbitai

Actionable comments posted: 6

♻️ Duplicate comments (1)

apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingServiceTest.java (1)

48-69: 리플렉션 헬퍼 메서드가 CatalogFacadeTest와 중복됩니다.

앞서 언급한 대로, 공통 테스트 유틸리티 클래스로 추출을 고려하세요.

🧹 Nitpick comments (15)

apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java (1)

34-37: null 입력에 대한 방어 코드 고려

date 파라미터가 null인 경우 NullPointerException이 발생합니다. 호출자가 항상 non-null을 보장한다면 괜찮지만, 방어적 프로그래밍 관점에서 null 체크를 추가하거나 @NonNull 어노테이션을 명시하는 것을 고려해 보세요.
apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java (2)
128-132: 테스트 용이성을 위한 시간 추상화 고려

LocalDate.now()를 직접 호출하면 단위 테스트에서 날짜를 제어하기 어렵습니다. Clock을 주입받거나, 별도의 날짜 제공자를 사용하면 테스트 시 시간을 고정할 수 있습니다.
🔎 Clock 주입 예시
// 필드 추가
private final Clock clock;

// 생성자에서 주입 (또는 @Value로 기본값 설정)

// 사용 시
LocalDate today = LocalDate.now(clock);
147-159: 캐시 미스 시 흐름 개선 가능

현재 흐름에서 ProductInfo.withoutRank(productDetail)을 두 번 생성하고 있습니다 (Line 152, 158). 한 번만 생성하여 재사용하면 코드가 더 명확해집니다.
🔎 개선 제안
         // 랭킹 정보 조회
         LocalDate today = LocalDate.now();
         Long rank = rankingService.getProductRank(productId, today);
         
-        // 캐시에 저장 (랭킹 정보는 제외하고 저장 - 랭킹은 실시간으로 조회)
-        productCacheService.cacheProduct(productId, ProductInfo.withoutRank(productDetail));
+        // 캐시에 저장 (랭킹 정보는 제외하고 저장 - 랭킹은 실시간으로 조회)
+        ProductInfo productInfoWithoutRank = ProductInfo.withoutRank(productDetail);
+        productCacheService.cacheProduct(productId, productInfoWithoutRank);
         
         // ✅ 상품 조회 이벤트 발행 (메트릭 집계용)
         productEventPublisher.publish(ProductEvent.ProductViewed.from(productId));
         
         // 로컬 캐시의 좋아요 수 델타 적용 (DB 조회 결과에도 델타 반영)
-        ProductInfo deltaApplied = productCacheService.applyLikeCountDelta(ProductInfo.withoutRank(productDetail));
+        ProductInfo deltaApplied = productCacheService.applyLikeCountDelta(productInfoWithoutRank);
         return ProductInfo.withRank(deltaApplied.productDetail(), rank);
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java (3)
6-6: 사용되지 않는 import 제거

@DateTimeFormat 어노테이션이 import되어 있지만 코드에서 사용되지 않습니다.
🔎 제안
-import org.springframework.format.annotation.DateTimeFormat;
82-87: 잘못된 날짜 형식에 대한 피드백 부재

날짜 파싱 실패 시 예외를 무시하고 오늘 날짜를 반환합니다. 클라이언트가 잘못된 형식을 전달했을 때 이를 인지하지 못할 수 있습니다. 로깅을 추가하거나, 명시적으로 400 Bad Request를 반환하는 것을 고려하세요.
🔎 로깅 추가 예시
         try {
             return LocalDate.parse(dateStr, DATE_FORMATTER);
         } catch (DateTimeParseException e) {
-            // 파싱 실패 시 오늘 날짜 반환
+            log.warn("날짜 파싱 실패, 오늘 날짜 사용: input={}", dateStr);
             return LocalDate.now();
         }
54-62: 메서드 파라미터 재할당 지양

page와 size 파라미터를 메서드 내에서 재할당하고 있습니다. 이는 코드 가독성을 저하시킬 수 있습니다. 별도의 지역 변수를 사용하는 것이 더 명확합니다.
🔎 개선 제안
-        // 페이징 검증
-        if (page < 0) {
-            page = 0;
-        }
-        if (size < 1) {
-            size = 20;
-        }
-        if (size > 100) {
-            size = 100; // 최대 100개로 제한
-        }
+        // 페이징 검증
+        int validPage = Math.max(page, 0);
+        int validSize = Math.max(1, Math.min(size, 100));

-        RankingService.RankingsResponse result = rankingService.getRankings(targetDate, page, size);
+        RankingService.RankingsResponse result = rankingService.getRankings(targetDate, validPage, validSize);
apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java (1)

133-137: 개별 호출마다 TTL 설정 호출 최적화 고려

incrementScore가 호출될 때마다 setTtlIfNotExists를 호출합니다. setTtlIfNotExists는 내부적으로 TTL이 없을 때만 설정하지만, 매번 Redis 호출이 발생할 수 있습니다. 고빈도 호출 시 불필요한 네트워크 오버헤드가 발생할 수 있습니다.

addScoresBatch처럼 배치 단위로 TTL을 설정하거나, 키별로 로컬에서 TTL 설정 여부를 추적하는 방식을 고려해 보세요.

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java (1)

18-51: 코드 중복: commerce-streamer 모듈과 동일한 RankingKeyGenerator 클래스가 존재합니다.

apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java에 동일한 로직의 클래스가 있습니다. 두 모듈 모두에서 동일한 키 생성 로직을 사용하므로, 공유 모듈(예: modules/redis 또는 별도의 modules/ranking-common)로 추출하여 중복을 제거하는 것을 권장합니다.

현재 구현 자체는 올바르며, DateTimeFormatter를 static final로 재사용하는 것은 좋은 패턴입니다.
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingService.java (1)
82-93: Collectors.toMap에서 중복 키 발생 시 예외 가능성

Collectors.toMap은 중복 키가 있을 경우 IllegalStateException을 발생시킵니다. Redis ZSET에서 반환된 productIds에 중복이 없다고 가정하지만, productService.getProducts()가 중복된 ID를 가진 Product를 반환하는 경우 예외가 발생할 수 있습니다.
🔎 중복 키 처리를 위한 수정 제안
 Map<Long, Product> productMap = products.stream()
-    .collect(Collectors.toMap(Product::getId, product -> product));
+    .collect(Collectors.toMap(Product::getId, product -> product, (existing, replacement) -> existing));

 Map<Long, Brand> brandMap = brandService.getBrands(brandIds).stream()
-    .collect(Collectors.toMap(Brand::getId, brand -> brand));
+    .collect(Collectors.toMap(Brand::getId, brand -> brand, (existing, replacement) -> existing));
apps/commerce-api/src/test/java/com/loopers/application/catalog/CatalogFacadeTest.java (1)

67-88: 리플렉션 유틸리티 메서드 중복

setId(Product, Long)와 setId(Brand, Long) 메서드가 RankingServiceTest에도 동일하게 존재합니다. 테스트 유틸리티 클래스로 추출하면 코드 중복을 줄일 수 있습니다.

또한 lines 157-163과 199-206에서 likeCount 설정을 위한 리플렉션 코드도 중복되어 있습니다.
modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java (2)
59-69: TTL 조건 검사에서 키가 존재하지 않는 경우 누락

getExpire()는 키가 존재하지 않을 때 -2를 반환합니다. 현재 조건 currentTtl == null || currentTtl == -1은 이 경우를 처리하지 않습니다. 단, ZSET에 incrementScore가 먼저 호출된 후 setTtlIfNotExists가 호출되는 순서라면 키가 이미 존재하므로 문제없을 수 있습니다.
🔎 더 명확한 조건 처리 제안
 public void setTtlIfNotExists(String key, Duration ttl) {
     try {
         Long currentTtl = redisTemplate.getExpire(key);
-        if (currentTtl == null || currentTtl == -1) {
+        if (currentTtl == null || currentTtl < 0) {
             // TTL이 없거나 -1(만료 시간 없음)인 경우에만 설정
+            // -2는 키가 존재하지 않는 경우
             redisTemplate.expire(key, ttl);
         }
     } catch (Exception e) {
         log.warn("ZSET TTL 설정 실패: key={}", key, e);
     }
 }
41-48: Silent failure 동작에 대한 문서화 고려

incrementScore에서 예외 발생 시 로그만 남기고 계속 진행하는 것은 의도된 설계이지만, 이로 인해 데이터 유실이 발생할 수 있습니다. 클라이언트 코드에서 이 동작을 인지할 수 있도록 Javadoc에 이 동작을 명시하는 것이 좋습니다.
apps/commerce-streamer/src/test/java/com/loopers/interfaces/consumer/RankingConsumerTest.java (1)

185-222: 배치 처리 테스트가 실제 배치 시나리오를 완전히 반영하지 않음

canConsumeMultipleEvents 테스트는 consumeLikeEvents와 consumeProductEvents를 별도로 호출합니다. 실제 배치 처리 시나리오(단일 consumer 호출에서 여러 레코드 처리)를 테스트하려면 동일한 이벤트 타입의 여러 레코드를 하나의 리스트로 전달해야 합니다.

현재 테스트는 여전히 유효하지만, 테스트 이름과 의도가 일치하도록 조정하거나 실제 배치 시나리오 테스트를 추가하는 것을 고려하세요.
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java (2)
320-344: Like 이벤트 파싱 로직을 개선할 수 있습니다.

Lines 323, 339의 파싱 로직이 비효율적입니다:

이미 타입이 지정된 객체인 경우에도 JSON으로 직렬화 후 다시 역직렬화하는 불필요한 과정을 거칩니다.

parseOrderCreatedEvent와 parseProductViewedEvent는 instanceof 체크를 먼저 수행하는 반면, 이 두 메서드는 그렇지 않아 일관성이 부족합니다.
🔎 개선된 파싱 로직 제안
 private LikeEvent.LikeAdded parseLikeEvent(Object value) {
     try {
+        if (value instanceof LikeEvent.LikeAdded) {
+            return (LikeEvent.LikeAdded) value;
+        }
+        
         // JSON 문자열인 경우 파싱
         String json = value instanceof String ? (String) value : objectMapper.writeValueAsString(value);
         return objectMapper.readValue(json, LikeEvent.LikeAdded.class);
     } catch (Exception e) {
         throw new RuntimeException("LikeAdded 이벤트 파싱 실패", e);
     }
 }

 private LikeEvent.LikeRemoved parseLikeRemovedEvent(Object value) {
     try {
+        if (value instanceof LikeEvent.LikeRemoved) {
+            return (LikeEvent.LikeRemoved) value;
+        }
+        
         // JSON 문자열인 경우 파싱
         String json = value instanceof String ? (String) value : objectMapper.writeValueAsString(value);
         return objectMapper.readValue(json, LikeEvent.LikeRemoved.class);
     } catch (Exception e) {
         throw new RuntimeException("LikeRemoved 이벤트 파싱 실패", e);
     }
 }
420-433: 사용되지 않는 메서드입니다.

extractVersion 메서드가 정의되어 있지만 코드 어디에서도 호출되지 않습니다. 향후 사용 계획이 있다면 유지하고, 그렇지 않다면 제거를 고려하세요.
#!/bin/bash
# extractVersion 메서드 사용처 확인
rg -n "extractVersion" --type=java

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3af88f9 and 22bb0a9.

📒 Files selected for processing (17)

apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java
apps/commerce-api/src/main/java/com/loopers/application/catalog/ProductInfo.java
apps/commerce-api/src/main/java/com/loopers/application/product/ProductCacheService.java
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingService.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/catalog/ProductV1Dto.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Dto.java
apps/commerce-api/src/test/java/com/loopers/application/catalog/CatalogFacadeTest.java
apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingServiceTest.java
apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java
apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java
apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingServiceTest.java
apps/commerce-streamer/src/test/java/com/loopers/interfaces/consumer/RankingConsumerTest.java
modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java
modules/redis/src/main/java/com/loopers/zset/ZSetEntry.java

🧰 Additional context used

🧠 Learnings (7)

📓 Common learnings

Learnt from: junoade
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 0
File: :0-0
Timestamp: 2025-12-02T08:12:06.383Z
Learning: ProductQueryService에서 상품 목록 조회 시 Redis 캐시를 적용했으며, 캐시 키는 brandId, sortType, pageNumber, pageSize의 조합으로 구성되고 TTL은 5분으로 설정되어 있다.

📚 Learning: 2025-12-19T21:30:08.018Z

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: apps/commerce-api/src/main/kotlin/com/loopers/infrastructure/outbox/OutboxEventListener.kt:0-0
Timestamp: 2025-12-19T21:30:08.018Z
Learning: In the Loopers-dev-lab/loopers-spring-kotlin-template Kafka event pipeline, Like events (LikeCreatedEventV1, LikeCanceledEventV1) intentionally use aggregateType="Like" with aggregateId=productId. The aggregateId serves as a partitioning/grouping key (not a unique Like entity identifier), ensuring all like events for the same product go to the same partition for ordering guarantees and aligning with ProductStatisticService's product-based aggregation logic. Using individual like_id would scatter events across partitions and break the statistics aggregation pattern.

Applied to files:

apps/commerce-streamer/src/test/java/com/loopers/interfaces/consumer/RankingConsumerTest.java
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java

📚 Learning: 2025-12-19T20:59:50.009Z

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: docs/week8/round8-detailed-design.md:151-178
Timestamp: 2025-12-19T20:59:50.009Z
Learning: In the Loopers-dev-lab/loopers-spring-kotlin-template repository's Kafka event pipeline, only 5 domain events are intentionally published to Kafka via CloudEventEnvelopeFactory: OrderPaidEventV1, LikeCreatedEventV1, LikeCanceledEventV1, ProductViewedEventV1, and StockDepletedEventV1. Other domain events (OrderCreatedEventV1, OrderCanceledEventV1, PaymentCreatedEventV1, PaymentPaidEventV1, PaymentFailedEventV1) are internal-only and intentionally not mapped in resolveMetadata(), which correctly returns null for them to exclude them from Outbox publication.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java

📚 Learning: 2025-12-18T13:24:51.650Z

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 190
File: apps/commerce-streamer/src/main/java/com/loopers/applications/streamer/consumer/product/IncreaseProductViewKafkaConsumer.java:25-35
Timestamp: 2025-12-18T13:24:51.650Z
Learning: Adopt centralized error handling for Kafka consumers by using the EventInboxAspect to intercept methods annotated with InboxEvent. Ensure that service methods annotated with InboxEvent save failed EventInbox entries and log errors, avoiding duplicating error handling logic in individual consumers. Apply this pattern broadly to similar consumer/service layers within the commerce-streamer module.

Applied to files:

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java

📚 Learning: 2025-12-19T09:30:12.459Z

Learnt from: HongChangMo
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 198
File: apps/commerce-api/src/main/java/com/loopers/application/payment/PaymentEventListener.java:0-0
Timestamp: 2025-12-19T09:30:12.459Z
Learning: In the loopers-spring-java-template repository's commerce-api module, when entities are managed within a transactional context (e.g., Transactional methods), prefer relying on JPA dirty checking for automatic persistence rather than explicit save() calls. Both Payment and Order entities in PaymentEventListener use this pattern, with state changes automatically flushed on transaction commit.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java

📚 Learning: 2025-12-02T08:12:06.383Z

Learnt from: junoade
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 0
File: :0-0
Timestamp: 2025-12-02T08:12:06.383Z
Learning: ProductQueryService에서 상품 목록 조회 시 Redis 캐시를 적용했으며, 캐시 키는 brandId, sortType, pageNumber, pageSize의 조합으로 구성되고 TTL은 5분으로 설정되어 있다.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java

📚 Learning: 2025-11-27T09:09:24.961Z

Learnt from: sky980221
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 121
File: apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductJpaRepository.java:22-24
Timestamp: 2025-11-27T09:09:24.961Z
Learning: Product 엔티티 (apps/commerce-api/src/main/java/com/loopers/domain/product/Product.java)는 유즈케이스별로 의도적으로 다른 락 전략을 사용한다: 좋아요 기능에는 비관적 락(findByIdForUpdate)을, 재고 차감에는 낙관적 락(Version + 재시도)을 사용한다.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java
apps/commerce-api/src/main/java/com/loopers/application/product/ProductCacheService.java

🧬 Code graph analysis (3)

apps/commerce-streamer/src/test/java/com/loopers/interfaces/consumer/RankingConsumerTest.java (2)

apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingServiceTest.java (1)

ExtendWith (27-400)

apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingServiceTest.java (1)

ExtendWith (25-247)

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java (3)

apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java (1)

Slf4j (38-138)

modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java (1)

Slf4j (24-140)

apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java (1)

Component (18-52)

modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java (1)

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java (1)

Component (18-52)

🔇 Additional comments (20)

modules/redis/src/main/java/com/loopers/zset/ZSetEntry.java (1)

1-12: LGTM!

ZSET 엔트리를 표현하는 간결한 record입니다. Javadoc도 적절히 작성되어 있습니다.

apps/commerce-api/src/main/java/com/loopers/application/product/ProductCacheService.java (1)

272-272: LGTM!

withoutRank 팩토리 메서드를 사용하여 랭킹 정보 없이 ProductInfo를 반환하는 것이 적절합니다. 랭킹 정보는 실시간으로 조회되므로 캐시된 좋아요 델타 적용 시 랭킹을 포함하지 않는 것이 올바른 설계입니다.

apps/commerce-api/src/main/java/com/loopers/application/catalog/CatalogFacade.java (1)

96-96: 상품 목록에 랭킹 정보 미포함 확인

상품 목록 조회 시 withoutRank를 사용하여 랭킹 정보를 포함하지 않습니다. 이것이 의도된 동작인지 확인해 주세요. 목록에서도 랭킹을 보여주어야 한다면 수정이 필요합니다.

apps/commerce-api/src/main/java/com/loopers/application/catalog/ProductInfo.java (1)

11-31: LGTM!

withoutRank와 withRank 팩토리 메서드를 통해 랭킹 정보 유무에 따른 ProductInfo 생성을 명확하게 분리한 좋은 설계입니다. record의 불변성을 유지하면서 확장성 있는 구조를 제공합니다.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/catalog/ProductV1Dto.java (1)

26-51: LGTM!

rank 필드가 ProductResponse에 적절히 추가되었으며, ProductInfo로부터의 매핑도 올바르게 구현되었습니다. Javadoc도 명확하게 업데이트되었습니다.

apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingService.java (2)

70-76: 좋아요 취소 시 음수 점수 가능성

좋아요 취소 시 -LIKE_WEIGHT를 적용합니다. 만약 좋아요가 추가되기 전에 취소 이벤트가 먼저 처리되면 (이벤트 순서 역전), 해당 상품의 점수가 음수가 될 수 있습니다. Eventually Consistent 설계 원칙에 따라 허용 가능한 상황인지 확인해 주세요.

38-48: LGTM!

랭킹 점수 가중치와 TTL 설정이 명확하게 정의되어 있습니다. CQRS Read Model 설계 원칙에 따른 구현이 적절합니다.

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingService.java (2)

60-61: @Transactional(readOnly = true) 어노테이션 재고 필요

이 메서드는 주로 Redis에서 데이터를 읽고, ProductService와 BrandService를 통해 DB 조회를 수행합니다. 만약 ProductService.getProducts()와 BrandService.getBrands()가 이미 자체적으로 트랜잭션을 관리하고 있다면, 이 레벨에서 별도의 트랜잭션은 불필요한 오버헤드가 될 수 있습니다.

하위 서비스의 트랜잭션 설정을 확인하고, 필요한 경우에만 유지하세요.

96-132: LGTM! 배치 조회 패턴이 잘 구현되어 있습니다.

N+1 쿼리 문제를 방지하기 위해 상품과 브랜드를 배치로 조회하고, 누락된 데이터에 대해 로그를 남기며 스킵하는 처리가 적절합니다. hasNext 계산 로직도 명확합니다.

apps/commerce-api/src/test/java/com/loopers/application/catalog/CatalogFacadeTest.java (1)

90-229: LGTM! 캐시 히트/미스 시나리오에 대한 랭킹 통합 테스트가 포괄적입니다.

4가지 주요 시나리오(캐시 히트 + 랭킹 있음/없음, 캐시 미스 + 랭킹 있음/없음)를 모두 커버하고 있으며, mock 설정과 검증이 적절합니다.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Dto.java (1)

14-94: LGTM! DTO 설계가 깔끔합니다.

from() 팩토리 메서드를 통한 도메인-API 매핑이 명확하고, record를 사용하여 불변 DTO를 구현한 것이 적절합니다.

apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingServiceTest.java (1)

71-399: LGTM! RankingService에 대한 포괄적인 테스트 커버리지가 잘 구현되어 있습니다.

다음 시나리오들이 모두 테스트되었습니다:

기본 랭킹 조회 및 페이징

빈 결과 처리

누락된 상품/브랜드 스킵

hasNext 플래그 계산

단일 상품 순위 조회

동일 브랜드 중복 제거

각 테스트가 명확한 arrange/act/assert 구조를 따르고 있습니다.

apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingServiceTest.java (1)

24-247: LGTM! commerce-streamer 모듈의 RankingService 점수 업데이트 로직에 대한 테스트가 잘 구현되어 있습니다.

조회/좋아요/주문 점수 추가, 배치 처리, 빈 배치 처리, 다중 날짜 독립 처리, 점수 누적 등 핵심 시나리오가 모두 커버되어 있습니다. ArgumentCaptor를 사용하여 동적 점수 값을 검증하는 것도 적절합니다.

modules/redis/src/main/java/com/loopers/zset/RedisZSetTemplate.java (1)

102-120: LGTM! getTopRankings 구현이 올바릅니다.

reverseRangeWithScores를 사용하여 점수가 높은 순서로 정렬된 결과를 반환하고, null 체크 및 예외 처리가 적절합니다.

apps/commerce-streamer/src/test/java/com/loopers/interfaces/consumer/RankingConsumerTest.java (2)

415-455: LGTM! 멱등성 테스트가 잘 구현되어 있습니다.

동일한 eventId를 가진 중복 메시지 3개를 처리할 때 첫 번째만 실제 처리되고 나머지는 스킵되는 것을 검증합니다. isAlreadyHandled의 순차적 반환값 설정과 호출 횟수 검증이 적절합니다.

1-414: LGTM! RankingConsumer에 대한 포괄적인 테스트 커버리지

다음 시나리오들이 잘 테스트되었습니다:

각 이벤트 타입(LikeAdded, LikeRemoved, OrderCreated, ProductViewed) 처리

이미 처리된 이벤트 스킵

eventId 없는 메시지 처리

개별 이벤트 실패 시 배치 처리 계속

DataIntegrityViolationException 처리 (동시성 상황)

주문 이벤트의 엣지 케이스 (totalQuantity=0, subtotal=null)

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java (4)

22-66: 클래스 구조 및 문서화가 잘 되어 있습니다.

JavaDoc이 상세하고 의존성 주입이 올바르게 구현되었습니다. 이벤트 타입, Manual Ack 전략, CQRS 설계 원칙이 명확하게 문서화되어 있어 코드 이해에 도움이 됩니다.

139-143: 개별 레코드 처리 실패 시 데이터 손실 가능성을 고려하세요.

개별 이벤트 처리가 실패해도 로그만 남기고 계속 진행하며, 배치 전체는 커밋됩니다. 이는 "At Most Once" 시맨틱으로 실패한 이벤트는 영구적으로 손실됩니다. 랭킹 데이터의 특성상 일부 손실이 허용 가능하다면 현재 구조가 적절하지만, 다음을 고려해보세요:

Dead Letter Queue(DLQ)로 실패한 이벤트를 별도 토픽에 발행하여 추후 재처리

메트릭/알람을 통해 실패율 모니터링

현재 설계가 의도적이라면 JavaDoc에 데이터 손실 가능성을 명시하는 것이 좋습니다.

352-384: Order 및 Product 이벤트 파싱 로직이 올바르게 구현되었습니다.

타입 체크를 먼저 수행하여 불필요한 직렬화/역직렬화를 방지하고 있습니다. 이 패턴을 Like 이벤트 파싱에도 적용하면 일관성이 향상됩니다.

392-412: 헤더 추출 로직이 안전하게 구현되었습니다.

lastHeader()를 사용하고 null 체크를 수행하여 방어적으로 구현되었습니다.

apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingKeyGenerator.java

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/RankingConsumer.java

* feat: zset 모듈에 zunionstore 연산 처리 메소드 추가 * test: 랭킹 집계에 필요한 데이터 수집과 랭킹 계산 로직을 application event 기준으로 분리하도록 테스트 코드 수정 * feat: 랭킹 집계에 필요한 데이터 수집과 랭킹 계산 로직을 application event 기준으로 분리하도록 함

* test: 랭킹 조회 실패할 때의 테스트코드 추가 * feat: 랭킹 조회 실패시 전날 혹은 좋아요 순 데이터로 응답하도록 보완 * feat: 랭킹 fallback 전략 구현 * test: 랭킹 fallback 전략에 맞춰 테스트코드 수정 * refactor: 일자 단위 carry over 도입에 따라 unionstore 제거 * chore: 클래스명과 동일하게 파일 이름 변경 * refactor: 랭킹 이벤트 컨슈머에서 멱등성 체크 로직, 에러 처리 로직, 배치 커밋 로직 반복 제거 * refactor: 불필요한 stubbing 제거 * chore: 시간대 설정 추가

coderabbitai bot reviewed Dec 23, 2025

View reviewed changes

minor7295 added 2 commits December 26, 2025 02:04

minor7295 self-assigned this Dec 26, 2025

minor7295 marked this pull request as ready for review December 26, 2025 04:57

minor7295 changed the title ~~Feature/ranking (#37)~~ [volume - 9] What is Popularity? Dec 26, 2025

minor7295 merged commit f8db897 into Loopers-dev-lab:minor7295 Dec 28, 2025
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[volume - 9] What is Popularity? #210

[volume - 9] What is Popularity? #210

Uh oh!

minor7295 commented Dec 23, 2025 •

edited

Loading

Uh oh!

coderabbitai bot commented Dec 23, 2025 •

edited

Loading

Uh oh!

minor7295 commented Dec 23, 2025

Uh oh!

coderabbitai bot commented Dec 23, 2025

Uh oh!

coderabbitai bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

[volume - 9] What is Popularity? #210

[volume - 9] What is Popularity? #210

Uh oh!

Conversation

minor7295 commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📌 Summary

💬 Review Points

1. 랭킹은 도메인이 아닌 유스케이스로 판단

2. 외부 이벤트와 내부 이벤트 구분: Spring ApplicationEvent 사용

3. 콜드 스타트 문제 해결: Score Carry-Over 방식

4. 예외 처리: Graceful Degradation 전략

5. ZSET을 별도 모듈로 분리

✅ Checklist

Ranking Consumer

Ranking API

📎 References

Summary by CodeRabbit

릴리스 노트

Uh oh!

coderabbitai bot commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Possibly related PRs

Suggested labels

Poem

Pre-merge checks and finishing touches

Uh oh!

minor7295 commented Dec 23, 2025

Uh oh!

coderabbitai bot commented Dec 23, 2025

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

minor7295 commented Dec 23, 2025 •

edited

Loading

coderabbitai bot commented Dec 23, 2025 •

edited

Loading