[volume-9] Product Ranking with Redis

[HongChangMo]

📌 Summary

• Redis ZSET 기반 랭킹 시스템 구현
• Kafka Batch 리스너 기반 이벤트 처리 변경
• 상품 이벤트 누계 -> DB 저장 -> 스케줄러 기반 랭킹 적재 파이프라인 적용

💬 Review Points

1. 일자별 전체 캐시 초기화 기능

멘토링때 멘토님께서 조언해주신대로 Scheduler를 통해 Score를 계산하는 로직을 분리하였습니다.
궁금한 점은, 전체 score에 대한 sync를 맞추기 위한 "일자별 전체 캐시 초기화" 기능 같은게 있으면 좋은지 궁금하여 질문드립니다.
현재는 ProductMetricsDaily(일자별 상품 집계 정보) 테이블에서 일자별 증분 데이터에 대한 랭킹 처리를 하도록 하였는데,
만약에 "일자별 전체 캐시 초기화" 같은 기능이 있다면, ProductMetrics(상품 집계 정보) 테이블에서 해당 상품에 대한 집계(스케줄러가 도는 날짜 집계)를 가지고 와서
캐시를 전체 초기화할 수 있는 기능이 있으면 어떨까 궁금하여 질문드립니다.

2. 랭킹 시스템 흐름

멘토링때 말씀 주신 내용을 참고해서 랭킹 시스템의 흐름을 아래와 같이 구현하였습니다.

[commerce-api]
    ↓ Kafka 이벤트 발행 (좋아요, 조회, 주문 등)
[Kafka Commit Log]
    ↓
[commerce-collector]
    ↓ Kafka 이벤트 Consume
    ↓ 이벤트 처리 및 누계
    ↓ DB 저장 (ProductMetricsDaily)
[Ranking Scheduler]
    ↓ ProductMetricsDaily 누계 데이터 조회
    ↓ Score 계산
[Redis ZSET 적재]

궁금한점은 멘토링 때 말씀해주신 내용처럼 누계와 랭킹 갱신을 Scheduler를 통해 분리했는데, 이 구조처럼 분리하는게 맞는지 궁금합니다.

✅ Checklist

📈 Ranking Consumer

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

⚾ Ranking API

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

📎 References

Summary by CodeRabbit

릴리스 노트

• 새로운 기능

  • 상품 상세 페이지에 좋아요, 조회, 주문 순위 정보 추가
  • 상품 순위 조회 API 엔드포인트 추가 (/api/v1/rankings)
  • 상품 조회 이벤트 추적 기능 강화

• 개선 사항

  • 주문 생성 이벤트에 주문 항목 상세 정보 포함
  • 순위 데이터 수집 및 처리 효율 개선

_{✏️ 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

이 풀 요청은 순위(ranking) 시스템 구현, 주문 이벤트 확장, 배치 이벤트 처리 추가를 통해 상거래 플랫폼의 이벤트 기반 아키텍처를 재구조화합니다. 도메인 서비스 중심 설계에서 애플리케이션 파사드 중심으로 전환하며, Redis 기반 순위 저장소와 일일 메트릭 추적을 도입합니다.

Changes

Cohort / File(s)	변경 요약
주문 이벤트 페이로드 확장 apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java, apps/commerce-api/src/main/java/com/loopers/domain/order/event/OrderCreatedEvent.java	OrderCreatedEvent에 새로운 OrderItem 중첩 레코드와 items 필드 추가. OrderFacade에서 저장된 주문 항목으로부터 OrderItem 리스트를 구성하여 이벤트 페이로드에 전달. KafkaTopics 참조 정정.
순위 시스템 - 도메인 계층 apps/commerce-api/src/main/java/com/loopers/domain/ranking/Ranking.java, apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingType.java, apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java, apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/RedisRankingRepository.java	Ranking 도메인 모델(rank, productId, score) 및 RankingType 열거형(LIKE, VIEW, ORDER, ALL) 도입. RankingService가 RedisRankingRepository에 위임하고 입력 검증 수행. Redis ZSET 기반 저장소로 상위 순위, 페이지별 순위, 개별 상품 순위, 순위 크기 조회 지원.
순위 시스템 - 애플리케이션 계층 apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingInfo.java, apps/commerce-api/src/main/java/com/loopers/application/ranking/SimpleRankingInfo.java, apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java	RankingInfo 및 nested ProductRankings 레코드로 순위 데이터 모델링. SimpleRankingInfo는 nullable rank/score 쌍 표현. RankingFacade는 상위 순위, 페이지별 순위, 개별 상품 순위, 모든 순위 유형 조회 및 상품 정보로 리칭 제공.
상품 상세 정보 및 순위 통합 apps/commerce-api/src/main/java/com/loopers/application/product/ProductDetailInfo.java, apps/commerce-api/src/main/java/com/loopers/application/product/ProductInfo.java, apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java	ProductDetailInfo에 rankings 필드 추가 및 of(Product, ProductRankings) 팩토리 메소드 신설. ProductInfo에 from(Product) 정적 생성자 추가. ProductFacade에서 RankingFacade 의존성 추가하고 캐시 누락 시 순위 데이터로 상품 상세 정보 구성.
상품 뷰 이벤트 발행 apps/commerce-api/src/main/java/com/loopers/application/product/ProductEventPublisher.java, apps/commerce-api/src/main/java/com/loopers/application/outbox/OutboxEventPublisher.java	ProductEventPublisher 신설(ProductViewedEvent 발행), OutboxEventPublisher에서 PRODUCT_VIEW 집계 타입 처리 추가. 이전 인라인 발행 로직 제거.
상품 저장소 확장 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/infrastructure/product/ProductJpaRepository.java, apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductRepositoryImpl.java	일괄 조회를 위한 findAllByIdIn(List) 메소드를 저장소 계층 전반에 추가.
순위 API 엔드포인트 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	/api/v1/rankings 경로에 페이지별, 상위, 개별 상품 순위 조회 엔드포인트 신설. 요청/응답 DTO 정의 및 Date 파싱 로직 통합.
상품 DTO 순위 필드 추가 apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1DTO.java	ProductDetailResponse에 RankingResponse 필드 추가 및 nested SimpleRankingResponse 레코드 정의. RankingInfo.ProductRankings에서 DTO로 변환 로직 구현.
이벤트 처리 파사드화 - Collector apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java, apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledInfo.java, apps/commerce-collector/src/main/java/com/loopers/domain/eventhandled/EventHandledService.java (삭제), apps/commerce-collector/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java	EventHandledService 제거, EventHandledFacade 신설(isAlreadyHandled, markAsHandled, markAsHandledBatch). 배치 저장 지원 추가.
메트릭 수집 - 일일 메트릭 엔티티 및 저장소 apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDaily.java, apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDailyRepository.java, apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyJpaRepository.java, apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyRepositoryImpl.java	ProductMetricsDaily JPA 엔티티(productId, metricDate, 델타, 처리 상태) 및 저장소 신설. 일일 메트릭 조회, 저장, upsert, 정리 기능 제공.
메트릭 파사드 리팩토링 apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java, apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java, apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java	ProductMetricsService를 ProductMetricsFacade로 이동 및 배치 upsert 메소드(updateLikeCountBatch, updateViewCountBatch, updateOrderCountBatch) 추가. ProductMetricsDailyFacade 신설로 일일 델타 배치 업데이트 위임. JDBC 배치 작업 지원.
배치 이벤트 핸들러 - 상품 뷰 apps/commerce-collector/src/main/java/com/loopers/application/product/ProductBatchEventHandler.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductEventConsumer.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/dto/ProductEvent.java	ProductBatchEventHandler 신설로 배치 ProductEvent 처리(필터링, 중복 제거, 델타 집계, 메트릭 업데이트, 이벤트 표시). ProductBatchEventConsumer는 Kafka 배치 리스너. ProductEventConsumer를 consumer/product 패키지로 이동 및 비활성화. ProductEvent DTO 추가.
배치 이벤트 핸들러 - 상품 좋아요 apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/dto/ProductLikeEvent.java	ProductLikeBatchEventHandler 신설로 배치 ProductLikeEvent 처리(유형별 델타, 이벤트 표시). ProductLikeBatchEventConsumer는 Kafka 배치 리스너. ProductLikeEventConsumer를 consumer/like 패키지로 이동 및 비활성화. ProductLikeEvent DTO 추가.
배치 이벤트 핸들러 - 주문 apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderBatchEventConsumer.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderEventConsumer.java, apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/dto/OrderEvent.java	OrderBatchEventHandler 신설로 배치 OrderEvent 처리(ORDER_CREATED 필터링, 수량 집계, 일일 메트릭 업데이트). OrderBatchEventConsumer는 Kafka 배치 리스너. OrderEventConsumer 리팩토링(DTO 기반 파싱, handleOrderCreatedEvent 내부 핸들러). OrderEvent/OrderCreatedPayload/OrderItem DTO 구조 추가.
순위 업데이트 스케줄링 apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingFacade.java, apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingScheduler.java, apps/commerce-collector/src/main/java/com/loopers/CommerceCollectorApplication.java	RankingFacade(Redis ZSET 배치 업데이트, TTL/가중치 설정) 신설. RankingScheduler 신설로 5분마다 미처리 일일 메트릭 처리, 복합 순위 계산, 10일 이상 된 기록 정리 스케줄. @EnableScheduling 추가.
이벤트 핸들러 - 서비스에서 파사드로 마이그레이션 apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeEventHandler.java, apps/commerce-collector/src/main/java/com/loopers/application/order/OrderEventHandler.java, apps/commerce-collector/src/main/java/com/loopers/application/product/ProductEventHandler.java	EventHandledService → EventHandledFacade, ProductMetricsService → ProductMetricsFacade 의존성 변경. 모든 메소드 호출을 파사드 기반으로 업데이트. 제어 흐름 유지.
메트릭 저장소 확장 apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsRepository.java	upsertLikeDeltas, upsertViewDeltas, upsertOrderDeltas 배치 메소드 추가.
설정 업데이트 apps/commerce-collector/src/main/resources/application.yml	Kafka max.poll.records 10→100, fetch-min-size/fetch-max-wait 추가. 순위 설정 블록 신설(ttl-days: 2, 가중치: like 0.2, view 0.1, order 0.6).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• [volume-7] Decoupling with Event #183: OrderFacade 이벤트 발행 흐름 수정과 OrderCreatedEvent 페이로드 확장이 동일 파일에서 겹침.
• [volume-3] 도메인 모델링 및 구현 #94: ProductFacade 및 ProductDetailInfo 수정으로 상품 도메인 API 변경이 일치.
• [volume - 8] Decoupling with Kafka  #204: Outbox/idempotency 파이프라인(EventHandled, Kafka 소비자/프로듀서) 구현 시 동일 컴포넌트 변경.

Suggested labels

enhancement, feature, backend

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 24.86% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	❓ Inconclusive	PR 설명이 기본 요구 사항 섹션을 대부분 포함하지만, 일부 섹션이 불완전합니다.	Summary와 Review Points는 작성되었으나, Checklist 항목들이 대부분 미완료([ ] 체크 안됨) 상태입니다. 완료된 항목과 미완료 항목을 명확히 구분하고, 특히 테스트 코드 포함 여부와 같은 중요 항목에 대한 구체적인 설명을 추가해주세요.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	PR 제목은 '[volume-9] Product Ranking with Redis'로 Redis를 기반으로 한 랭킹 시스템 구현이라는 주요 변경사항을 명확하게 요약하고 있습니다.

---

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: 13

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java (1)

17-89: 비활성화된 컨슈머 코드 정리 필요

@Component 어노테이션이 주석 처리되어 이 컨슈머가 비활성화되었지만, 전체 구현 코드(89줄)가 그대로 남아있습니다. 배치 컨슈머(ProductLikeBatchEventConsumer)로 대체된 것으로 보이므로, 다음 중 하나를 선택해주세요:

1. 권장: 이 파일을 완전히 삭제
2. 참고용으로 보존하려는 경우, 파일 상단에 명확한 주석 추가 (예: "이 클래스는 배치 처리로 대체되었으며 참고용으로만 보존됨")

현재 상태는 코드베이스에 혼란을 주고 유지보수성을 저해합니다.

🔎 코드 정리를 위한 제안

Option 1: 파일 삭제 (권장)

# 이 파일을 git에서 제거
git rm apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java

Option 2: 명확한 문서화
파일을 유지하려면 상단에 다음과 같은 주석을 추가:

 package com.loopers.interfaces.consumer.like;

+/**
+ * @deprecated 이 클래스는 배치 처리 방식(ProductLikeBatchEventConsumer)으로 대체되었습니다.
+ * 참고 목적으로만 보존되며, 프로덕션에서 사용되지 않습니다.
+ * TODO: 배치 처리가 안정화되면 이 파일을 삭제할 예정입니다.
+ */
 // 메시지 단건 처리 비활성화
 //@Component

🧹 Nitpick comments (23)

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

8-10: rank 필드의 타입 일관성 검토 필요

rank가 primitive int로 선언되어 있지만, SimpleRankingInfo에서는 Integer(nullable)로 정의되어 있습니다. 순위가 없는 경우를 표현해야 한다면 Integer로 변경하는 것이 일관성 있습니다.

🔎 제안된 수정

 @Getter
 public class Ranking {
-    private final int rank;
+    private final Integer rank;
     private final Long productId;
     private final Double score;

     @Builder
-    public Ranking(int rank, Long productId, Double score) {
+    public Ranking(Integer rank, Long productId, Double score) {
         this.rank = rank;
         this.productId = productId;
         this.score = score;
     }
 }

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/dto/ProductEvent.java (1)

3-8: 이벤트 DTO 설계 승인

깔끔한 record 기반 이벤트 DTO입니다.

ProductLikeEvent와 동일한 구조를 가지고 있어 코드 중복이 있습니다. 필요하다면 공통 인터페이스나 제네릭 타입을 고려할 수 있지만, 도메인 분리를 위해 개별 타입을 유지하는 것도 합리적인 선택입니다.

apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledInfo.java (1)

9-12: 정적 팩토리 메서드 단순화 고려

of() 메서드가 단순히 생성자를 호출만 하고 있습니다. Record는 이미 public 정규 생성자를 제공하므로, 이 팩토리 메서드는 추가적인 가치를 제공하지 않습니다.

현재 구현도 동작하지만, 호출 측에서 new EventHandledInfo(...)를 직접 사용하거나, 팩토리 메서드가 실제로 검증이나 변환 로직을 추가하는 경우에만 유지하는 것을 고려해보세요.

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

29-37: 엔드포인트 파라미터 바인딩 방식의 불일치 및 date 파라미터 검증

getTopRanking과 getRankingWithPaging 엔드포인트는 요청 DTO를 사용하는 반면, getProductRanking은 개별 @PathVariable과 @RequestParam을 사용하고 있어 일관성이 부족합니다. 또한 모든 엔드포인트의 date 파라미터가 명시적인 @Pattern 검증 없이 문자열로 선언되어 있습니다.

현재는 컨트롤러의 parseDate() 메서드에서 yyyyMMdd 형식으로 런타임에 파싱되고 있으며, 형식이 @Schema 어노테이션으로 문서화되어 있습니다. 다만 잘못된 형식의 date가 전달되면 DateTimeParseException이 발생하므로, 다음 개선을 고려하세요:

1. 설계 일관성: getProductRanking 엔드포인트를 GetProductRankingRequest DTO로 통일하거나, 현재 설계가 의도적인 경우 그 이유를 문서화해주세요.
2. date 파라미터 검증: 모든 date 파라미터에 @Pattern(regexp = "\\d{8}") 같은 명시적 검증을 추가하여 입력값 검증을 선언적으로 처리하는 것이 좋습니다.

apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.java (2)

59-63: 배치 멱등성 체크 최적화 고려

현재 각 이벤트마다 개별적으로 isAlreadyHandled를 호출하고 있습니다. 대량의 이벤트 처리 시 N번의 데이터베이스 쿼리가 발생할 수 있습니다. EventHandledFacade에 배치 체크 메서드(예: areAlreadyHandled(List<String> eventIds))를 추가하면 성능을 개선할 수 있습니다.

---

85-92: 이벤트 타입 비교에 상수 사용 권장

문자열 리터럴 비교 대신 KafkaTopics.ProductLike 상수를 직접 사용하고 있어 양호하지만, 알 수 없는 이벤트 타입에 대한 처리가 0을 반환합니다. 예상치 못한 이벤트 타입이 들어올 경우 로그를 남기거나 예외를 발생시키는 것을 고려해보세요.

🔎 제안하는 개선안

 private int calculateDelta(String eventType) {
     if (KafkaTopics.ProductLike.LIKE_ADDED.equals(eventType)) {
         return 1;
     } else if (KafkaTopics.ProductLike.LIKE_REMOVED.equals(eventType)) {
         return -1;
     }
+    log.warn("알 수 없는 이벤트 타입: {}", eventType);
     return 0;
 }

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

32-55: 이벤트 발행 패턴이 올바르게 구현되었습니다.

REQUIRES_NEW 전파 전략으로 부모 트랜잭션과 독립적인 이벤트 발행을 보장하며, 실패 시 조회 작업에 영향을 주지 않는 fire-and-forget 패턴이 적절히 적용되었습니다.

선택적 개선 사항: 로그 레벨 조정

Line 45의 성공 로그가 debug 레벨로 되어 있습니다. 이벤트 발행은 중요한 비즈니스 동작이므로 감사 추적(audit trail)을 위해 info 레벨을 고려해보세요.

-            log.debug("ProductViewedEvent 발행 성공 - productId: {}", productId);
+            log.info("ProductViewedEvent 발행 성공 - productId: {}", productId);

apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDaily.java (1)

71-74: 타임존 명시 권장

Line 73의 ZonedDateTime.now()는 시스템 기본 타임존을 사용합니다. 명시적으로 ZonedDateTime.now(ZoneId.of("Asia/Seoul"))을 사용하여 타임존 불일치를 방지하는 것이 좋습니다.

🔎 제안하는 수정

 public void markAsProcessed() {
     this.isProcessed = true;
-    this.processedAt = ZonedDateTime.now();
+    this.processedAt = ZonedDateTime.now(ZoneId.of("Asia/Seoul"));
 }

필요 시 상수로 추출:

private static final ZoneId KST = ZoneId.of("Asia/Seoul");

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

20-45: from(Product)과 of(Product, RankingInfo.ProductRankings) 간 중복 코드 제거 권장

두 팩토리 메서드가 동일한 필드 매핑 로직을 반복하고 있습니다. from(Product)이 of(Product, null)에 위임하도록 변경하면 유지보수성이 향상됩니다.

🔎 중복 제거 제안

     public static ProductDetailInfo from(Product product) {
-        return new ProductDetailInfo(
-                product.getId(),
-                product.getProductCode(),
-                product.getProductName(),
-                product.getPrice().getAmount(),
-                product.getStockQuantity(),
-                product.getLikeCount(),
-                product.getBrand() != null ? BrandInfo.from(product.getBrand()) : null,
-                null
-        );
+        return of(product, null);
     }

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

1-14: 도메인 계층에서 인프라스트럭처 계층 직접 의존 문제

RankingService가 도메인 패키지(com.loopers.domain.ranking)에 위치하지만, 인프라스트럭처 계층의 RedisRankingRepository를 직접 의존하고 있습니다. 이는 의존성 역전 원칙(DIP)을 위반합니다.

도메인 계층에 RankingRepository 인터페이스를 정의하고, RedisRankingRepository가 이를 구현하도록 하거나, 이 서비스를 application 계층으로 이동하는 것을 권장합니다.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/dto/OrderEvent.java (1)

31-35: OrderItem 레코드에도 @JsonIgnoreProperties 추가 권장

OrderEvent와 OrderCreatedPayload에는 @JsonIgnoreProperties(ignoreUnknown = true)가 적용되어 있으나, OrderItem에는 누락되어 있습니다. 스키마 진화 시 일관된 역호환성을 위해 추가를 권장합니다.

🔎 수정 제안

+        @JsonIgnoreProperties(ignoreUnknown = true)
         public record OrderItem(
                 Long productId,
                 Integer quantity,
                 BigDecimal price
         ) {}

apps/commerce-collector/src/main/java/com/loopers/application/product/ProductBatchEventHandler.java (1)

57-61: filterUnprocessedEvents에서 N+1 쿼리 발생 가능성

각 이벤트마다 eventHandledFacade.isAlreadyHandled(event.eventId())를 개별 호출하고 있어, 이벤트 수가 많을 경우 N+1 쿼리 문제가 발생할 수 있습니다.

EventHandledFacade에 isAlreadyHandledBatch(List<String> eventIds) 메서드를 추가하여 한 번의 쿼리로 처리하는 것을 권장합니다.

🔎 최적화 제안

     private List<ProductEvent> filterUnprocessedEvents(List<ProductEvent> events) {
+        List<String> eventIds = events.stream()
+                .map(ProductEvent::eventId)
+                .collect(Collectors.toList());
+        Set<String> handledEventIds = eventHandledFacade.findHandledEventIds(eventIds);
+        
         return events.stream()
-                .filter(event -> !eventHandledFacade.isAlreadyHandled(event.eventId()))
+                .filter(event -> !handledEventIds.contains(event.eventId()))
                 .collect(Collectors.toList());
     }

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java (1)

37-41: 미사용 파라미터 keys 확인

@Header(KafkaHeaders.RECEIVED_KEY) List<String> keys 파라미터가 선언되어 있지만 메서드 내에서 사용되지 않습니다. 의도적인 것이 아니라면 제거하거나, 로깅/추적 목적으로 사용하는 것을 고려해 주세요.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderBatchEventConsumer.java (1)

66-80: ArrayList import 사용 권장

java.util.ArrayList를 직접 참조하는 대신 import 문을 사용하는 것이 일관성 있는 코드 스타일입니다.

🔎 제안된 수정

 import java.util.List;
+import java.util.ArrayList;

...

 private List<OrderEvent> parseMessages(List<String> messages, List<String> keys) {
-    List<OrderEvent> events = new java.util.ArrayList<>();
+    List<OrderEvent> events = new ArrayList<>();

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

39-39: 타임존 고려 필요

LocalDate.now()는 시스템 기본 타임존을 사용합니다. 서버 배포 환경이 다른 타임존일 경우 예상치 못한 동작이 발생할 수 있습니다.

🔎 권장 수정

-LocalDate today = LocalDate.now();
+LocalDate today = LocalDate.now(ZoneId.of("Asia/Seoul"));

또는 애플리케이션 전역에서 사용할 Clock 빈을 주입받아 사용하는 것도 테스트 용이성을 높이는 방법입니다.

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

88-88: 타임존 일관성 확인 필요

LocalDate.now()가 RankingScheduler와 이 클래스에서 모두 사용됩니다. 두 컴포넌트가 다른 시점에 실행될 때 타임존 경계에서 날짜 불일치가 발생할 수 있습니다. 명시적 타임존 사용을 권장합니다.

🔎 권장 수정

+private static final ZoneId ZONE_ID = ZoneId.of("Asia/Seoul");
+
 private void incrementRanking(String prefix, Map<Long, Integer> deltas, double weight) {
     // ...
-    String todayKey = prefix + ":" + LocalDate.now().format(DATE_FORMATTER);
+    String todayKey = prefix + ":" + LocalDate.now(ZONE_ID).format(DATE_FORMATTER);

Also applies to: 129-129

---

137-138: 부동소수점 비교 시 주의

entry.getValue() == 0.0 비교는 부동소수점 정밀도 문제로 예상치 못한 결과를 낼 수 있습니다. 하지만 이 경우 점수가 정수 연산의 결과이므로 실제로는 문제가 없을 가능성이 높습니다.

🔎 더 안전한 비교 방식

-if (entry.getValue() == 0.0) continue;
+if (Math.abs(entry.getValue()) < 1e-9) continue;

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/RedisRankingRepository.java (1)

129-142: NumberFormatException 처리 필요

Long.parseLong(tuple.getValue().toString())은 Redis에 잘못된 데이터가 저장된 경우 NumberFormatException을 발생시킬 수 있습니다. 방어적 처리를 권장합니다.

🔎 권장 수정

 for (ZSetOperations.TypedTuple<Object> tuple : result) {
     if (tuple.getValue() == null) {
         continue;
     }

+    Long productId;
+    try {
+        productId = Long.parseLong(tuple.getValue().toString());
+    } catch (NumberFormatException e) {
+        log.warn("잘못된 productId 형식 - value: {}", tuple.getValue());
+        continue;
+    }
-    Long productId = Long.parseLong(tuple.getValue().toString());
     Double score = tuple.getScore();

     entries.add(Ranking.builder()
             .rank(rank++)
             .productId(productId)
             .score(score)
             .build());
 }

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

91-96: 잘못된 날짜 형식 처리 필요

LocalDate.parse()는 잘못된 형식의 날짜 문자열에 대해 DateTimeParseException을 발생시킵니다. 현재 전역 예외 핸들러가 있다면 문제없지만, 명확한 에러 메시지를 위해 명시적 처리를 권장합니다.

🔎 권장 수정

 private LocalDate parseDate(String dateString) {
     if (dateString == null || dateString.isBlank()) {
         return LocalDate.now();
     }
+    try {
         return LocalDate.parse(dateString, DATE_FORMATTER);
+    } catch (DateTimeParseException e) {
+        throw new IllegalArgumentException("잘못된 날짜 형식입니다. yyyyMMdd 형식을 사용해주세요: " + dateString);
+    }
 }

관련 코드 스니펫 ApiControllerAdvice.kt에서 일반 Throwable을 INTERNAL_ERROR로 처리하므로, IllegalArgumentException이나 커스텀 예외를 사용하여 적절한 400 응답을 반환하는 것이 좋습니다.

---

82-84: null 응답 대신 404 반환 고려

ApiResponse.success(null) 대신 명확한 404 응답이나 빈 응답 객체를 반환하는 것이 API 사용자에게 더 명확합니다. 주석에서도 "적절한 에러 응답"을 언급하고 있습니다.

🔎 권장 수정 옵션

옵션 1: 404 응답 반환

 if (ranking == null) {
-    return ApiResponse.success(null);  // 또는 적절한 에러 응답
+    throw new CoreException(ErrorType.NOT_FOUND, "해당 상품의 랭킹 정보가 없습니다.");
 }

옵션 2: Optional 패턴 사용

-if (ranking == null) {
-    return ApiResponse.success(null);  // 또는 적절한 에러 응답
-}
-
-return ApiResponse.success(
-        RankingV1Dto.ProductRankingResponse.from(ranking)
-);
+return ApiResponse.success(
+        ranking != null ? RankingV1Dto.ProductRankingResponse.from(ranking) : null
+);

---

22-46: 랭킹 조회와 카운트 조회 분리

getRankingWithPaging과 getTopRanking 모두 랭킹 데이터와 총 개수를 별도로 조회합니다. 성능이 중요하다면 RankingFacade에서 한 번에 반환하는 방식을 고려해볼 수 있습니다.

Also applies to: 48-69

apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java (1)

125-138: NPE 방지 및 스타일 개선

1. Line 126: new java.util.ArrayList<>() 대신 import 사용 권장
2. Line 133: event.payload().orderId()가 null인 경우 NPE 발생 가능

🔎 권장 수정

+import java.util.ArrayList;

 private List<EventHandledInfo> createEventHandledInfos(Iterable<OrderEvent> events) {
-    List<EventHandledInfo> infos = new java.util.ArrayList<>();
+    List<EventHandledInfo> infos = new ArrayList<>();
     for (OrderEvent event : events) {
         if (KafkaTopics.Order.ORDER_CREATED.equals(event.eventType())) {
+            OrderEvent.OrderCreatedPayload payload = event.payload();
+            if (payload == null || payload.orderId() == null) {
+                log.warn("유효하지 않은 payload - eventId: {}", event.eventId());
+                continue;
+            }
             infos.add(EventHandledInfo.of(
                     event.eventId(),
                     event.eventType(),
                     AggregateTypes.ORDER,
-                    event.payload().orderId().toString()
+                    payload.orderId().toString()
             ));
         }
     }
     return infos;
 }

apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyRepositoryImpl.java (1)

48-151: 배치 upsert 구현이 잘 되어 있습니다.

BatchPreparedStatementSetter를 사용한 배치 처리와 ON DUPLICATE KEY UPDATE 패턴이 적절합니다. 빈 맵에 대한 early return도 좋은 방어적 코딩입니다.

선택적으로, 세 upsert 메서드의 구조가 거의 동일하므로 공통 private 헬퍼 메서드로 추출하면 중복을 줄일 수 있습니다:

private void upsertDeltas(Map<Long, Integer> deltas, LocalDate metricDate, 
                          String sql, String metricName) {
    if (deltas.isEmpty()) return;
    // ... 공통 로직
}

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 128f47d and 5b67c36.

📒 Files selected for processing (54)

• apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/outbox/OutboxEventPublisher.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductDetailInfo.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductEventPublisher.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/RankingFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingInfo.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/SimpleRankingInfo.java
• apps/commerce-api/src/main/java/com/loopers/domain/order/event/OrderCreatedEvent.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/RankingService.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingType.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/infrastructure/ranking/RedisRankingRepository.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-collector/src/main/java/com/loopers/CommerceCollectorApplication.java
• apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java
• apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledInfo.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java
• apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java
• apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/order/OrderEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/product/ProductBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/product/ProductEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingFacade.java
• apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingScheduler.java
• apps/commerce-collector/src/main/java/com/loopers/domain/eventhandled/EventHandledRepository.java
• apps/commerce-collector/src/main/java/com/loopers/domain/eventhandled/EventHandledService.java
• apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDaily.java
• apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDailyRepository.java
• apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsRepository.java
• apps/commerce-collector/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java
• apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyJpaRepository.java
• apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyRepositoryImpl.java
• apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/dto/ProductLikeEvent.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/dto/OrderEvent.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/dto/ProductEvent.java
• apps/commerce-collector/src/main/resources/application.yml

💤 Files with no reviewable changes (1)

• apps/commerce-collector/src/main/java/com/loopers/domain/eventhandled/EventHandledService.java

🧰 Additional context used

🧠 Learnings (9)

📚 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-api/src/main/java/com/loopers/application/outbox/OutboxEventPublisher.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductEventPublisher.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java
• apps/commerce-api/src/main/java/com/loopers/domain/order/event/OrderCreatedEvent.java
• apps/commerce-collector/src/main/java/com/loopers/application/order/OrderEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeEventHandler.java
• apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java
• apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/dto/ProductLikeEvent.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/dto/OrderEvent.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/product/ProductBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/product/ProductEventHandler.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-api/src/main/java/com/loopers/application/outbox/OutboxEventPublisher.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductEventPublisher.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/dto/ProductEvent.java
• apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledInfo.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/dto/ProductLikeEvent.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/product/ProductEventHandler.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-collector/src/main/java/com/loopers/domain/eventhandled/EventHandledRepository.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductEventPublisher.java
• apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/application/order/OrderEventHandler.java
• apps/commerce-api/src/main/java/com/loopers/application/order/OrderFacade.java
• apps/commerce-collector/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderEventConsumer.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/infrastructure/product/ProductJpaRepository.java
• apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDaily.java
• apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java
• apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsRepository.java
• apps/commerce-api/src/main/java/com/loopers/domain/product/ProductRepository.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeEventHandler.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/dto/ProductLikeEvent.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java
• apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/product/ProductInfo.java
• apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java

📚 Learning: 2025-11-21T03:38:07.494Z

Learnt from: minor7295
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 99
File: apps/commerce-api/src/main/resources/application.yml:26-30
Timestamp: 2025-11-21T03:38:07.494Z
Learning: The batch job implementation for likeCount synchronization in apps/commerce-api is temporary and intended for development environment only. It will be replaced with Event-Driven Architecture (EDA) before production deployment, so production-level configuration concerns (like profile-based initialize-schema settings) are not required.

Applied to files:

• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.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-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeEventConsumer.java
• apps/commerce-collector/src/main/java/com/loopers/application/product/ProductEventHandler.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-12-07T15:47:18.277Z

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 52
File: apps/commerce-api/src/main/kotlin/com/loopers/infrastructure/payment/PgFeignConfig.kt:0-0
Timestamp: 2025-12-07T15:47:18.277Z
Learning: In Spring Cloud OpenFeign, configuration classes specified in FeignClient(configuration = ...) do NOT need the Configuration annotation. Spring Cloud OpenFeign creates a separate ApplicationContext for each named client and directly instantiates Bean methods from the configuration class. Adding Configuration would cause the class to be registered globally via ComponentScan, making the configuration apply to ALL Feign clients instead of just the specific client, which is usually undesirable.

Applied to files:

• apps/commerce-collector/src/main/java/com/loopers/CommerceCollectorApplication.java

📚 Learning: 2025-11-09T10:41:39.297Z

Learnt from: ghojeong
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 25
File: apps/commerce-api/src/main/kotlin/com/loopers/domain/product/ProductRepository.kt:1-12
Timestamp: 2025-11-09T10:41:39.297Z
Learning: In this codebase, domain repository interfaces are allowed to use Spring Data's org.springframework.data.domain.Page and org.springframework.data.domain.Pageable types. This is an accepted architectural decision and should not be flagged as a DIP violation.

Applied to files:

• apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyJpaRepository.java

🧬 Code graph analysis (14)

apps/commerce-api/src/main/java/com/loopers/application/outbox/OutboxEventPublisher.java (1)

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

• KafkaTopics (3-58)

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

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

• AggregateTypes (3-14)

modules/kafka/src/main/java/com/loopers/kafka/KafkaTopics.java (2)

• KafkaTopics (3-58)
• ProductDetail (20-26)

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

• Slf4j (17-132)

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java (4)

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

• KafkaTopics (3-58)

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java (1)

• Component (12-42)

apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java (1)

• Component (12-58)

apps/commerce-collector/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java (1)

• Component (10-34)

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

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

• Slf4j (19-139)

apps/pg-simulator/src/main/kotlin/com/loopers/interfaces/api/ApiControllerAdvice.kt (1)

• log (22-119)

apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java (4)

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

• AggregateTypes (3-14)

modules/kafka/src/main/java/com/loopers/kafka/KafkaTopics.java (2)

• KafkaTopics (3-58)
• Order (28-36)

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java (1)

• Slf4j (13-70)

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java (1)

• Component (12-42)

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

modules/kafka/src/main/java/com/loopers/kafka/KafkaTopics.java (2)

• KafkaTopics (3-58)
• Coupon (38-45)

apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java (1)

apps/commerce-collector/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java (1)

• Component (10-34)

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

apps/commerce-api/src/main/java/com/loopers/interfaces/api/brand/BrandV1Dto.java (1)

• BrandV1Dto (5-19)

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java (1)

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

• KafkaTopics (3-58)

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

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

• RankingV1Dto (13-151)

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

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

• Component (18-127)

apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsDailyRepositoryImpl.java (2)

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java (1)

• Component (12-42)

apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java (1)

• Component (12-58)

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

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

• RequiredArgsConstructor (15-80)

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

• Component (10-56)

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java (3)

apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java (1)

• Slf4j (18-144)

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java (1)

• Component (12-42)

apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java (1)

• Component (12-58)

🔇 Additional comments (50)

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductEventConsumer.java (2)

1-1: 패키지 재구성이 적절합니다.

제품(product) 도메인별 컨슈머 네임스페이스로의 재구성이 PR의 전반적인 구조 개선과 일치합니다.

---

20-79: 배치 컨슈머가 존재하고 PRODUCT_VIEWED 이벤트를 처리하지만, 에러 핸들링 전략이 단건 컨슈머와 다릅니다.

ProductBatchEventConsumer는 존재하며 PRODUCT_VIEWED 이벤트를 정상적으로 처리합니다. 그러나 에러 핸들링 패턴의 불일치가 있습니다:

• ProductEventConsumer: JSON 파싱 에러 시 명시적으로 acknowledgment.acknowledge()를 호출하여 재시도를 방지하고, 비즈니스 로직 에러는 예외를 던져 재시도를 허용합니다.
• ProductBatchEventConsumer: JSON 파싱 에러를 parseEvent() 메서드에서 catch하여 null을 반환하고 Objects::nonNull로 필터링합니다. 이는 에러를 암묵적으로 처리하며, 배치 레벨 예외만 발생시킵니다.

또한 추가 검증이 필요합니다:

1. 이 코드베이스에서는 EventInboxAspect 패턴이 존재하지 않습니다. 에러 처리가 수동 try-catch로 구현되어 있습니다.
2. JSON 파싱 실패에 대한 재시도 정책이 두 컨슈머 간에 불일치합니다. 배치 버전에서 파싱 실패 메시지가 자동으로 버려지는데, 이것이 의도된 동작인지 확인하세요.

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

31-33: application.yml의 Kafka 설정이 효과 없음

선택된 설정값들이 modules/kafka/src/main/java/com/loopers/confg/kafka/KafkaConfig.java의 하드코딩된 상수로 인해 무시됩니다. 실제 적용되는 설정은 다음과 같습니다:

• max.poll.records: 100 → 3000 (하드코딩됨)
• fetch-min-size: 1024 → 1MB (하드코딩됨)
• fetch-max-wait: 500ms → 5000ms (하드코딩됨)

따라서 max.poll.interval.ms(기본 5분) 대신 MAX_POLL_INTERVAL_MS = 2분(120초)이 실제 제한값입니다. 3000개 메시지를 3개 동시성으로 처리할 때 2분 내에 배치 처리가 완료되지 않으면 컨슈머 리밸런싱 위험이 높습니다. KafkaConfig의 하드코딩된 값들이 설계 의도를 반영하는지, 그리고 배치 처리 시간이 실제로 2분 이내로 완료되는지 검증하십시오.

Likely an incorrect or invalid review comment.

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

19-20: 도메인 인터페이스 추가가 적절합니다.

새로운 메서드 시그니처가 리포지토리 계층 전체와 일관성 있게 추가되었습니다.

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

58-61: 구현이 올바릅니다.

JPA 리포지토리로의 단순 위임 패턴이 정확하게 구현되었으며, @Override 어노테이션으로 인터페이스 계약을 명시적으로 준수하고 있습니다.

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

6-16: LGTM!

Redis 키 접두사와 설명을 캡슐화한 깔끔한 enum 설계입니다. Lombok 어노테이션 사용이 적절하며, 일관된 키 네이밍 컨벤션(ranking:{type})이 Redis ZSET 기반 랭킹 시스템에 잘 부합합니다.

apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsRepository.java (1)

11-14: LGTM!

배치 업데이트 메서드 추가가 적절합니다. Kafka 배치 리스너에서 집계된 델타값을 효율적으로 처리하기 위한 설계가 잘 반영되어 있습니다. 메서드 네이밍이 명확하고 일관성 있습니다.

apps/commerce-api/src/main/java/com/loopers/domain/order/event/OrderCreatedEvent.java (1)

14-21: items 리스트의 null 안전성 확인 필요

items 필드가 null로 전달될 경우 downstream 컨슈머에서 NPE가 발생할 수 있습니다. 팩토리 메서드에서 null 체크 또는 빈 리스트 기본값 처리를 고려해 주세요.

🔎 제안된 수정

     public static OrderCreatedEvent of(
             Long orderId,
             Long userId,
             BigDecimal totalPrice,
             PaymentType paymentType,
             List<OrderItem> items
     ) {
         return new OrderCreatedEvent(
                 orderId,
                 userId,
                 totalPrice,
                 paymentType,
-                items,
+                items != null ? items : List.of(),
                 LocalDateTime.now()
         );
     }

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

161-168: LGTM - 주문 아이템 매핑 로직

savedOrder.getOrderItems()에서 OrderCreatedEvent.OrderItem으로의 변환이 깔끔합니다. 단, item.getPrice()가 null일 경우 NPE 가능성이 있으니 확인해 주세요.

apps/commerce-api/src/main/java/com/loopers/application/outbox/OutboxEventPublisher.java (1)

94-94: LGTM!

PRODUCT_VIEW aggregate type에 대한 토픽 매핑이 적절하게 추가되었습니다. ProductEventPublisher의 outbox 기반 이벤트 발행과 일관성 있게 연동됩니다.

apps/commerce-collector/src/main/java/com/loopers/CommerceCollectorApplication.java (1)

6-9: LGTM!

@EnableScheduling 추가로 RankingScheduler 등 스케줄링 기반 컴포넌트가 정상 동작할 수 있습니다. 적절한 변경입니다.

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

9-17: LGTM - 팩토리 메서드 설계 확인

from() 메서드에서 null 입력 시 null을 반환하는 설계가 JSON 직렬화 시 필드 생략 목적이라면 적절합니다. 다만, 호출부에서 null 체크가 필요할 수 있으니 사용 패턴을 확인해 주세요.

apps/commerce-collector/src/main/java/com/loopers/domain/eventhandled/EventHandledRepository.java (1)

8-8: 배치 저장 메서드 추가 승인

배치 이벤트 처리를 위한 saveAll 메서드가 적절하게 추가되었습니다. 이는 Spring Data Repository 패턴과 일관성이 있으며, PR에서 도입된 배치 처리 워크플로우를 잘 지원합니다.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/dto/ProductLikeEvent.java (1)

3-8: 간결한 이벤트 DTO 설계 승인

불변성을 제공하는 record를 사용한 이벤트 DTO 설계가 적절합니다. 배치 이벤트 처리 패턴에 잘 부합하며, 필드 구성도 합리적입니다.

apps/commerce-collector/src/main/java/com/loopers/infrastructure/eventhandled/EventHandledRepositoryImpl.java (1)

25-28: 배치 저장 구현 승인

JPA Repository에 위임하는 간결한 구현이 적절합니다. void 반환 타입은 호출자가 저장된 엔티티를 필요로 하지 않는 경우 효율적입니다.

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

16-25: 가격 필드는 엔티티 레벨에서 필수 검증이 적용되어 있습니다

Product 엔티티의 생성자에서 validationPrice() 메서드로 price가 null이면 CoreException을 발생시킵니다(lines 99-102). 따라서 product.getPrice().getAmount()는 NPE 위험이 없으며, 현재 코드는 안전합니다.

Likely an incorrect or invalid review comment.

apps/commerce-collector/src/main/java/com/loopers/application/product/ProductEventHandler.java (1)

1-40: 파사드 패턴 마이그레이션이 올바르게 적용되었습니다.

도메인 서비스에서 애플리케이션 파사드로의 전환이 일관되게 적용되었으며, 멱등성 체크 → 메트릭 증가 → 이벤트 처리 완료 기록의 흐름이 유지되고 있습니다.

apps/commerce-collector/src/main/java/com/loopers/application/order/OrderEventHandler.java (1)

1-65: 파사드 마이그레이션 및 주문 수량 처리가 올바르게 반영되었습니다.

도메인 서비스에서 애플리케이션 파사드로의 전환이 일관되게 적용되었으며, incrementOrderCount에 수량 파라미터가 추가되어 주문 집계가 더 정확해졌습니다.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/like/ProductLikeBatchEventConsumer.java (1)

44-48: 잘못된 메시지 처리 전략 확인 필요

파싱에 실패한 메시지는 null로 변환되어 필터링됩니다. 이는 해당 메시지가 영구적으로 손실됨을 의미합니다. 만약 일시적인 파싱 오류(예: ObjectMapper 설정 불일치)라면 DLQ(Dead Letter Queue)로 라우팅하거나 별도로 기록하는 것이 좋습니다.

현재 배치 내 일부 메시지만 성공하고 나머지는 스킵되는 부분 성공 시나리오가 의도된 동작인지 확인해주세요.

apps/commerce-collector/src/main/java/com/loopers/application/eventhandled/EventHandledFacade.java (1)

1-58: 이벤트 처리 상태 관리 파사드가 잘 설계되었습니다.

멱등성 체크와 배치 처리를 모두 지원하며, 적절한 트랜잭션 경계와 null 안전성 검사가 포함되어 있습니다. 배치 처리 메서드는 대량 이벤트 처리 시 성능 향상에 기여합니다.

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsDailyFacade.java (1)

1-42: 일일 메트릭 배치 업데이트 파사드가 적절히 구현되었습니다.

Propagation.REQUIRED를 사용하여 상위 트랜잭션에 참여함으로써 이벤트 처리와 메트릭 업데이트 간의 원자성을 보장합니다. 세 가지 메트릭 타입(좋아요, 조회, 주문)에 대한 일관된 인터페이스를 제공합니다.

apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDaily.java (2)

14-19: 일일 메트릭 중복 방지가 올바르게 구현되었습니다.

(product_id, metric_date)에 대한 유니크 제약 조건이 일별 메트릭 레코드의 중복을 방지합니다. Upsert 연산과 함께 사용하면 멱등성을 보장할 수 있습니다.

---

59-69: 이 메서드들은 코드에서 사용되지 않으므로 동시성 제어 검토가 불필요합니다.

addLikeDelta, addViewDelta, addOrderDelta 메서드는 ProductMetricsDaily 엔티티에 정의되어 있지만 실제로는 어디서도 호출되지 않습니다. 실제 배치 업데이트는 ProductMetricsDailyFacade를 통해 ProductMetricsDailyRepository의 upsert 메서드를 직접 호출하며, 이 메서드들은 MySQL의 ON DUPLICATE KEY UPDATE 원자적 연산을 사용합니다. (product_id, metric_date) 고유 제약으로 인해 동시 실행 시에도 원자성이 보장되므로 lost update 문제는 발생하지 않습니다.

Likely an incorrect or invalid review comment.

apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeBatchEventHandler.java (1)

98-99: 애플리케이션이 시작 시 TimeZone.setDefault(TimeZone.getTimeZone("Asia/Seoul"))로 기본 타임존을 명시적으로 설정하므로, 명시적인 ZoneId 지정은 불필요합니다. 현재 코드는 RankingScheduler, RankingFacade, OrderBatchEventHandler 등 애플리케이션 전체에서 일관되게 사용되는 패턴을 따르고 있습니다.

Likely an incorrect or invalid review comment.

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

19-55: 입력 유효성 검증 및 페이지네이션 로직 확인

limit, page, size 파라미터에 대한 유효성 검증과 offset 계산 로직이 적절하게 구현되어 있습니다.

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

6-47: 레코드 구조 및 팩토리 메서드 구현 적절

RankingInfo와 중첩 레코드 ProductRankings의 구조가 명확하고, null 처리 로직(모든 랭킹이 null이면 전체를 null로 반환)이 API 응답의 일관성을 위해 적절하게 구현되어 있습니다.

apps/commerce-collector/src/main/java/com/loopers/application/product/ProductBatchEventHandler.java (1)

31-55: 전체적인 배치 처리 로직 적절

트랜잭션 경계 내에서 필터링, 중복 제거, 델타 계산, 메트릭 업데이트, 이벤트 처리 완료 마킹까지의 흐름이 명확하게 구현되어 있습니다. 예외 발생 시 롤백을 위한 RuntimeException 래핑도 적절합니다.

apps/commerce-collector/src/main/java/com/loopers/infrastructure/metrics/ProductMetricsRepositoryImpl.java (2)

47-54: like_count 음수 방지 로직 확인

INSERT 시 GREATEST(?, 0)로 음수를 방지하고 있으나, UPDATE 시에는 like_count = like_count + VALUES(like_count)로 델타를 직접 더합니다. 취소 이벤트로 인해 음수 델타가 전달되고 like_count가 해당 값보다 작을 경우, 결과가 음수가 될 수 있습니다.

🔎 음수 방지 수정 제안

             ON DUPLICATE KEY UPDATE
-                like_count = like_count + VALUES(like_count),
+                like_count = GREATEST(like_count + VALUES(like_count), 0),
                 updated_at = NOW()

---

41-73: 배치 업서트 패턴 구현 적절

빈 맵 체크, BatchPreparedStatementSetter 활용, 로깅 등 배치 업서트 패턴이 일관되게 잘 구현되어 있습니다. 다만, ON DUPLICATE KEY UPDATE 구문은 MySQL 전용이므로 데이터베이스 이식성이 필요할 경우 고려가 필요합니다.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/product/ProductBatchEventConsumer.java (2)

45-53: 이벤트 타입 필터링 위치 검토

기존 ProductEventConsumer는 PRODUCT_VIEWED 이벤트만 처리하도록 필터링하지만, 이 배치 컨슈머는 모든 이벤트를 핸들러로 전달합니다. 핸들러의 calculateDelta에서 PRODUCT_VIEWED가 아닌 경우 0을 반환하지만, 해당 이벤트도 "처리 완료"로 마킹됩니다.

이것이 의도된 동작이라면 문제 없으나, PRODUCT_VIEWED 외의 이벤트가 product 토픽에 발행될 경우를 대비하여 컨슈머 레벨에서 필터링을 추가하는 것도 고려해 볼 수 있습니다.

---

65-96: 메시지 파싱 및 유효성 검증 로직 적절

필수 필드 검증, 파싱 실패 시 null 반환 및 경고 로깅 등 방어적 프로그래밍이 잘 적용되어 있습니다. ProductLikeBatchEventConsumer와 동일한 패턴을 따르고 있어 일관성이 유지됩니다.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderBatchEventConsumer.java (2)

86-96: JSON 파싱 실패 처리 - LGTM

파싱 실패 시 null을 반환하고 로그만 남기는 방식은 poison pill 메시지를 적절히 처리합니다. 재시도가 불필요한 메시지를 스킵하여 배치 전체가 실패하는 것을 방지합니다.

---

28-32: 배치 리스너 설정이 올바르게 구성되어 있습니다.

KafkaConfig.BATCH_LISTENER는 MAX_POLL_RECORDS_CONFIG가 3000으로 설정되어 있고, 동시성이 3으로 구성되어 있으며, 수동 승인(MANUAL) 모드가 적절하게 적용되어 있습니다. BatchMessagingMessageConverter도 올바르게 설정되어 배치 메시지 처리에 문제가 없습니다.

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

127-138: 일자별 데이터 정리 로직 - LGTM

10일 이전 데이터 삭제 로직이 적절합니다. 에러 핸들링과 로깅도 잘 구현되어 있습니다.

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

64-102: 랭킹 DTO 추가 - LGTM

RankingResponse와 SimpleRankingResponse 레코드가 null 안전하게 구현되었으며, 기존 DTO 패턴(BrandV1Dto.BrandResponse)과 일관성 있는 구조입니다.

---

36-51: ProductDetailResponse 랭킹 필드 추가 - LGTM

rankings 필드 추가와 매핑 로직이 적절합니다. null 체크를 통해 랭킹 정보가 없는 경우도 안전하게 처리됩니다.

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

91-107: Redis 파이프라인 구현 - LGTM

SessionCallback을 사용한 파이프라인 처리로 Redis 호출 횟수를 최소화한 좋은 구현입니다. TTL 설정도 파이프라인 내에서 함께 처리됩니다.

apps/commerce-collector/src/main/java/com/loopers/application/like/ProductLikeEventHandler.java (2)

3-16: Facade 패턴으로의 리팩토링 - LGTM

EventHandledService → EventHandledFacade, ProductMetricsService → ProductMetricsFacade로의 변경이 일관되게 적용되었습니다. 멱등성 체크와 이벤트 처리 흐름이 유지됩니다.

---

21-36: 좋아요 이벤트 처리 로직 - LGTM

handleLikeAdded와 handleLikeRemoved 메서드가 멱등성 체크, 메트릭 업데이트, 이벤트 처리 완료 기록의 순서로 올바르게 구현되어 있습니다. 학습된 내용에 따르면, Like 이벤트는 productId를 aggregateId로 사용하여 파티션 순서를 보장합니다.

Also applies to: 41-56

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/RedisRankingRepository.java (2)

32-45: TOP N 랭킹 조회 - LGTM

ZREVRANGE를 사용한 점수 내림차순 조회가 올바르게 구현되었습니다. 빈 결과에 대한 처리도 적절합니다.

---

81-103: 단일 상품 랭킹 조회 - LGTM

점수와 순위를 각각 조회하여 Ranking 객체를 생성하는 로직이 적절합니다. null 체크도 잘 되어 있습니다.

apps/commerce-collector/src/main/java/com/loopers/application/order/OrderBatchEventHandler.java (2)

78-92: ORDER_CREATED 외 이벤트 타입 처리

aggregateOrderQuantities에서 ORDER_CREATED가 아닌 이벤트는 경고 로그만 남기고 스킵합니다. 이 동작이 의도된 것인지 확인이 필요합니다. 만약 다른 주문 이벤트(ORDER_COMPLETED, ORDER_CANCELLED 등)도 처리해야 한다면 별도 로직이 필요합니다.

---

30-61: 배치 처리 흐름 - LGTM

전체적인 배치 처리 흐름이 적절합니다:

1. 미처리 이벤트 필터링
2. 중복 제거
3. 주문 수량 집계
4. 메트릭 업데이트
5. 이벤트 처리 완료 기록

트랜잭션 내에서 모든 작업이 원자적으로 처리되며, 실패 시 전체 롤백됩니다. 학습된 내용에 따르면 JPA dirty checking을 활용한 패턴과 일관됩니다.

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

40-84: LGTM! Cache-Aside 패턴과 랭킹 통합이 잘 구현되었습니다.

캐시 히트/미스 양쪽 경로에서 이벤트 발행이 올바르게 처리되고 있으며, 랭킹 정보 조회 및 ProductDetailInfo 구성 로직이 명확합니다.

한 가지 참고 사항: 캐시된 ProductDetailInfo에 랭킹 정보가 포함되어 있어 TTL(5분) 동안 랭킹이 변경되어도 반영되지 않습니다. 실시간 랭킹이 중요하다면 랭킹 정보를 별도로 조회하는 것을 고려해 볼 수 있습니다.

apps/commerce-collector/src/main/java/com/loopers/interfaces/consumer/order/OrderEventConsumer.java (1)

17-18: 단건 처리 컨슈머 비활성화 확인.

배치 리스너로 전환하면서 @Component를 주석 처리한 것으로 보입니다. 향후 유지보수를 위해 이 클래스를 완전히 제거하거나, 필요 시 재활성화할 수 있도록 명확한 주석을 추가하는 것을 고려해 주세요.

apps/commerce-collector/src/main/java/com/loopers/application/metrics/ProductMetricsFacade.java (1)

43-56: 배치 업데이트 API 추가가 잘 되어 있습니다.

Propagation.REQUIRED를 사용하여 상위 트랜잭션에 참여하는 설계가 ProductMetricsDailyFacade와 일관됩니다. Repository의 upsert 메서드로 위임하는 방식도 깔끔합니다.

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

28-52: 랭킹 조회 메서드들의 구조가 명확합니다.

getTopRanking과 getRankingWithPaging 메서드가 빈 결과에 대해 early return하고, enrichWithProductInfo로 상품 정보를 보강하는 패턴이 일관됩니다.

단, 위에서 지적한 enrichWithProductInfo의 NPE 버그 수정이 필요합니다.

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

15-58: 요청 DTO의 기본값 처리가 잘 되어 있습니다.

Record의 compact constructor를 활용하여 limit, page, size에 기본값을 설정하는 패턴이 적절합니다. @Min/@Max 검증 어노테이션도 올바르게 적용되어 있습니다.

---

83-127: 응답 DTO 구조가 깔끔합니다.

TopRankingResponse와 PagingRankingResponse의 정적 팩토리 메서드가 도메인 객체에서 DTO로의 변환을 명확하게 처리하고 있습니다. totalPages 계산 로직도 @Min(1) 검증으로 인해 0 나눗셈 문제가 없습니다.

apps/commerce-collector/src/main/java/com/loopers/domain/metrics/ProductMetricsDailyRepository.java (1)

8-21: 리포지토리 인터페이스 설계가 적절합니다.

도메인 계층에서 인프라 구현을 분리하는 좋은 설계입니다. CRUD, 배치 upsert, 정리(cleanup) 메서드가 명확하게 정의되어 있으며, 반환 타입도 적절합니다 (Optional for single find, int for delete count).

[HongChangMo]

@coderabbitai 아래의 체크리스트를 만족하는지 확인해줘

📈 Ranking Consumer

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

⚾ Ranking API

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

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check TTL and key strategy in RankingFacade (commerce-collector)
echo "=== RankingFacade TTL and Key Strategy ==="
cat apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingFacade.java | head -80

echo ""
echo "=== Application YAML ranking configuration ==="
cat apps/commerce-collector/src/main/resources/application.yml | grep -A 10 "ranking:"

echo ""
echo "=== RedisRankingRepository buildRankingKey method ==="
cat apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/RedisRankingRepository.java | grep -A 15 "buildRankingKey"

echo ""
echo "=== RankingScheduler processing and update logic ==="
cat apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingScheduler.java | grep -A 30 "processUnprocessedDeltas"

echo ""
echo "=== RankingV1Controller getRankingWithPaging endpoint ==="
cat apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java | grep -A 20 "getRankingWithPaging"

echo ""
echo "=== RankingFacade (commerce-api) enrichWithProductInfo ==="
cat apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java | grep -A 30 "enrichWithProductInfo"

echo ""
echo "=== ProductFacade product detail with ranking ==="
cat apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java | grep -A 40 "getProductDetail"

Length of output: 12352

---

🏁 Script executed:

#!/bin/bash
# Check if TTL is actually applied in incrementRanking method
echo "=== RankingFacade incrementRanking method (TTL application) ==="
cat apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingFacade.java | grep -A 60 "private void incrementRanking"

echo ""
echo "=== Check incrementRankingWithCompositeScores for TTL ==="
cat apps/commerce-collector/src/main/java/com/loopers/application/ranking/RankingFacade.java | grep -A 60 "incrementRankingWithCompositeScores"

Length of output: 6341

---

@HongChangMo 체크리스트를 검증한 결과를 공유드립니다:

📈 Ranking Consumer

• 랭킹 ZSET 의 TTL, 키 전략을 적절하게 구성하였다

  • ✅ TTL: application.yml에서 ranking.ttl-days: 2로 설정되어 있으며, RankingFacade의 incrementRanking 메서드에서 operations.expire(todayKey, rankingTtlDays, TimeUnit.DAYS)로 적용됩니다
  • ✅ 키 전략: ranking:{type}:yyyyMMdd 형식 사용 (예: ranking:like:20251226)
  • ✅ 4가지 타입별 prefix 정의: ranking:like, ranking:view, ranking:order, ranking:all

• 날짜별로 적재할 키를 계산하는 기능을 만들었다

  • ✅ RedisRankingRepository.buildRankingKey(RankingType, LocalDate) 메서드 구현
  • ✅ RankingFacade에서 prefix + ":" + LocalDate.now().format(DATE_FORMATTER) 형식으로 오늘 날짜 키 생성
  • ✅ DATE_FORMATTER: yyyyMMdd 패턴 사용

• 이벤트가 발생한 후, ZSET 에 점수가 적절하게 반영된다

  • ✅ 이벤트 흐름: Kafka 배치 컨슈머 → ProductMetricsDailyFacade (일별 증감 저장) → RankingScheduler (5분마다 실행) → RankingFacade.incrementXXXRanking → Redis ZSET 업데이트
  • ✅ 가중치 적용: like 0.2, view 0.1, order 0.6
  • ✅ zSetOps.incrementScore() 사용하여 점수 증분 업데이트

⚾ Ranking API

• 랭킹 Page 조회 시 정상적으로 랭킹 정보가 반환된다

  • ✅ RankingV1Controller.getRankingWithPaging 엔드포인트 구현
  • ✅ PagingRankingResponse 반환: rankings, currentPage, pageSize, totalCount, totalPages 포함
  • ✅ 페이지네이션 검증: page >= 0, size: 1-100

• 랭킹 Page 조회 시 단순히 상품 ID 가 아닌 상품정보가 Aggregation 되어 제공된다

  • ✅ RankingFacade.enrichWithProductInfo 메서드에서 productService.getAllByIdIn(productIds)로 배치 조회
  • ✅ RankingInfo에 ProductInfo 포함
  • ✅ 응답의 RankingItem에 rank, productId, product(상품 상세정보), score 모두 포함

• 상품 상세 조회 시 해당 상품의 순위가 함께 반환된다 (순위에 없다면 null)

  • ✅ ProductFacade.getProductDetail에서 rankingFacade.getAllRankingsForProduct(productId, null) 호출
  • ✅ ProductDetailInfo.of(product, rankings) 로 랭킹 정보 포함하여 반환
  • ✅ getAllRankingsForProduct는 4가지 타입(like, view, order, all)의 랭킹을 조회하며, 모든 랭킹이 없으면 null 반환

모든 체크리스트 항목이 충족되었습니다! 🎉