[volume-9] Product Ranking with Redis

[rnqhstmd]

📌 Summary

• Redis ZSET을 활용한 실시간 랭킹 시스템 구현

💬 Review Points

• 가중치 실시간 변경을 위해 가중치 저장소를 yml이 아닌 Redis 적재를 선택해보았습니다.
• 가중치 관리 API를 commerce-streamer 모듈에 두었는데, 적절한지 궁금합니다.
• 콜드 스타트 해결을 위해 매일 23:50에 전날 점수의 10%를 다음날 키에 복사하는 스케쥴러를 추가했습니다. 그런데 만약 전날 랭킹 데이터가 없는 경우 별도 처리를 하는 로직은 없는데 필요할까요..?

✅ Checklist

📈 Ranking Consumer

• 랭킹 ZSET 의 TTL, 키 전략을 적절하게 구성하였다
• 날짜별로 적재할 키를 계산하는 기능을 만들었다
• 이벤트가 발생한 후, ZSET 에 점수가 적절하게 반영된다

⚾ Ranking API

• 랭킹 Page 조회 시 정상적으로 랭킹 정보가 반환된다
• 랭킹 Page 조회 시 단순히 상품 ID 가 아닌 상품정보가 Aggregation 되어 제공된다
• 상품 상세 조회 시 해당 상품의 순위가 함께 반환된다 (순위에 없다면 null)

Summary by CodeRabbit

Release Notes

• New Features
  • 상품 순위 시스템 추가 - 사용자 조회, 좋아요, 주문 데이터를 기반으로 매일 자동 계산
  • 상품 상세 정보에 현재 순위 표시
  • 순위 조회 API 추가 - 날짜별 전체 순위 목록 및 상위 상품 조회 지원
  • 관리자용 순위 가중치 설정 API - 각 이벤트의 가중치 조정 및 초기화 가능

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

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

상품 순위 시스템을 구현했습니다. commerce-api에서는 상품 상세 조회 시 Redis에서 당일 순위를 조회하여 응답에 포함하고, commerce-streamer에서는 조회/좋아요/주문 이벤트를 기반으로 정렬 집합에 점수를 누적합니다. 매일 밤 11:50에 점수를 다음 날로 이월하는 스케줄러를 통해 콜드 스타트를 지원합니다.

Changes

Cohort / File(s)	변경 사항
commerce-api - 상품 순위 도메인 모델 com/loopers/domain/ranking/RankingEntry.java, com/loopers/domain/ranking/RankingInfo.java, com/loopers/domain/ranking/RankingKey.java, com/loopers/domain/ranking/RankingService.java	순위 엔트리 레코드, 순위 정보 레코드, Redis 키 유틸리티, Redis 정렬 집합 기반 순위 조회 서비스 추가
commerce-api - 상품 순위 응용 계층 com/loopers/application/ranking/RankingCommand.java, com/loopers/application/ranking/RankingPageInfo.java, com/loopers/application/ranking/RankingFacade.java	페이징 파라미터 검증, 순위 페이지 응답, 상품 조회 및 순위 정보 매핑 로직 추가
commerce-api - 상품 통합 com/loopers/application/product/ProductDetailInfo.java, com/loopers/application/product/ProductFacade.java, com/loopers/interfaces/api/product/ProductV1ApiSpec.java, com/loopers/interfaces/api/product/ProductV1Controller.java, com/loopers/interfaces/api/product/ProductV1Dto.java	상품 상세 정보에 순위 필드 추가, ProductFacade에서 순위 조회 통합, 상품 API 인터페이스 및 컨트롤러 구현
commerce-api - 순위 API com/loopers/interfaces/api/ranking/RankingV1ApiSpec.java, com/loopers/interfaces/api/ranking/RankingV1Controller.java, com/loopers/interfaces/api/ranking/RankingV1Dto.java	순위 페이지 및 상위 N개 순위 조회 엔드포인트, 요청/응답 DTO 추가
commerce-api - 설정 com/loopers/support/config/ClockConfig.java	Clock 빈 구성 추가
commerce-api - 테스트 domain/ranking/RankingServiceTest.java, interfaces/api/ranking/RankingV1ApiE2ETest.java	Redis 정렬 집합 상호작용 단위 테스트, 순위 API 통합 테스트 추가
commerce-streamer - 순위 도메인 domain/ranking/RankingKey.java, domain/ranking/RankingService.java, domain/ranking/RankingWeight.java	Redis 키 생성 및 파싱 유틸리티, 점수 증감 서비스, 가중치 관리 컴포넌트 추가
commerce-streamer - 순위 응용 계층 application/ranking/RankingFacade.java, application/ranking/RankingScheduler.java, application/metrics/ProductMetricsFacade.java	이벤트 처리 및 점수 업데이트 파사드, 매일 밤 11:50 스케줄 이월, 메트릭 처리 시 순위 업데이트 통합
commerce-streamer - 순위 설정 API interfaces/api/ranking/RankingConfigV1ApiSpec.java, interfaces/api/ranking/RankingConfigV1Controller.java, interfaces/api/ranking/RankingConfigV1Dto.java	순위 가중치 조회/수정/리셋 관리자 엔드포인트 구현
commerce-streamer - 설정 src/main/resources/application.yml, CommerceStreamerApplication.java	애플리케이션명 변경 및 이월 가중치 설정, 스케줄링 활성화
commerce-streamer - 테스트 domain/ranking/RankingIntegrationTest.java, domain/ranking/RankingSchedulerTest.java, domain/ranking/RankingServiceTest.java, domain/ranking/RankingWeightTest.java, interfaces/ProductMetricsConsumerTest.java	점수 누적, TTL 동작, 이월 로직, 가중치 동적 관리 통합 테스트 및 단위 테스트 추가

Sequence Diagram(s)

sequenceDiagram
    autonumber
    actor Client
    participant API as ProductV1Controller
    participant PF as ProductFacade
    participant PRep as ProductRepository
    participant RF as RankingFacade
    participant RS as RankingService
    participant Redis
    
    Client->>API: GET /api/v1/products/{id}
    activate API
    API->>PF: getProductDetail(productId)
    activate PF
    
    PF->>PRep: findById(productId)
    activate PRep
    PRep-->>PF: Product
    deactivate PRep
    
    PF->>PF: 상품 정보 → ProductDetailInfo
    
    PF->>RF: getProductRankToday(productId)
    activate RF
    RF->>RS: getRank(productId, today)
    activate RS
    RS->>Redis: ZREVRANK key(today), productId
    Redis-->>RS: rank (1-based)
    RS-->>RF: rank
    deactivate RS
    RF-->>PF: rank
    deactivate RF
    
    PF->>PF: withRank(rank) 적용
    PF-->>API: ProductDetailInfo (rank 포함)
    deactivate PF
    
    API->>API: ProductV1Dto.ProductDetailResponse로 변환
    API-->>Client: ApiResponse (ProductDetailResponse)
    deactivate API

Loading

sequenceDiagram
    autonumber
    participant Kafka as Kafka Topics
    participant Consumer as ProductMetricsConsumer
    participant PMF as ProductMetricsFacade
    participant RF as RankingFacade
    participant RS as RankingService
    participant Redis
    
    Kafka->>Consumer: product-view-metrics
    activate Consumer
    Consumer->>PMF: processViewMetrics(command)
    activate PMF
    
    PMF->>PMF: 조회 메트릭 처리
    PMF->>RF: processViewEvent(productId)
    activate RF
    RF->>RS: incrementViewScore(productId, today)
    activate RS
    RS->>Redis: ZINCRBY key(today), viewScore, productId
    RS->>Redis: EXPIRE key(today), 48h
    Redis-->>RS: 성공
    RS-->>RF: 완료
    deactivate RS
    RF-->>PMF: 완료
    deactivate RF
    
    PMF-->>Consumer: 완료
    deactivate PMF
    Consumer->>Kafka: ack
    deactivate Consumer
    
    Note over Redis: 점수 누적 (view, like, order 모두 동일한 흐름)

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• PR #196: commerce-streamer의 ProductMetricsFacade 및 Kafka 메트릭 파이프라인을 도입했으며, 이번 PR에서 이 클래스들과 순위 시스템을 통합하기 때문에 코드 수준에서 직접 관련이 있습니다.

• PR #132: ProductFacade, ProductDetailInfo, ProductV1Controller/ProductV1Dto 등 상품 관련 클래스들을 처음 도입했으며, 이번 PR에서 이들 클래스에 순위 필드 및 조회 로직을 추가하기 때문에 관련이 있습니다.

• PR #147: ProductFacade를 수정하여 상품 목록 기능을 추가했으며, 이번 PR에서 동일한 ProductFacade 클래스에 순위 통합 로직을 추가하기 때문에 코드 수준에서 관련이 있습니다.

Poem

🐰 순위의 마법을 담아 ✨
Redis에 점수 쌓고 쌓고
밤 열한 시 반에는
내일을 위해 나눔을 나누고
상품도 우리도 순위를 맞이해
숫자로 세어진 인기와 사랑! 💚

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 21.62% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	제목이 변경 사항의 주요 기능(Redis를 활용한 상품 랭킹 시스템 구현)을 명확하게 설명하고 있으며, 간결하고 구체적입니다.
Description check	✅ Passed	PR 설명은 템플릿의 기본 섹션(Summary, Review Points, Checklist)을 모두 포함하고 있으며, 랭킹 시스템 구현 내용과 설계 고민이 충분히 설명되어 있습니다.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 14

🧹 Nitpick comments (22)

apps/commerce-streamer/src/main/java/com/loopers/domain/ranking/RankingKey.java (1)

21-32: 테스트 가능성을 위해 Clock 사용 권장

today()와 yesterday() 메서드가 LocalDate.now()를 직접 호출하여 단위 테스트가 어렵습니다. ClockConfig에서 제공하는 Clock 빈을 활용하거나, LocalDate를 파라미터로 받는 방식으로 리팩토링하는 것을 권장합니다.

🔎 권장 리팩토링

옵션 1: Clock을 파라미터로 받기

-    public static String today() {
-        return daily(LocalDate.now());
+    public static String today(Clock clock) {
+        return daily(LocalDate.now(clock));
     }
     
-    public static String yesterday() {
-        return daily(LocalDate.now().minusDays(1));
+    public static String yesterday(Clock clock) {
+        return daily(LocalDate.now(clock).minusDays(1));
     }

옵션 2: 이 메서드들을 제거하고 호출하는 쪽에서 daily(LocalDate.now(clock))를 직접 호출

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

16-27: 묵시적 검증 방식 재검토 권장

유효하지 않은 입력값을 자동으로 보정하고 있습니다. 이는 호출자의 버그를 숨길 수 있습니다. 다음 사항을 고려해주세요:

1. 잘못된 입력에 대해 예외를 던지거나
2. 최소한 경고 로그를 남기거나
3. 현재 방식을 유지하되 문서화

또한 LocalDate.now()를 직접 호출하여 테스트가 어렵습니다. Clock을 파라미터로 받는 것을 권장합니다.

🔎 개선 제안

옵션 1: 예외 던지기

     public RankingCommand {
-        if (page < 0) {
-            page = 0;
+        if (page < 0) {
+            throw new IllegalArgumentException("Page must be non-negative: " + page);
         }
-        if (size <= 0 || size > MAX_PAGE_SIZE) {
-            size = DEFAULT_PAGE_SIZE;
+        if (size <= 0 || size > MAX_PAGE_SIZE) {
+            throw new IllegalArgumentException("Size must be between 1 and " + MAX_PAGE_SIZE);
         }
         if (date == null) {
-            date = LocalDate.now();
+            throw new IllegalArgumentException("Date must not be null");
         }
     }

옵션 2: Clock 파라미터 추가

public RankingCommand {
    if (date == null) {
        throw new IllegalArgumentException("Use today() factory method instead of passing null date");
    }
    // ... validation
}

public static RankingCommand today(int page, int size, Clock clock) {
    return new RankingCommand(LocalDate.now(clock), page, size);
}

---

38-47: 파싱 실패 시 로깅 고려

parseDate 메서드가 파싱 실패 시 현재 날짜를 반환하여 오류를 숨깁니다. 디버깅을 위해 파싱 실패를 로깅하는 것을 고려해주세요.

🔎 로깅 추가 제안

+    private static final Logger log = LoggerFactory.getLogger(RankingCommand.class);
+
     private static LocalDate parseDate(String dateString) {
         if (dateString == null || dateString.isBlank()) {
             return LocalDate.now();
         }
         try {
             return LocalDate.parse(dateString, DATE_FORMATTER);
         } catch (DateTimeParseException e) {
+            log.warn("Failed to parse date string: {}, using current date", dateString, e);
             return LocalDate.now();
         }
     }

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingKey.java (1)

21-22: 테스트 가능성을 위해 Clock 사용 권장

today() 메서드가 LocalDate.now()를 직접 호출하여 단위 테스트가 어렵습니다. ClockConfig에서 제공하는 Clock 빈을 파라미터로 받거나, 호출하는 쪽에서 daily(LocalDate.now(clock))를 직접 사용하는 것을 권장합니다.

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

21-22: carryOverWeight 유효성 검증을 고려하세요.

carryOverWeight에 대한 범위 검증이 없습니다. 음수나 1.0을 초과하는 값이 설정되면 예상치 못한 동작이 발생할 수 있습니다. @Value 주입 후 @PostConstruct에서 범위를 검증하거나, @Validated와 @DecimalMin/@DecimalMax 어노테이션을 사용하는 것을 권장합니다.

🔎 권장 수정안

+import jakarta.annotation.PostConstruct;
+
 @Slf4j
 @Component
 @RequiredArgsConstructor
 public class RankingScheduler {
 
     private final RankingService rankingService;
     private final Clock clock;
 
     @Value("${ranking.carry-over.weight:0.1}")
     private double carryOverWeight;
+
+    @PostConstruct
+    public void validateConfiguration() {
+        if (carryOverWeight < 0.0 || carryOverWeight > 1.0) {
+            throw new IllegalArgumentException(
+                "ranking.carry-over.weight must be between 0.0 and 1.0, but was: " + carryOverWeight
+            );
+        }
+    }

apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1ApiSpec.java (2)

25-34: 파라미터 유효성 검증 어노테이션을 고려하세요.

page, size 파라미터에 @Min(0) 등의 유효성 검증 어노테이션을 추가하면 잘못된 요청을 조기에 차단할 수 있습니다. Controller 또는 Service 계층에서 검증하는 것도 가능하지만, API 스펙 레벨에서 명시하면 문서화 측면에서도 유리합니다.

---

45-51: 파라미터 유효성 검증 어노테이션을 고려하세요.

n 파라미터에 @Min(1) 등의 유효성 검증 어노테이션을 추가하면 음수나 0 값을 조기에 차단할 수 있습니다.

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

5-9: 가중치 파라미터에 유효성 검증을 추가하세요.

viewWeight, likeWeight, orderWeight에 대한 유효성 검증이 없습니다. 음수 값이나 비정상적으로 큰 값이 입력되면 랭킹 계산에 문제가 발생할 수 있습니다. @Min, @Max, @Positive 등의 Bean Validation 어노테이션을 추가하는 것을 권장합니다.

🔎 권장 수정안

+import jakarta.validation.constraints.PositiveOrZero;
+
 public class RankingConfigV1Dto {
 
     public record WeightConfigRequest(
+            @PositiveOrZero
             double viewWeight,
+            @PositiveOrZero
             double likeWeight,
+            @PositiveOrZero
             double orderWeight
     ) {}

apps/commerce-api/src/test/java/com/loopers/interfaces/api/ranking/RankingV1ApiE2ETest.java (1)

51-70: 테스트 시간 의존성 고려

LocalDate.now()를 직접 사용하면 자정 근처에서 테스트가 실패할 수 있습니다. ClockConfig가 PR에 포함되어 있으므로, 테스트에서도 고정된 Clock을 주입받아 사용하는 것을 권장합니다.

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

35-38: 입력 값 검증 추가 고려

WeightConfigRequest에 @Valid 어노테이션이 없습니다. 가중치 값의 범위 검증(예: 음수 불가, 합계가 1.0 등)이 필요할 수 있습니다.

🔎 제안하는 수정

     @PutMapping("/weights")
     RankingConfigV1Dto.WeightConfigResponse updateWeights(
-            @RequestBody RankingConfigV1Dto.WeightConfigRequest request
+            @Valid @RequestBody RankingConfigV1Dto.WeightConfigRequest request
     );

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java (1)

114-125: NumberFormatException 가능성

Long.parseLong(tuple.getValue())에서 Redis에 잘못된 데이터가 저장된 경우 NumberFormatException이 발생할 수 있습니다. 현재 상위 메서드의 catch 블록에서 처리되지만, 일부 유효한 엔트리가 손실될 수 있습니다.

🔎 제안하는 수정

     private List<RankingEntry> convertToRankingEntries(Set<ZSetOperations.TypedTuple<String>> tuples) {
         List<RankingEntry> entries = new ArrayList<>();
         for (ZSetOperations.TypedTuple<String> tuple : tuples) {
             if (tuple.getValue() != null && tuple.getScore() != null) {
-                entries.add(new RankingEntry(
-                        Long.parseLong(tuple.getValue()),
-                        tuple.getScore()
-                ));
+                try {
+                    entries.add(new RankingEntry(
+                            Long.parseLong(tuple.getValue()),
+                            tuple.getScore()
+                    ));
+                } catch (NumberFormatException e) {
+                    log.warn("Invalid productId in ranking: {}", tuple.getValue());
+                }
             }
         }
         return entries;
     }

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

56-70: 삭제된 상품 처리 시 순위 계산 불일치 가능성

productMap.get(entry.productId())가 null을 반환하면 해당 항목을 건너뛰지만, startRank + i는 여전히 증가합니다. 이로 인해 반환되는 순위에 빈 공간이 생겨 사용자에게 혼란을 줄 수 있습니다.

예: 1위 상품이 삭제된 경우, 결과가 2위부터 시작하게 됩니다.

🔎 수정 제안

         List<RankingInfo> rankings = new ArrayList<>();
-        long startRank = (long) command.page() * command.size() + 1;
+        long currentRank = (long) command.page() * command.size() + 1;
 
         for (int i = 0; i < entries.size(); i++) {
             RankingEntry entry = entries.get(i);
             Product product = productMap.get(entry.productId());
 
             if (product != null) {
                 rankings.add(RankingInfo.of(
                         product.getId(),
                         product.getName(),
                         product.getPriceValue(),
                         product.getBrand().getName(),
-                        startRank + i,
+                        currentRank++,
                         entry.score()
                 ));
+            } else {
+                log.warn("랭킹에 포함된 상품을 찾을 수 없음: productId={}", entry.productId());
             }
         }

---

101-116: getRankingPage와 동일한 null 상품 처리 문제 및 코드 중복

getTopN에서도 동일한 순위 계산 문제가 있습니다. 두 메서드의 매핑 로직을 별도 헬퍼 메서드로 추출하면 중복을 줄이고 일관성을 유지할 수 있습니다.

apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingWeightTest.java (1)

163-188: 개별 가중치 업데이트 메서드 테스트 누락

updateViewWeight, updateLikeWeight, updateOrderWeight 개별 메서드에 대한 테스트가 없습니다. updateAllWeights만 테스트하고 있어 개별 메서드의 동작을 검증하지 못합니다.

🔎 추가 테스트 제안

@Test
@DisplayName("개별 가중치를 업데이트한다")
void shouldUpdateIndividualWeight() {
    // when
    rankingWeight.updateViewWeight(0.15);

    // then
    verify(hashOperations).put(WEIGHT_KEY, "view", "0.15");
}

apps/commerce-streamer/src/main/java/com/loopers/domain/ranking/RankingWeight.java (2)

37-39: * 1.0 연산이 불필요함

getViewWeight() * 1.0은 getViewWeight()와 동일합니다. 다른 계산 메서드와의 일관성을 위해 의도적인 것일 수 있으나, 불필요한 연산입니다.

---

65-75: 가중치 값 검증 부재

가중치 업데이트 시 음수나 비정상적으로 큰 값에 대한 검증이 없습니다. 잘못된 가중치가 설정되면 랭킹 계산에 영향을 줄 수 있습니다.

🔎 검증 로직 추가 제안

     public void updateViewWeight(double weight) {
+        validateWeight(weight);
         updateWeight("view", weight);
     }
 
+    private void validateWeight(double weight) {
+        if (weight < 0 || weight > 1.0) {
+            throw new IllegalArgumentException("가중치는 0과 1 사이여야 합니다: " + weight);
+        }
+    }

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

110-123: 대용량 데이터에서 성능 저하 가능성

rangeWithScores(fromKey, 0, -1)로 모든 멤버를 조회하고, 개별 add() 호출로 복사합니다. 상품 수가 많아지면 네트워크 라운드트립이 증가하여 성능이 저하될 수 있습니다.

🔎 파이프라이닝 사용 제안

redisTemplate.executePipelined((RedisCallback<Object>) connection -> {
    for (ZSetOperations.TypedTuple<String> tuple : tuples) {
        if (tuple.getValue() != null && tuple.getScore() != null) {
            double newScore = tuple.getScore() * weight;
            connection.zSetCommands().zAdd(
                toKey.getBytes(), 
                newScore, 
                tuple.getValue().getBytes()
            );
        }
    }
    return null;
});

---

16-21: 선택적 리뷰 - 아키텍처 설계 재검토 필요

이 프로젝트는 두 개의 별도 RankingService를 가진 멀티 모듈 구조입니다:

• commerce-api: getTopNWithScores, getRankingPage, getRank, getScore 등 쿼리 메서드 포함
• commerce-streamer: incrementViewScore, carryOverScores 등 쓰기 작업만 포함

제공된 코드(commerce-streamer)에 쿼리 메서드가 없는 것은 설계에 따른 것입니다. commerce-api의 RankingFacade는 commerce-api의 RankingService를 호출하므로, 메서드 누락이 아니라 모듈 간 역할 분담입니다. 다만 이러한 분리 구조가 의도된 설계인지 확인이 필요합니다.

apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingIntegrationTest.java (4)

56-62: 느슨한 단언문(assertion)으로 인해 계산 버그를 놓칠 수 있습니다.

현재 isGreaterThanOrEqualTo(0.4) 단언은 실제 예상값인 정확히 0.4를 검증하지 않습니다. 가중치가 정해져 있다면(view=0.1, like=0.2), 부동소수점 비교를 위해 isCloseTo를 사용하는 것이 더 정확합니다.

🔎 제안된 수정

-            assertThat(score).isGreaterThanOrEqualTo(0.4);
+            assertThat(score).isCloseTo(0.4, org.assertj.core.api.Assertions.within(0.01));

---

98-102: TTL 유효 범위 검증을 권장합니다.

현재 TTL이 0보다 크다는 것만 확인합니다. 설정된 TTL 값(예: 2일)이 올바르게 적용되었는지 범위 검증을 추가하면 설정 오류를 조기에 발견할 수 있습니다.

🔎 제안된 수정 예시

             Long ttl = redisTemplate.getExpire(key);
             assertThat(ttl).isNotNull();
-            assertThat(ttl).isGreaterThan(0);
+            // 예상 TTL이 2일(172800초)인 경우
+            assertThat(ttl).isGreaterThan(0);
+            assertThat(ttl).isLessThanOrEqualTo(172800L); // 최대 2일

---

174-177: 부동소수점 비교에 isCloseTo 사용을 권장합니다.

isEqualTo를 사용한 double 비교는 부동소수점 정밀도 문제로 인해 불안정할 수 있습니다. 다른 테스트(line 131)와 일관성을 위해 isCloseTo를 사용하는 것이 좋습니다.

🔎 제안된 수정

-            assertThat(rankingWeight.getViewWeight()).isEqualTo(newViewWeight);
-            assertThat(rankingWeight.getLikeWeight()).isEqualTo(newLikeWeight);
-            assertThat(rankingWeight.getOrderWeight()).isEqualTo(newOrderWeight);
+            assertThat(rankingWeight.getViewWeight()).isCloseTo(newViewWeight, within(0.001));
+            assertThat(rankingWeight.getLikeWeight()).isCloseTo(newLikeWeight, within(0.001));
+            assertThat(rankingWeight.getOrderWeight()).isCloseTo(newOrderWeight, within(0.001));

within을 사용하려면 static import를 추가하세요:

import static org.assertj.core.api.Assertions.within;

---

189-193: 기본값 상수화를 고려해 주세요.

테스트에 하드코딩된 기본값(0.1, 0.2, 0.7)이 RankingWeight 구현체의 실제 기본값과 동기화되어야 합니다. 기본값이 변경되면 테스트가 실패하므로, 상수를 공유하거나 RankingWeight에서 기본값을 제공하는 메서드를 사용하는 것이 유지보수에 유리합니다.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e7bf613 and fd11c00.

📒 Files selected for processing (34)

• apps/commerce-api/src/main/java/com/loopers/application/product/ProductDetailInfo.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingCommand.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingPageInfo.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingEntry.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingInfo.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingKey.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1ApiSpec.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Controller.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Dto.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1ApiSpec.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/main/java/com/loopers/support/config/ClockConfig.java
• apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingServiceTest.java
• apps/commerce-api/src/test/java/com/loopers/interfaces/api/ranking/RankingV1ApiE2ETest.java
• apps/commerce-streamer/src/main/java/com/loopers/CommerceStreamerApplication.java
• apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java
• apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingFacade.java
• apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingScheduler.java
• apps/commerce-streamer/src/main/java/com/loopers/domain/ranking/RankingKey.java
• apps/commerce-streamer/src/main/java/com/loopers/domain/ranking/RankingService.java
• apps/commerce-streamer/src/main/java/com/loopers/domain/ranking/RankingWeight.java
• apps/commerce-streamer/src/main/java/com/loopers/interfaces/api/ranking/RankingConfigV1ApiSpec.java
• apps/commerce-streamer/src/main/java/com/loopers/interfaces/api/ranking/RankingConfigV1Controller.java
• apps/commerce-streamer/src/main/java/com/loopers/interfaces/api/ranking/RankingConfigV1Dto.java
• apps/commerce-streamer/src/main/resources/application.yml
• apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingIntegrationTest.java
• apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingSchedulerTest.java
• apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingServiceTest.java
• apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingWeightTest.java
• apps/commerce-streamer/src/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.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-22T16:33:50.678Z

Learnt from: jikimee64
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 71
File: apps/commerce-streamer/src/main/kotlin/com/loopers/application/ranking/RankingFacade.kt:167-173
Timestamp: 2025-12-22T16:33:50.678Z
Learning: In the Loopers-dev-lab/loopers-spring-kotlin-template repository, using system default timezone (ZonedDateTime.now() without explicit ZoneId) in date key calculations is an intentional design choice. The deployment ensures all instances share the same timezone configuration.

Applied to files:

• apps/commerce-api/src/main/java/com/loopers/support/config/ClockConfig.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/product/ProductFacade.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/product/ProductFacade.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1ApiSpec.java

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

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:57.713Z
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/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.java

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

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:54.339Z
Learning: In this codebase, Kafka consumers delegate error handling and event tracking to the service layer via EventInboxAspect. Service methods annotated with InboxEvent are intercepted by the aspect, which handles failures by saving failed EventInbox entries and logging errors. This centralized approach avoids duplicating error handling logic across multiple consumers.

Applied to files:

• apps/commerce-streamer/src/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.java

📚 Learning: 2025-12-19T23:39:20.851Z

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: apps/commerce-streamer/src/main/kotlin/com/loopers/interfaces/consumer/product/ProductEventConsumer.kt:0-0
Timestamp: 2025-12-19T23:39:20.851Z
Learning: In Loopers-dev-lab/loopers-spring-kotlin-template, toongri prefers pragmatic idempotency handling in Kafka consumers: when idempotency key persistence fails after successful business logic execution, log a warning and continue (accepting low risk of duplicates on retry) rather than rolling back business data. This keeps business logic decoupled from idempotency store (which might be Redis/external system, not RDB), avoids over-engineering for rare edge cases, and prioritizes core business value over auxiliary metadata. Transaction-based atomicity between business data and idempotency keys is considered excessive when duplicate event probability is very low.

Applied to files:

• apps/commerce-streamer/src/test/java/com/loopers/interfaces/ProductMetricsConsumerTest.java

🧬 Code graph analysis (2)

apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Controller.java (1)

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

• ProductV1Dto (8-75)

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

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

• RankingConfigV1Dto (3-20)

🔇 Additional comments (35)

apps/commerce-streamer/src/main/java/com/loopers/CommerceStreamerApplication.java (1)

7-7: @EnableScheduling 활성화는 안전합니다—carryOverScores가 멱등성을 제공합니다.

RankingScheduler의 carryOverScores 메서드는 이미 준비된 랭킹 데이터가 존재하면 조기에 반환하도록 설계되어 있습니다(line 104-108). 다중 인스턴스 환경에서 첫 번째 인스턴스가 실행되어 데이터를 준비하면, 이후 인스턴스들은 데이터 존재 여부를 확인하고 작업을 건너뜁니다. 따라서 중복 실행에 대한 우려는 제거되며, 분산 락이 필요하지 않습니다.

Likely an incorrect or invalid review comment.

apps/commerce-streamer/src/main/resources/application.yml (1)

17-17: 애플리케이션 이름 수정 확인

모듈 이름과 일치하도록 commerce-streamer로 올바르게 수정되었습니다.

apps/commerce-api/src/main/java/com/loopers/application/product/ProductDetailInfo.java (3)

14-16: rank 필드 추가 확인

순위 정보를 담는 rank 필드가 올바르게 추가되었습니다. nullable Long 타입을 사용하여 순위가 없는 경우 null로 표현할 수 있습니다.

---

17-41: 팩토리 메서드 구현 확인

기존 of 메서드를 유지하면서 rank를 null로 설정하고, 새로운 오버로드 메서드를 추가하여 하위 호환성과 확장성을 모두 확보했습니다.

---

43-54: withRank 메서드 구현 확인

불변 레코드 패턴을 따라 새 인스턴스를 생성하는 withRank 메서드가 올바르게 구현되었습니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingEntry.java (1)

1-7: LGTM!

Redis ZSET 엔트리를 표현하는 간단하고 명확한 도메인 레코드입니다.

apps/commerce-api/src/main/java/com/loopers/support/config/ClockConfig.java (1)

1-15: Clock 빈 설정 확인

Clock.systemDefaultZone()을 사용하여 시스템 기본 타임존으로 Clock 빈을 제공합니다. 학습된 내용에 따르면 모든 인스턴스가 동일한 타임존 설정을 공유하도록 배포 환경이 구성되어 있어 이 설정이 적절합니다. 이 빈을 활용하여 다른 컴포넌트들의 테스트 가능성을 개선할 수 있습니다.

Based on learnings, the deployment ensures all instances share the same timezone configuration.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingInfo.java (1)

1-21: 순위 정보 레코드 구현 확인

상품 순위 정보를 담는 RankingInfo 레코드가 잘 구현되었습니다. of 팩토리 메서드는 단순히 생성자를 호출하지만, API 일관성을 위한 패턴으로 적절합니다.

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

1-75: LGTM!

DTO 구조가 명확하고, ProductDetailResponse의 rank 필드가 nullable Long 타입으로 선언되어 순위가 없을 때 null을 반환하는 PR 목표와 일치합니다. 매핑 로직도 간결합니다.

apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingSchedulerTest.java (1)

1-71: LGTM!

스케줄러 테스트가 잘 작성되었습니다. 고정된 시계를 사용하여 날짜 계산을 검증하고, 예외 발생 시에도 정상 종료되는지 확인합니다.

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

198-222: LGTM!

랭킹 업데이트 테스트가 적절하게 작성되었습니다. processViewMetrics 호출과 productId 검증이 정확합니다.

---

224-243: LGTM!

잘못된 JSON 메시지를 건너뛰고 다음 메시지를 정상 처리하는 로직을 잘 검증하고 있습니다.

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

28-42: LGTM!

스케줄러 로직이 명확하게 구현되었습니다. 명시적으로 today/tomorrow를 계산하고, 예외 처리도 적절합니다. Clock 주입을 통한 테스트 가능성도 우수합니다.

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

1-203: LGTM!

테스트 커버리지가 우수합니다. 정상 케이스, 엣지 케이스(TTL 설정, 이미 준비된 랭킹), 양수/음수 점수 처리 등을 모두 검증하고 있습니다. 중첩 클래스로 테스트를 그룹화한 구조도 가독성이 좋습니다.

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

16-18: LGTM!

정적 팩토리 메서드가 간단하고 명확합니다.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Controller.java (2)

20-35: LGTM!

getProducts 메서드 구현이 깔끔합니다. ProductGetListCommand를 통한 커맨드 패턴 사용과 DTO 변환이 적절합니다.

---

37-48: LGTM!

userId null/blank 체크 로직이 올바르게 구현되어 있습니다. 로그인/비로그인 사용자 분기 처리가 명확합니다.

apps/commerce-api/src/test/java/com/loopers/interfaces/api/ranking/RankingV1ApiE2ETest.java (1)

186-210: LGTM!

Top-N 랭킹 조회 테스트가 적절하게 구현되어 있습니다.

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

25-30: LGTM!

RankingCommand.of()를 통한 커맨드 생성이 간결합니다. 날짜/페이지 파싱 로직이 커맨드 내부에서 처리되는 것으로 보입니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java (1)

25-41: LGTM!

Top-N 조회 로직이 적절합니다. 예외 발생 시 빈 리스트를 반환하는 graceful degradation 패턴이 잘 적용되어 있습니다.

apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingServiceTest.java (2)

22-37: LGTM!

테스트 셋업이 깔끔합니다. RedisTemplate과 ZSetOperations 모킹이 올바르게 구성되어 있습니다.

---

222-233: LGTM!

TypedTuple 헬퍼 메서드가 테스트 가독성을 높여줍니다.

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

27-29: LGTM!

empty() 팩토리 메서드가 빈 결과에 대한 적절한 기본값을 제공합니다.

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

8-22: LGTM!

컨트롤러 구현이 깔끔합니다. RankingWeight 도메인 서비스에 위임하는 패턴이 적절합니다.

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

121-133: LGTM!

Clock 주입을 통해 테스트 용이성을 확보한 좋은 설계입니다.

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

10-71: LGTM!

DTO 구조가 깔끔하고, DateTimeFormatter를 static final로 선언하여 스레드 안전성을 확보했습니다. Factory 메서드를 통한 매핑 패턴도 적절합니다.

apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingWeightTest.java (1)

1-35: LGTM!

테스트 구조가 @Nested 클래스로 잘 정리되어 있고, Redis 예외 처리 및 기본값 폴백 시나리오를 적절히 검증하고 있습니다.

apps/commerce-streamer/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java (2)

65-68: LGTM!

재고 감소(DECREASED) 시에만 주문 이벤트를 랭킹에 반영하는 로직이 올바릅니다.

---

46-49: 랭킹 업데이트는 이미 트랜잭션 영향을 고려한 설계입니다

RankingService.incrementScore() 메서드에서 모든 예외가 캐치되어 로그만 기록하고 재발생되지 않습니다. 따라서 랭킹 업데이트 실패 시 메트릭 저장 트랜잭션이 롤백되지 않으므로 추가 수정이 불필요합니다.

Likely an incorrect or invalid review comment.

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

15-22: LGTM!

Clock 주입으로 테스트 용이성을 확보했고, 단일 책임 원칙을 잘 따르는 깔끔한 Facade 설계입니다.

---

27-49: RankingService의 예외 처리 확인됨

검증 결과, RankingService는 내부적으로 모든 점수 업데이트 작업(incrementScore 메서드, 62-77줄)에 대해 예외를 처리합니다. 발생한 예외는 로깅되고 재발생하지 않으므로, ProductMetricsFacade의 트랜잭션에 영향을 주지 않습니다. 따라서 RankingFacade에서 추가 예외 처리는 불필요합니다.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1ApiSpec.java (1)

15-62: LGTM!

OpenAPI 명세가 잘 정의되어 있고, 한글 설명이 포함되어 있습니다. 랭킹 정보가 상품 상세 조회에 포함된다는 점이 문서화되어 있습니다.

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

80-93: LGTM!

getRankingSize 메서드의 예외 처리가 적절하며, null 체크와 기본값 반환이 잘 되어 있습니다.

apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingIntegrationTest.java (2)

13-39: LGTM!

테스트 설정이 잘 구성되어 있습니다. @BeforeEach로 각 테스트 전 Redis를 정리하여 테스트 격리를 보장하고, 고정된 testDate를 사용하여 재현 가능한 테스트를 구현했습니다.

---

105-157: LGTM!

Carry-over 테스트가 잘 구현되어 있습니다. 특히 line 131에서 부동소수점 비교에 isCloseTo를 사용한 점과, 기존 데이터를 덮어쓰지 않는 동작을 검증하는 테스트가 좋습니다.