[volume-9] Product Ranking with Redis

[yeonsu00]

📌 Summary

• 컨슈머에서 상품 일별 랭킹 집계
  • Redis ZSET TTL, 키 전략 구성
  • 콜드 스타트 문제 해결
• 랭킹 Page 조회
• 상품 상세 조회 시 랭킹 반환

---

💬 Review Points

1. product_metrics의 용도

현재 구현에서는 Kafka 이벤트(좋아요 등록, 조회수, 주문 생성)를 수신하면

• Redis ZSET에 즉시 점수를 반영하고
• product_metrics 테이블에도 업데이트합니다.

데이터 흐름:

Kafka 이벤트 발생 (예: ProductLiked)
    ↓
MetricsConsumer.handleProductLikedEvents()
    ↓
    ├─→ rankingService.incrementScore(productId, LIKE)
    │   └─→ Redis ZSET에 점수 추가 
    │
    └─→ productMetricsService.incrementLikeCount(productId)
        └─→ ProductMetrics 테이블: productId의 likeCount 컬럼 +1
            (랭킹 계산과 무관)

prodcut_metrics는 현재 누적 데이터만 저장하는 구조인데, 일별 랭킹을 위한 일별 변화량을 추적하려면 product_metrics 테이블에 저장 날짜 컬럼을 추가해야 할까요?

---

2. 동일 점수 처리 방식

레디스 zset에서 점수가 동일하면 멤버의 사전식 순서로 정렬되는 것 같습니다.

Redis ZSET 상태:
- 상품 1: 10점
- 상품 2: 10점  (동일 점수)
- 상품 3: 5점

현재 동작:
1위: 상품 1 (10점, rank=1)
2위: 상품 2 (10점, rank=2)  ← 동일 점수인데도 다른 순위
3위: 상품 3 (5점, rank=3)

실무에서는 동일 점수인 경우 어떤 비즈니스 로직으로 처리하는 것이 일반적인가요?

---

3. 비동기 콜백에서 트랜잭션 관리

지난 주 과제 리팩토링을 하면서 OutService의 이벤트 발행 로직을 비동기 방식에서 동기 방식으로 변경했습니다.

변경 전:

public void publishPendingOutboxes(int batchSize) {
    List<Outbox> pendingOutboxes = outboxRepository.findPendingOutboxes(batchSize);
    
    for (Outbox outbox : pendingOutboxes) {
        kafkaTemplate
                .send(
                        outbox.getTopic(),
                        outbox.getPartitionKey(),
                        outbox.getPayload()
                )
                .whenComplete((result, exception) -> {
                    // 비동기 콜백에서 DB 업데이트 시도
                    if (exception == null) {
                        outboxRepository.markAsPublished(outbox.getId());
                    } else {
                        outboxRepository.markAsFailed(outbox.getId(), exception.getMessage());
                    }
                });
    }
}

변경 후:

public void publishPendingOutboxes(int batchSize) {
        List<Outbox> pendingOutboxes = outboxRepository.findPendingOutboxes(batchSize);
        
        for (Outbox outbox : pendingOutboxes) {
            try {
                // .get()으로 동기 처리로 변경
                kafkaTemplate.send(
                    outbox.getTopic(),
                    outbox.getPartitionKey(),
                    outbox.getPayload()
                ).get();  // CompletableFuture.get() - 블로킹 호출로 변경
                
                outboxRepository.markAsPublished(outbox.getId());
            } catch (Exception e) {
                outboxRepository.markAsFailed(outbox.getId(), e.getMessage());
            }
        }
    }

whenComplete 콜백은 비동기로 실행되므로 outboxRepository.markAsPublished()와 markAsFailed() 호출이 트랜잭션 밖에서 실행될 수 있어서, 동기 방식으로 변경해줬습니다.

비동기 방식을 계속 사용하려면 트랜잭션 관리를 해줘야 하는데, 같은 클래스 내에서 트랜잭션 관리를 위해 별도의 Manager를 사용하는 방식이 실무에서 많이 사용하는 방식인가요? 아니면 지양하는 방식인가요?

---

✅ Checklist

📈 Ranking Consumer

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

⚾ Ranking API

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

Summary by CodeRabbit

릴리스 노트

• 새로운 기능
  • 제품에 순위 정보 추가됨
  • 일일 제품 순위 조회 API 추가 (날짜, 페이지네이션 지원)
  • 주문 시 상품 상세 정보가 함께 기록됨
  • Redis 기반 순위 캐싱 시스템 구현으로 빠른 순위 조회 제공

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

[coderabbitai]

Walkthrough

순위 관리 기능을 추가하여 Redis 캐시 기반의 일일 제품 순위 조회 및 갱신을 지원합니다. 제품 조회 시 순위 정보를 포함하도록 통합하고, 이벤트 기반 점수 누적 및 자동 이월 기능을 제공합니다.

Changes

Cohort / File(s)	Summary
Ranking Domain Layer apps/commerce-api/src/main/java/com/loopers/domain/ranking/Ranking.java, RankingItem.java, RankingService.java	순위 관련 도메인 모델(Ranking, RankingItem) 및 서비스 클래스 신규 추가. RankingService는 페이징을 적용하여 날짜별 순위 목록을 조회합니다.
Ranking Cache Infrastructure apps/commerce-api/src/main/java/com/loopers/infrastructure/cache/RankingCacheService.java	Redis ZSET을 활용하여 순위 데이터를 저장/조회하는 캐시 서비스 신규 추가. getRankingRange 및 getProductRank 메서드 제공.
Ranking Application Layer apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingCommand.java, RankingInfo.java, RankingFacade.java	순위 조회 명령(GetDailyRankingCommand), 응답(RankingInfo), 파사드(RankingFacade) 클래스 신규 추가.
Ranking API Layer apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1ApiSpec.java, RankingV1Controller.java, RankingV1Dto.java	REST API 엔드포인트(/api/v1/rankings) 및 DTO 신규 추가. OpenAPI 명세 정의 및 컨트롤러 구현.
Product Integration apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java, ProductInfo.java	ProductInfo에 순위 필드 추가, ProductFacade에서 RankingCacheService를 통해 순위 조회. ProductRepositoryImpl, ProductJpaRepository에 findProductsByIds 메서드 추가.
Product DTO Update apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Dto.java	ProductResponse에 순위 필드 추가 및 팩토리 메서드 업데이트.
Order Event Enhancements apps/commerce-api/src/main/java/com/loopers/application/order/OrderEvent.java, KafkaOutboxEventListener.java	OrderCreated 레코드에 orderItems 필드 추가. KafkaOutboxEventListener에서 이벤트 매핑 시 orderItems 전달.
Kafka Event Update modules/kafka/src/main/java/com/loopers/application/kafka/KafkaEvent.java	KafkaEvent.OrderEvent.OrderCreated에 orderItems 필드 추가 및 팩토리 메서드 업데이트.
Brand Domain apps/commerce-api/src/main/java/com/loopers/domain/brand/Brand.java	무인자 생성자 및 빌더 기반 생성자, createBrand 팩토리 메서드 추가.
Commerce Streamer Ranking Service apps/commerce-streamer/src/main/java/com/loopers/domain/ranking/RankingService.java, RankingWeight.java	Redis 기반 순위 점수 증가 및 이월 기능 제공. RankingWeight 열거형으로 가중치 관리.
Commerce Streamer Integration apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/MetricsConsumer.java, scheduler/RankingScoreCarryOverScheduler.java, CommerceStreamerApplication.java	이벤트 핸들러에서 순위 점수 갱신, 일일 자동 이월 스케줄러 추가. @EnableScheduling 적용.
Integration Tests apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingFacadeIntegrationTest.java, domain/ranking/RankingServiceIntegrationTest.java, infrastructure/cache/RankingCacheServiceIntegrationTest.java, interfaces/api/ranking/RankingV1ApiE2ETest.java, product/ProductFacadeIntegrationTest.java, infrastructure/cache/ProductCacheServiceIntegrationTest.java	순위 기능 및 제품 통합에 대한 단위/통합/E2E 테스트 추가.
Commerce Streamer Tests apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingServiceIntegrationTest.java	순위 점수 증가/이월 로직에 대한 통합 테스트 추가.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant RankingV1Controller
    participant RankingFacade
    participant RankingService
    participant RankingCacheService
    participant Redis
    participant ProductService
    participant Database
    participant BrandService

    Client->>RankingV1Controller: GET /api/v1/rankings?date=yyyyMMdd&page=1&size=20
    
    activate RankingV1Controller
    RankingV1Controller->>RankingFacade: getDailyRanking(GetDailyRankingCommand)
    deactivate RankingV1Controller

    activate RankingFacade
    RankingFacade->>RankingService: getRanking(date, page, size)
    
    activate RankingService
    RankingService->>RankingCacheService: getRankingRange(date, start, end)
    deactivate RankingService
    
    activate RankingCacheService
    RankingCacheService->>Redis: ZREVRANGE ranking:all:yyyyMMdd (with scores)
    activate Redis
    Redis-->>RankingCacheService: List[RankingItem]
    deactivate Redis
    RankingCacheService-->>RankingFacade: List[Ranking]
    deactivate RankingCacheService
    
    rect rgb(200, 220, 240)
        note over RankingFacade: 상품 데이터 조회 및 보강
        RankingFacade->>ProductService: findProductsByIds(productIds)
        activate ProductService
        ProductService->>Database: Query Product entities
        activate Database
        Database-->>ProductService: List[Product]
        deactivate Database
        ProductService-->>RankingFacade: List[Product]
        deactivate ProductService
        
        RankingFacade->>BrandService: Brand name lookup
        activate BrandService
        BrandService->>Database: Query Brand entities
        activate Database
        Database-->>BrandService: Brand data
        deactivate Database
        BrandService-->>RankingFacade: Brand names
        deactivate BrandService
    end
    
    RankingFacade-->>RankingV1Controller: RankingInfo (enriched with product details)
    deactivate RankingFacade
    
    activate RankingV1Controller
    RankingV1Controller->>RankingV1Controller: Convert to DailyRankingListResponse
    RankingV1Controller-->>Client: ApiResponse<DailyRankingListResponse> (HTTP 200)
    deactivate RankingV1Controller

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 분

Possibly related PRs

• [volume - 8] Decoupling with Kafka  #205: OrderCreated 레코드에 orderItems 필드를 추가하고 팩토리 메서드를 업데이트하는 동일한 변경이 포함되어 있습니다.
• [volume - 8] Decoupling with Kafka #196: Kafka 이벤트 페이로드 수정 및 commerce-streamer 메트릭/순위 소비자 추가 등 스트리밍 계층의 동일한 변경사항을 포함합니다.
• [volume-5] 인덱스 및 Redis 캐시 적용 #140: ProductFacade 및 ProductInfo 변경으로 제품 API 계층의 동일한 코드를 수정합니다.

Suggested labels

enhancement

Poem

🐰 순위를 담은 Redis 저장소,
상품 별 점수 매기고 담네.
이벤트마다 쌓이는 점수,
밤 열시 오십분 이월하며,
사용자들 눈길 사로잡을 순위 🏆

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% 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	PR 제목은 '[volume-9] Product Ranking with Redis'로, 핵심 변경사항인 Redis를 기반으로 한 상품 랭킹 기능을 명확하게 요약합니다.
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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (7)

apps/commerce-api/src/main/java/com/loopers/interfaces/listener/KafkaOutboxEventListener.java (1)

25-32: 중복 매핑 로직을 헬퍼 메서드로 추출하는 것을 고려하세요.

handleOrderCreated의 lines 25-32와 handleOrderPaid의 lines 47-54에서 동일한 매핑 로직이 반복됩니다. 유지보수성 향상을 위해 공통 헬퍼 메서드로 추출할 수 있습니다.

🔎 중복 제거를 위한 헬퍼 메서드 제안

+    private List<KafkaEvent.OrderEvent.OrderItemInfo> mapToKafkaOrderItemInfos(
+            List<OrderEvent.OrderItemInfo> orderItems) {
+        return orderItems.stream()
+                .map(item -> new KafkaEvent.OrderEvent.OrderItemInfo(
+                        item.productId(),
+                        item.productName(),
+                        item.price(),
+                        item.quantity()
+                ))
+                .toList();
+    }
+
     @TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
     public void handleOrderCreated(OrderEvent.OrderCreated event) {
-        List<KafkaEvent.OrderEvent.OrderItemInfo> orderItemInfos = event.orderItems().stream()
-                .map(item -> new KafkaEvent.OrderEvent.OrderItemInfo(
-                        item.productId(),
-                        item.productName(),
-                        item.price(),
-                        item.quantity()
-                ))
-                .toList();
+        List<KafkaEvent.OrderEvent.OrderItemInfo> orderItemInfos = 
+                mapToKafkaOrderItemInfos(event.orderItems());
         
         KafkaEvent.OrderEvent.OrderCreated kafkaEvent = KafkaEvent.OrderEvent.OrderCreated.from(
                 event.orderKey(),
                 event.userId(),
                 event.orderId(),
                 event.originalTotalPrice(),
                 event.discountPrice(),
                 orderItemInfos
         );
         outboxService.saveOutbox("order-created-events", event.orderKey(), kafkaEvent);
     }

     @TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
     public void handleOrderPaid(OrderEvent.OrderPaid event) {
-        List<KafkaEvent.OrderEvent.OrderItemInfo> orderItemInfos = event.orderItems().stream()
-                .map(item -> new KafkaEvent.OrderEvent.OrderItemInfo(
-                        item.productId(),
-                        item.productName(),
-                        item.price(),
-                        item.quantity()
-                ))
-                .toList();
+        List<KafkaEvent.OrderEvent.OrderItemInfo> orderItemInfos = 
+                mapToKafkaOrderItemInfos(event.orderItems());
         
         KafkaEvent.OrderEvent.OrderPaid kafkaEvent = KafkaEvent.OrderEvent.OrderPaid.from(
                 event.orderKey(),
                 event.userId(),
                 event.orderId(),
                 event.totalPrice(),
                 orderItemInfos
         );
         outboxService.saveOutbox("order-paid-events", event.orderKey(), kafkaEvent);
     }

Also applies to: 39-40

apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java (2)

62-87: 순위 통합 로직 확인 완료, 리팩토링 제안

RankingCacheService를 통한 순위 조회 및 ProductInfo 보강 로직이 올바르게 구현되었습니다. Null 처리도 적절합니다.

현재 구현에서는 순위가 있을 때 ProductInfo의 모든 필드를 수동으로 복사하여 새 인스턴스를 생성하고 있습니다. 가독성과 유지보수성 향상을 위해 다음 리팩토링을 고려해보세요:

🔎 제안하는 리팩토링

옵션 1: ProductInfo에 팩토리 메서드 추가

ProductInfo 클래스에 다음 메서드를 추가:

public ProductInfo withRank(Long rank) {
    return new ProductInfo(
        this.id, this.name, this.brandId, this.brandName,
        this.price, this.likeCount, this.stock, this.createdAt, rank
    );
}

그러면 ProductFacade에서:

-        if (rank != null) {
-            return new ProductInfo(
-                    productInfo.id(),
-                    productInfo.name(),
-                    productInfo.brandId(),
-                    productInfo.brandName(),
-                    productInfo.price(),
-                    productInfo.likeCount(),
-                    productInfo.stock(),
-                    productInfo.createdAt(),
-                    rank
-            );
-        }
-
-        return productInfo;
+        return rank != null ? productInfo.withRank(rank) : productInfo;

옵션 2 (더 간단): 삼항 연산자로 간소화

         Long rank = rankingCacheService.getProductRank(LocalDate.now(), productId);
-
-        if (rank != null) {
-            return new ProductInfo(
-                    productInfo.id(),
-                    productInfo.name(),
-                    productInfo.brandId(),
-                    productInfo.brandName(),
-                    productInfo.price(),
-                    productInfo.likeCount(),
-                    productInfo.stock(),
-                    productInfo.createdAt(),
-                    rank
-            );
-        }
-
-        return productInfo;
+        return rank != null 
+            ? new ProductInfo(productInfo.id(), productInfo.name(), productInfo.brandId(), 
+                productInfo.brandName(), productInfo.price(), productInfo.likeCount(), 
+                productInfo.stock(), productInfo.createdAt(), rank)
+            : productInfo;

---

70-70: LocalDate.now() 사용 확인

일일 순위 조회를 위해 LocalDate.now()를 사용하고 있습니다. 이는 현재 날짜 기준 순위를 조회하는 의도에 부합합니다. 다만, 테스트 가능성과 시간대 관련 이슈를 고려한다면 Clock 주입을 통해 날짜를 제어할 수 있도록 하는 것도 검토해볼 수 있습니다.

🔎 선택적 개선 사항

테스트 용이성을 위해 Clock을 주입받는 패턴:

 @RequiredArgsConstructor
 @Component
 public class ProductFacade {
 
     private final ProductService productService;
     private final BrandService brandService;
     private final ProductCacheService productCacheService;
     private final RankingCacheService rankingCacheService;
+    private final Clock clock;
 
     public ProductInfo getProduct(Long productId) {
         ProductInfo productInfo = productCacheService.getProduct(productId, () -> {
             Product product = productService.findProductById(productId)
                     .orElseThrow(() -> new CoreException(ErrorType.NOT_FOUND, "상품을 찾을 수 없습니다."));
             String brandName = brandService.findBrandNameById(product.getBrandId());
             return ProductInfo.from(product, brandName);
         });
 
-        Long rank = rankingCacheService.getProductRank(LocalDate.now(), productId);
+        Long rank = rankingCacheService.getProductRank(LocalDate.now(clock), productId);
         
         // ...
     }
 }

Config 클래스에서 Bean 등록:

@Bean
public Clock clock() {
    return Clock.systemDefaultZone();
}

이렇게 하면 테스트에서 고정된 시간을 주입할 수 있습니다.

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

12-22: 잠재적 NullPointerException 위험

item.rank().intValue() 호출 시 rank()가 null이면 NPE가 발생합니다. 랭킹 결과에서 rank가 항상 존재해야 하지만, 방어적 코딩을 위해 null 체크를 고려해보세요.

🔎 제안된 수정

                     .map(item -> new DailyRankingItem(
                             item.productId(),
                             item.productName(),
                             item.brandName(),
                             item.price(),
                             item.likeCount(),
-                            item.rank().intValue()
+                            item.rank() != null ? item.rank().intValue() : null
                     ))

또는 DailyRankingItem의 rank 타입을 Long으로 통일하는 것도 고려해보세요.

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

30-43: 매 호출마다 TTL 갱신 최적화 고려

incrementScore가 호출될 때마다 expire()를 호출하여 TTL을 갱신합니다. 고빈도 호출 환경에서는 불필요한 Redis 명령이 될 수 있습니다.

🔎 최적화 제안 (선택적)

// 옵션 1: Lua 스크립트로 ZINCRBY와 EXPIRE를 원자적으로 실행
// 옵션 2: TTL이 짧아졌을 때만 갱신 (getExpire 체크 후 갱신)
// 현재 구현도 기능적으로는 문제없으며, 최적화는 부하 테스트 후 결정 가능

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

41-43: Collectors.toMap에서 중복 키 발생 시 예외가 발생할 수 있습니다.

ProductService.findProductsByIds가 중복 상품을 반환하는 경우는 드물지만, 방어적으로 merge function을 추가하는 것이 안전합니다.

🔎 제안된 수정

         List<Product> products = productService.findProductsByIds(productIds);
         Map<Long, Product> productMap = products.stream()
-                .collect(Collectors.toMap(Product::getId, product -> product));
+                .collect(Collectors.toMap(Product::getId, product -> product, (p1, p2) -> p1));

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

152-217: LGTM! Carry-over 테스트가 잘 구현되었습니다.

전날 점수의 가중치 적용과 원본 데이터 보존을 올바르게 검증합니다.

선택적 개선 제안: 오늘 키에 이미 데이터가 있는 상태에서 carry-over가 발생할 때 점수가 올바르게 합산되는지 검증하는 테스트 케이스를 추가하면 더 완벽한 커버리지를 제공할 수 있습니다.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9ecdb90 and 945a352.

📒 Files selected for processing (33)

• apps/commerce-api/src/main/java/com/loopers/application/order/OrderEvent.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductInfo.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/RankingInfo.java
• apps/commerce-api/src/main/java/com/loopers/domain/brand/Brand.java
• apps/commerce-api/src/main/java/com/loopers/domain/product/ProductRepository.java
• apps/commerce-api/src/main/java/com/loopers/domain/product/ProductService.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/Ranking.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingItem.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/cache/RankingCacheService.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductJpaRepository.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductRepositoryImpl.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/interfaces/listener/KafkaOutboxEventListener.java
• apps/commerce-api/src/test/java/com/loopers/application/product/ProductFacadeIntegrationTest.java
• apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingFacadeIntegrationTest.java
• apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingServiceIntegrationTest.java
• apps/commerce-api/src/test/java/com/loopers/infrastructure/cache/ProductCacheServiceIntegrationTest.java
• apps/commerce-api/src/test/java/com/loopers/infrastructure/cache/RankingCacheServiceIntegrationTest.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/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/consumer/MetricsConsumer.java
• apps/commerce-streamer/src/main/java/com/loopers/interfaces/scheduler/RankingScoreCarryOverScheduler.java
• apps/commerce-streamer/src/test/java/com/loopers/domain/ranking/RankingServiceIntegrationTest.java
• modules/kafka/src/main/java/com/loopers/application/kafka/KafkaEvent.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-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/infrastructure/cache/RankingCacheService.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.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/main/java/com/loopers/interfaces/consumer/MetricsConsumer.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/listener/KafkaOutboxEventListener.java
• modules/kafka/src/main/java/com/loopers/application/kafka/KafkaEvent.java

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

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:16.024Z
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/main/java/com/loopers/interfaces/consumer/MetricsConsumer.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/MetricsConsumer.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/interfaces/listener/KafkaOutboxEventListener.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/interfaces/api/product/ProductV1Dto.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductJpaRepository.java
• apps/commerce-api/src/main/java/com/loopers/domain/product/ProductService.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java

🧬 Code graph analysis (5)

apps/commerce-api/src/main/java/com/loopers/interfaces/listener/KafkaOutboxEventListener.java (1)

apps/commerce-api/src/main/java/com/loopers/application/order/OrderEvent.java (1)

• OrderEvent (6-87)

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

apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/MetricsConsumer.java (1)

• Slf4j (20-214)

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

apps/commerce-api/src/main/java/com/loopers/CommerceApiApplication.java (1)

• ConfigurationPropertiesScan (12-28)

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

k6_product_list.js (1)

• productId (356-356)

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

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

• RequiredArgsConstructor (17-76)

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

• RequiredArgsConstructor (15-41)

🔇 Additional comments (33)

apps/commerce-api/src/main/java/com/loopers/application/order/OrderEvent.java (1)

26-27: LGTM!

OrderCreated 이벤트에 주문 항목 정보가 올바르게 추가되었습니다. 매핑 로직이 정확하며 기존 OrderPaid 패턴과 일관성을 유지합니다.

Also applies to: 30-37, 45-46

modules/kafka/src/main/java/com/loopers/application/kafka/KafkaEvent.java (1)

32-32: LGTM!

Kafka 이벤트 OrderCreated에 주문 항목 정보가 올바르게 추가되었습니다. 팩토리 메서드 시그니처와 생성자 호출이 정확하게 업데이트되었습니다.

Also applies to: 35-35, 43-43

apps/commerce-api/src/test/java/com/loopers/infrastructure/cache/ProductCacheServiceIntegrationTest.java (1)

328-342: 테스트 헬퍼 메서드 업데이트 확인 완료

createProductInfo 헬퍼 메서드가 새로운 rank 필드를 포함하도록 올바르게 업데이트되었습니다. 캐시 테스트에서는 순위가 중요하지 않으므로 null을 전달하는 것이 적절합니다.

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

43-65: 상품 상세 응답에 순위 필드 추가 확인 완료

ProductResponse에 rank 필드가 올바르게 추가되었으며, info.rank()를 통해 적절히 매핑되고 있습니다. ProductItem (목록 조회용)에는 순위가 포함되지 않는 것이 의도된 설계로 보이며, 상세 조회에서만 순위를 제공하는 것은 합리적인 선택입니다.

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

1-8: RankingItem 레코드 설계 확인 완료

Redis ZSET 데이터를 전달하기 위한 간단한 데이터 캐리어로서 적절하게 설계되었습니다. Double 타입의 score 필드는 Redis ZSET의 score 값을 표현하기에 적합합니다.

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

7-13: 스케줄링 기능 활성화 확인 완료

@EnableScheduling 어노테이션이 추가되어 RankingScoreCarryOverScheduler와 같은 스케줄 작업이 실행될 수 있습니다. CommerceApiApplication과 일관되게 구성되었습니다.

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

1-8: Ranking 도메인 레코드 설계 확인 완료

RankingItem과 명확히 구분되는 도메인 레코드로서 적절하게 설계되었습니다. RankingItem(캐시 계층)에서 Ranking(도메인 계층)으로의 변환 시 순위 계산이 추가되는 구조가 깔끔합니다.

apps/commerce-api/src/main/java/com/loopers/domain/product/ProductRepository.java (1)

18-18: findProductsByIds 메서드는 null 및 빈 리스트 처리가 적절하게 구현되었습니다.

구현체에서 if (productIds == null || productIds.isEmpty())로 입력값을 검증한 후 빈 리스트를 반환하고 있어 엣지 케이스를 안전하게 처리하고 있습니다.

apps/commerce-api/src/main/java/com/loopers/domain/product/ProductService.java (1)

56-59: 배치 조회 메서드 구현 확인 완료

@Transactional(readOnly = true)를 사용한 읽기 전용 메서드로 적절하게 구현되었습니다. 리포지토리의 ProductRepositoryImpl.findProductsByIds()에서 null과 빈 리스트를 안전하게 처리하고 있으므로 엣지 케이스 처리도 문제없습니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductJpaRepository.java (1)

28-29: LGTM!

배치 조회를 위한 표준적인 IN 절 구현이며, 소프트 삭제된 레코드를 올바르게 필터링합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductRepositoryImpl.java (1)

42-48: LGTM!

null/empty 체크를 통한 방어적 프로그래밍으로 불필요한 DB 쿼리를 방지하고 NPE를 예방합니다.

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

28-34: LGTM!

입력 값이 유효하다는 전제 하에 순위 계산 로직(start + 1 + i)은 올바르며, 1-based 순위를 정확하게 생성합니다.

apps/commerce-api/src/main/java/com/loopers/domain/brand/Brand.java (1)

21-35: LGTM!

JPA를 위한 no-arg 생성자와 Builder 패턴 구현이 적절합니다. createBrand 팩토리 메서드는 빌더 패턴의 편의성 래퍼로 테스트 코드 작성 시 유용합니다.

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

73-212: LGTM!

포괄적인 E2E 테스트 커버리지를 제공합니다:

• 랭킹 데이터 존재 시 조회
• 데이터 없을 때 빈 리스트 반환
• 페이지네이션 동작 검증

명확한 arrange-act-assert 구조와 적절한 어설션으로 주요 시나리오를 잘 검증하고 있습니다.

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

5-18: LGTM!

랭킹 정보를 전달하기 위한 깔끔한 레코드 구조입니다. 중첩 레코드를 사용한 캡슐화가 적절하며, 모든 필드의 타입이 적합합니다.

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

1-19: LGTM!

가중치 상수가 명확하게 정의되어 있고, 주문 생성(0.7) > 좋아요(0.2) > 조회(0.1) 순으로 적절한 가중치 배분입니다. @Getter 활용도 적절합니다.

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

47-48: 좋아요 취소 시 랭킹 점수 처리 확인 필요

handleProductLikedEvents에서는 rankingService.incrementScore를 호출하지만, handleProductUnlikedEvents(라인 66-87)에서는 랭킹 점수를 차감하지 않습니다. 이것이 의도된 설계인지 확인이 필요합니다.

만약 랭킹이 순수 긍정 신호만 반영하는 설계라면 현재 구현이 맞지만, 좋아요 취소가 랭킹에 반영되어야 한다면 decrementScore 메서드 추가가 필요합니다.

---

106-107: LGTM!

조회 이벤트에 대한 랭킹 점수 증가 로직이 기존 패턴을 따르며 올바르게 통합되었습니다.

---

136-146: LGTM!

주문 생성 이벤트에서 각 주문 항목별로 랭킹 점수를 증가시키는 로직이 올바르게 구현되었습니다. ORDER_CREATED 가중치(0.7)가 가장 높아 구매 전환이 랭킹에 가장 큰 영향을 미치도록 설계되어 있습니다.

apps/commerce-api/src/test/java/com/loopers/application/product/ProductFacadeIntegrationTest.java (2)

56-57: LGTM!

RankingCacheService에 대한 @MockitoSpyBean 추가가 적절합니다. 기존 테스트 패턴과 일관성 있게 구현되었습니다.

---

289-354: LGTM!

랭킹이 없는 경우(rank = null)와 랭킹이 있는 경우(rank = 5L) 두 가지 시나리오에 대한 테스트가 잘 구현되어 있습니다. RankingCacheService 상호작용 검증도 포함되어 있어 테스트 커버리지가 충분합니다.

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

1-213: LGTM!

랭킹 파사드에 대한 통합 테스트가 포괄적으로 구현되어 있습니다:

• 정상 조회 시나리오
• DB에 없는 상품 제외 로직
• 빈 결과 처리
• 페이지네이션 동작

Redis와 DB 정리 로직도 @AfterEach에 적절히 포함되어 있습니다.

apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingServiceIntegrationTest.java (1)

1-158: LGTM!

RankingService.getRanking 메서드에 대한 통합 테스트가 잘 구현되어 있습니다:

• 데이터 존재 시 정상 조회
• 페이지네이션 동작 (3페이지 테스트)
• 빈 데이터 처리
• 순위가 1부터 시작하는지 검증

@BeforeEach와 @AfterEach에서 Redis를 정리하여 테스트 격리가 보장됩니다.

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

16-23: 이 부분은 실제로는 문제가 없습니다. RankingV1Controller.java에서 구현 시 @DateTimeFormat(pattern = "yyyyMMdd") 어노테이션을 사용하고 있으므로, API 명세의 설명 "yyyyMMdd 형식"과 실제 동작이 일치합니다.

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

45-58: carryOverScore 동작 시점 확인 및 테스트 커버리지 개선 제안

스케줄러가 매일 23:50 PM에 실행되므로 targetDate(내일)는 아직 하루가 시작되지 않은 상태입니다. 따라서 실제 운영 환경에서는 toKey에 기존 데이터가 없을 가능성이 높습니다.

다만, 현재 테스트 케이스는 toKey가 비어있는 경우만 검증하고 있습니다. 혹시 오류 복구나 수동 실행 등으로 toKey에 이미 누적된 점수가 있는 상황에서 unionAndStore(..., Aggregate.SUM, ...)이 제대로 병합하는지 확인하는 테스트 케이스 추가를 권장합니다.

// toKey에 기존 데이터가 있는 경우 병합 동작 검증
zSetOps.add(todayKey, "productId1", 50.0);  // 기존 당일 점수
rankingService.carryOverScore(yesterday, today);
// 검증: 기존 점수와 carry-over 점수가 SUM으로 합쳐지는가?

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

22-39: LGTM! 컨트롤러 구현이 적절합니다.

페이징 기본값과 날짜 포맷이 잘 구성되어 있습니다. RankingV1ApiSpec 인터페이스를 구현하여 API 문서화와 계약을 분리한 점도 좋습니다.

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

14-42: LGTM! rank 필드 추가가 깔끔하게 구현되었습니다.

기존 2개 파라미터 팩토리 메서드를 유지하면서 새로운 3개 파라미터 메서드를 추가하여 하위 호환성을 보장합니다.

apps/commerce-api/src/test/java/com/loopers/infrastructure/cache/RankingCacheServiceIntegrationTest.java (2)

43-114: LGTM! 테스트 커버리지가 적절합니다.

랭킹 범위 조회, 페이징, 빈 데이터 케이스를 포괄적으로 테스트합니다. RedisCleanUp을 활용한 teardown도 적절합니다.

---

117-160: LGTM! 상품 랭킹 조회 테스트가 적절합니다.

1-based 랭킹 변환과 존재하지 않는 상품에 대한 null 반환을 올바르게 검증합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/cache/RankingCacheService.java (2)

29-60: LGTM! Redis ZSET 조회 로직이 적절하게 구현되었습니다.

NumberFormatException 처리와 null 체크가 방어적으로 잘 구현되어 있습니다.

---

62-75: LGTM! 1-based 랭킹 변환이 올바르게 구현되었습니다.

Redis의 0-based reverseRank를 1-based 랭킹으로 변환하는 로직이 명확합니다.

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

41-150: LGTM! 점수 증가 테스트가 포괄적입니다.

다양한 이벤트 타입(LIKE, VIEW, ORDER_CREATED)에 대한 점수 증가, 누적, 날짜별 키 격리를 잘 검증합니다. TTL 검증(2일)도 적절합니다.

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

61-69: NPE 우려는 근거가 없습니다.

Product 엔티티의 price와 likeCount 필드는 다음과 같이 도메인 불변 조건으로 보호됩니다:

• @AttributeOverride의 nullable = false 제약
• 생성자의 명시적 검증 (validatePrice, validateLikeCount)
• 데이터베이스 스키마의 NOT NULL 제약

따라서 Product 인스턴스가 존재하면 두 필드 모두 항상 null이 아니며, 코드는 안전합니다.

Likely an incorrect or invalid review comment.