[volume-9] Product Ranking with Redis #215

junoade · 2025-12-26T04:12:38Z

📌 Summary

연말 일정이 조금 무리가 되어서
이벤트 에 대한 카프카 컨슘시, 레디스를 활용한 랭킹 집계/ 조회 API 추가 등의 과정 경험을 목표로,
단건 메시지 컨슘 해서 Zset에 랭킹 적재 하도록 하고 그 외 요구사항들을 구현하였습니다.

랭킹 ZSET 및 키 전략

ProductLike 이벤트에 대해서 weight=0.2, score = weight * 1 로 계산하여 zset에 집계
TTL : 2Day / Key: ranking:all:{yyyyMMdd}

컨슈머 메시지 처리 및 집계

(초기) streamer 모듈에 랭킹 집계 서비스 구현 및 컨슈머 리스너에 단일 메시지 단건 처리

Carry over 구현 등

💬 Review Points

멀티모듈 구조에서 다양한 컨슈머 서비스, 레디스를 사용하는 호출 주체가 늘어남에 따라

한 DTO를 여러 군데서 정의하고 사용하게 되는 케이스가 생길 것으로 보았는데 혹시 관련되어 실무에서는 어떻게 해결하시는 걸 선호하시는지와 관련된 키워드 들을 알 수 있을까요?

저희 회사에서는 호출 주체의 프로젝트 환경에 동일한 DTO를 정의하고 소스 DTO가 변경되면 업무연락 등을 통해 다같이 변경일정을 맞추는 방식으로 하고 있습니다.. (e.g 계정계 DTO <-> 인터넷 앱 서비스 내 DTO , 모바일 앱 서비스내 DTO 등 n개 존재)

✅ Checklist

📈 Ranking Consumer

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

⚾ Ranking API

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

📎 References

Summary by CodeRabbit

Release Notes

New Features
- 일일 인기 상품 조회 API 추가
- 상품 상세 정보에 순위 점수 포함
- 좋아요 이벤트 기반 순위 자동 집계 및 일일 누적
Tests
- Kafka 테스트 환경 개선
- 순위 집계 기능 테스트 추가

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

1. kafka.yml 에 기재된 testImplementation(testFixtures(project(":modules:kafka"))) 에 대한 설정 코드들을 추가. 2. 그 후 테스트 코드 수행시, - 스프링컨텍스트, 카프카 토픽, 컨슈머그룹, 컨슈머 등 생성 -> 테스트 될 수 있도록 설정 - @beforeeach 시 아래와 같이 떳고, 이는 컨슈머 컨테이너가 먼저 떠서 토픽 메타데이터를 조회하는데, 그 시점에 토픽이 없기 때문이다. ``` org.apache.kafka.clients.NetworkClient : [Consumer clientId=commerce-streamer-0, groupId=loopers-default-consumer] Error while fetching metadata with correlation id 2 : {order-events=UNKNOWN_TOPIC_OR_PARTITION} ```

> 일단 돌아가게 구현 1. 초기 랭킹 ZSET 및 키 전략 - ProductLike 이벤트에 대해서 weight=0.2, score = weight * 1 로 계산하여 zset에 집계 - TTL : 2Day / Key: ranking:all:{yyyyMMdd} 2. 컨슈머 메시지 처리 및 집계 - (초기) streamer 모듈에 랭킹 집계 서비스 구현 및 컨슈머 리스너에 단일 메시지 단건 처리

Week9 feature redis 초기구현

> 일단 돌아가게 구현

오늘 ZSET 점수를 0.1 가중치로 내일 키로 복사하고 TTL을 설정

- Redis에서 EXPIRE는 쓰기 연산이다. - 네트워크 RTT - 매번 ZINCRBY + EXPIRE = 왕복 2번 - Kafka 이벤트당 1~2 RTT → TPS 높아질수록 체감

Week9 feature redis

coderabbitai · 2025-12-26T04:12:48Z

Walkthrough

일일 상품 순위 시스템을 구현합니다. Redis ZSET 기반으로 좋아요 이벤트를 추적하고, 매일 정해진 시간에 점수를 이월합니다. REST API를 통해 순위 데이터를 조회하고, 상품 상세 조회에 순위 점수를 포함합니다. Kafka 테스트 인프라를 개선합니다.

Changes

순위 지정 매장 / 파일	변경 요약
Redis 순위 모듈 `modules/redis/src/main/java/com/loopers/ranking/RankingEntry.java`, `DailyRankingResponse.java`, `RankingKey.java`, `RankingPolicy.java`, `RankingZSetRepository.java`	순위 데이터를 나타내는 신규 레코드 타입(`RankingEntry`, `DailyRankingResponse`)과 Redis ZSET 리포지토리(`RankingZSetRepository`) 추가. `RankingKey`를 통한 일일 순위 키 생성.
Commerce API 순위 서비스 계층 `apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryResponse.java`, `RankingQueryService.java`	`RankingQueryResponse` 레코드와 `RankingQueryService` 추가. 일일 인기 상품 조회 및 상품 순위 점수 조회 기능 제공.
Commerce API 순위 REST 엔드포인트 `apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java`	`/api/v1/ranking` GET 엔드포인트 추가. 선택적 날짜 및 크기 파라미터로 일일 순위 조회.
Commerce API 상품 통합 `apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Controller.java`, `ProductV1Dto.java`	`ProductDetailResponse`에 `rankingScore` 필드 추가. 상품 상세 조회 시 순위 점수 포함.
Commerce Streamer 순위 집계 `apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingAggregationService.java`	일일 순위 점수 증가(`applyLike`) 및 정일 순위 이월(`carryOverDailyRanking`) 기능. 23:30에 자동 예약되어 이전 날짜 점수를 가중치 0.1로 이월.
Commerce Streamer 이벤트 처리 `apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/ProductLikeEventConsumer.java`	`RankingAggregationService` 의존성 추가. 상품 좋아요 이벤트 처리 시 순위 집계 호출.
Kafka 테스트 인프라 `modules/kafka/src/testFixtures/java/com/loopers/testcontainers/KafkaTestContainersConfig.java`, `com/loopers/utils/KafkaCleanUp.java`, `modules/kafka/src/main/resources/kafka.yml`	Testcontainers 기반 Kafka 테스트 설정 클래스 및 토픽/컨슈머 그룹 정리 유틸리티 추가. Kafka 부트스트랩 서버 환경변수화.
통합 테스트 `apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingAggregationServiceTest.java`, `apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java`	순위 이월 로직 테스트 및 Kafka 테스트 인프라 통합. Testcontainers 기반 설정으로 마이그레이션.

Sequence Diagram(s)

sequenceDiagram
    participant PLE as ProductLikeEvent
    participant Consumer as ProductLikeEventConsumer
    participant RAS as RankingAggregationService
    participant Redis as Redis ZSET
    participant Scheduler as Scheduler (23:30)

    PLE->>Consumer: 좋아요 이벤트 수신
    Consumer->>RAS: applyLike(productId, occurredAt)
    RAS->>Redis: ZSET 점수 증가 (0.2 LIKE_WEIGHT)
    Redis-->>RAS: 완료
    RAS->>Redis: 일일 키 TTL 설정 (2일)

    rect rgb(200, 220, 250)
    Note over Scheduler,Redis: 매일 23:30 실행
    Scheduler->>RAS: carryOverDailyRanking()
    RAS->>Redis: ZUNIONSTORE (가중치: 0.1)
    RAS->>Redis: 내일 키 TTL 설정
    Redis-->>RAS: 이월 완료
    end

sequenceDiagram
    participant Client as 클라이언트
    participant Controller as ProductV1Controller
    participant RankingService as RankingQueryService
    participant ProductService as ProductQueryService
    participant Redis as Redis

    Client->>Controller: 상품 상세 조회 요청
    Controller->>RankingService: getDailyRankingScore(productId)
    RankingService->>Redis: 일일 순위 점수 조회
    Redis-->>RankingService: 점수 반환
    
    Controller->>ProductService: 상품 상세 정보 조회
    ProductService-->>Controller: 상품 정보 반환
    
    Controller-->>Client: ProductDetailResponse (content + rankingScore)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

[volume - 8] Decoupling with Kafka #195: 동일한 Kafka 테스트 인프라 파일 추가 (KafkaTestContainersConfig, KafkaCleanUp) — 직결된 변경.
[volume-5] 인덱스 및 Redis 캐시 적용 #145: 상품 API 레이어 변경 — ProductV1Controller, ProductDetailResponse에 순위/좋아요 정보 포함.
[volume - 8] Decoupling with Kafka #193: Kafka 통합 및 테스트 유틸리티 수정 — KafkaTestContainersConfig, kafka.yml, KafkaCleanUp 등 동일 파일 변경.

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 29.03% 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

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

coderabbitai

Actionable comments posted: 5

🧹 Nitpick comments (13)

modules/redis/src/main/java/com/loopers/ranking/RankingPolicy.java (1)

1-7: 빈 플레이스홀더 클래스 - 구현 필요

현재 RankingPolicy 클래스는 주석만 있고 구현이 없는 플레이스홀더입니다. PR 요구사항에 따르면 이벤트 타입별로 가중치를 결정하는 로직이 필요합니다 (예: ProductLike → 0.2, 일일 이월 → 0.1).

다음과 같은 구현 방식을 고려해보세요:

Enum 기반: 각 이벤트 타입에 가중치를 매핑

Strategy 패턴: 인터페이스와 구현체로 분리

정적 상수/메서드: 간단한 매핑 로직

구현 코드를 생성하거나, 이 작업을 추적하기 위한 이슈를 생성해드릴까요?

modules/kafka/src/main/resources/kafka.yml (1)

18-18: TODO 주석을 해결하거나 이슈로 추적하는 것을 고려하세요.

프로듀서의 acks, enable.idempotence, max.in.flight.requests.per.connection 설정은 메시지 전송 신뢰성과 순서 보장에 중요한 영향을 미칩니다. 현재 설정이 프로젝트 요구사항에 적합한지 검토하고, TODO를 제거하거나 별도 이슈로 추적하는 것을 권장합니다.

이 설정들에 대한 권장 구성을 제안하거나 관련 문서를 찾아드릴까요?
apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Controller.java (1)
7-7: 미사용 import를 제거하세요.

RankingEntry import가 사용되지 않습니다. Line 49에서 사용하는 타입은 OptionalDouble입니다.
🔎 제안하는 수정
-import com.loopers.ranking.RankingEntry;
apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java (1)

44-44: 주석 처리된 코드의 의도를 명확히 하세요.

resetAllTestTopics() 호출이 주석 처리되어 있습니다. 의도적인 변경인지 확인이 필요합니다. 토픽 리셋이 불필요한 경우 주석이 아닌 완전히 제거하는 것을 권장합니다.
apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Dto.java (2)
3-3: 미사용 import를 제거하세요.

RankingEntry import가 이 파일에서 사용되지 않습니다.
🔎 제안하는 수정
-import com.loopers.ranking.RankingEntry;
36-38: null 대신 OptionalDouble.empty()를 사용하는 것을 고려하세요.

rankingScore가 없을 때 null을 반환하는 대신 OptionalDouble.empty()를 사용하면 의미가 더 명확해집니다.
🔎 제안하는 수정
         static <T> ProductDetailResponse<T> of(T content) {
-            return new ProductDetailResponse<>(content, null);
+            return new ProductDetailResponse<>(content, OptionalDouble.empty());
         }
modules/redis/src/main/java/com/loopers/ranking/RankingKey.java (1)
11-16: Javadoc을 완성하세요.

메소드의 @param과 @return 태그에 설명이 누락되어 있습니다. 각 파라미터와 반환값의 의미를 명확히 문서화하세요.
🔎 제안하는 수정
     /**
      * 일별 랭킹 레디스키를 정의합니다.
      * ranking:all:{yyyyMMdd}
-     * @param date
-     * @return
+     * @param date 랭킹을 조회할 날짜
+     * @return Redis에 저장할 일별 랭킹 키 (형식: ranking:all:yyyyMMdd)
      */
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java (1)
18-24: 응답 래퍼 일관성 검토 필요

ProductV1Controller는 ApiResponse<>로 응답을 감싸고 있지만, 이 컨트롤러는 RankingQueryResponse를 직접 반환합니다. API 응답 형식의 일관성을 위해 동일한 패턴을 적용하는 것이 좋습니다.
🔎 제안된 수정
-    public RankingQueryResponse getDailyRanking(
+    public ApiResponse<RankingQueryResponse> getDailyRanking(
             @RequestParam(required = false, name = "date") String date,
             @RequestParam(defaultValue = "20", name = "size") int size
     ) {
-        return rankingQueryService.getDailyPopularProducts(date, size);
+        return ApiResponse.success(rankingQueryService.getDailyPopularProducts(date, size));
     }
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryResponse.java (1)
9-16: 필드 명명 일관성: 복수형 사용 권장

productLikeSummary 필드가 List<ProductLikeSummary>를 담고 있으므로, 복수형 productLikeSummaries로 명명하는 것이 더 명확합니다.
🔎 제안된 수정
 public record RankingQueryResponse(
         LocalDate date,
         List<RankingEntry> rankingEntries,
-        List<ProductLikeSummary> productLikeSummary
+        List<ProductLikeSummary> productLikeSummaries
 ) {
-    public static RankingQueryResponse of(LocalDate date, List<RankingEntry> rankingEntries, List<ProductLikeSummary> productLikeSummary) {
-        return new RankingQueryResponse(date, rankingEntries, productLikeSummary);
+    public static RankingQueryResponse of(LocalDate date, List<RankingEntry> rankingEntries, List<ProductLikeSummary> productLikeSummaries) {
+        return new RankingQueryResponse(date, rankingEntries, productLikeSummaries);
     }
 }
modules/redis/src/main/java/com/loopers/ranking/RankingZSetRepository.java (1)

30-33: TODO 코멘트 해결 필요

"랭킹정보가 없다면?" TODO가 남아있습니다. 빈 리스트를 반환하는 현재 동작이 의도된 것인지, 아니면 추가 처리가 필요한지 명확히 해주세요.

이 TODO를 해결하거나 새로운 이슈로 등록해 드릴까요?
apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingAggregationService.java (1)
23-32: 타임존 명시적 지정 권장

ZoneId.systemDefault()는 서버 환경에 따라 다른 결과를 반환할 수 있어 분산 시스템에서 일관성 문제가 발생할 수 있습니다. 서비스 지역에 맞는 명시적 타임존(예: ZoneId.of("Asia/Seoul")) 사용을 권장합니다.
🔎 제안된 수정
+    private static final ZoneId SERVICE_ZONE = ZoneId.of("Asia/Seoul");
+
     public void applyLike(long productId, Instant occurredAt) {
-        LocalDate day = occurredAt.atZone(ZoneId.systemDefault()).toLocalDate();
+        LocalDate day = occurredAt.atZone(SERVICE_ZONE).toLocalDate();
         String key = RankingKey.dailyAll(day);
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryService.java (1)
54-56: 메서드 명명이 혼란스럽습니다

hasValidDate가 날짜가 null이거나 비어있을 때 true를 반환합니다. 이름이 로직과 반대입니다. isNullOrBlank 또는 shouldUseDefaultDate와 같이 의도를 명확히 하는 이름을 사용하세요.
🔎 제안된 수정
-    private boolean hasValidDate(String date) {
-        return date == null || date.isBlank();
+    private boolean shouldUseDefaultDate(String date) {
+        return date == null || date.isBlank();
     }
modules/kafka/src/testFixtures/java/com/loopers/utils/KafkaCleanUp.java (1)

76-81: Thread.sleep 대신 폴링 방식 고려

Thread.sleep(1000)은 토픽 삭제 완료를 보장하지 않습니다. 토픽 목록에서 삭제되었는지 폴링하는 방식이 더 안정적입니다. 다만, 테스트 유틸리티에서는 현재 접근 방식도 실용적입니다.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ecc5479 and 86dc621.

📒 Files selected for processing (17)

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryResponse.java
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryService.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Controller.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/product/ProductV1Dto.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java
apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingAggregationService.java
apps/commerce-streamer/src/main/java/com/loopers/interfaces/consumer/ProductLikeEventConsumer.java
apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java
apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingAggregationServiceTest.java
modules/kafka/src/main/resources/kafka.yml
modules/kafka/src/testFixtures/java/com/loopers/testcontainers/KafkaTestContainersConfig.java
modules/kafka/src/testFixtures/java/com/loopers/utils/KafkaCleanUp.java
modules/redis/src/main/java/com/loopers/ranking/DailyRankingResponse.java
modules/redis/src/main/java/com/loopers/ranking/RankingEntry.java
modules/redis/src/main/java/com/loopers/ranking/RankingKey.java
modules/redis/src/main/java/com/loopers/ranking/RankingPolicy.java
modules/redis/src/main/java/com/loopers/ranking/RankingZSetRepository.java

🧰 Additional context used

🧠 Learnings (7)

📚 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/ProductLikeEventConsumer.java
apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.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/ProductLikeEventConsumer.java
apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.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/ProductLikeEventConsumer.java

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

Learnt from: kilian-develop
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 190
File: apps/commerce-streamer/src/main/java/com/loopers/applications/streamer/consumer/product/IncreaseProductViewKafkaConsumer.java:25-35
Timestamp: 2025-12-18T13:24:54.339Z
Learning: In this codebase, Kafka consumers delegate error handling and event tracking to the service layer via EventInboxAspect. Service methods annotated with InboxEvent are intercepted by the aspect, which handles failures by saving failed EventInbox entries and logging errors. This centralized approach avoids duplicating error handling logic across multiple consumers.

Applied to files:

apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java

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

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

Applied to files:

apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java
modules/kafka/src/main/resources/kafka.yml

📚 Learning: 2025-12-19T03:23:54.756Z

Learnt from: minor7295
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 191
File: modules/kafka/src/testFixtures/java/com/loopers/testcontainers/KafkaTestContainersConfig.java:24-34
Timestamp: 2025-12-19T03:23:54.756Z
Learning: In the loopers-spring-java-template project, test container configurations (MySQL, Redis, Kafka) use static initialization blocks for consistency across the template. This pattern should be maintained for uniformity, even if alternative lifecycle management approaches exist.

Applied to files:

apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java

📚 Learning: 2025-12-19T03:23:51.674Z

Learnt from: minor7295
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 191
File: modules/kafka/src/testFixtures/java/com/loopers/testcontainers/KafkaTestContainersConfig.java:24-34
Timestamp: 2025-12-19T03:23:51.674Z
Learning: Maintain the use of static initialization blocks in test fixtures for testcontainers configurations (e.g., MySQL, Redis, Kafka) to ensure consistency and predictable initialization across the loopers-spring-java-template project. Apply this pattern to all test-fixture Java files under src/testFixtures/java to preserve uniform lifecycle behavior, unless there's a compelling, well-justified reason to diverge.

Applied to files:

modules/kafka/src/testFixtures/java/com/loopers/utils/KafkaCleanUp.java
modules/kafka/src/testFixtures/java/com/loopers/testcontainers/KafkaTestContainersConfig.java

🧬 Code graph analysis (6)

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

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

RequiredArgsConstructor (19-52)

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

RequiredArgsConstructor (11-26)

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

modules/redis/src/main/java/com/loopers/ranking/RankingKey.java (1)

RankingKey (9-21)

modules/redis/src/main/java/com/loopers/ranking/RankingZSetRepository.java (1)

modules/redis/src/main/java/com/loopers/ranking/RankingKey.java (1)

RankingKey (9-21)

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

modules/redis/src/main/java/com/loopers/ranking/RankingKey.java (1)

RankingKey (9-21)

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

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

RequiredArgsConstructor (19-52)

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

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

RequiredArgsConstructor (11-26)

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

ProductV1Dto (9-44)

🔇 Additional comments (9)

modules/redis/src/main/java/com/loopers/ranking/RankingEntry.java (1)

1-4: LGTM!

간결하고 명확한 record 정의입니다. 랭킹 데이터를 위한 double 타입 사용도 적절합니다.

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

47-51: LGTM!

랭킹 점수를 상품 상세 정보에 통합하는 로직이 올바르게 구현되었습니다. OptionalDouble을 사용한 nullable 처리도 적절합니다.

modules/redis/src/main/java/com/loopers/ranking/DailyRankingResponse.java (1)

1-7: LGTM!

일별 랭킹 데이터를 담는 간결한 record 정의입니다. LocalDate와 List 조합이 적절합니다.

modules/redis/src/main/java/com/loopers/ranking/RankingKey.java (1)

17-19: LGTM!

Redis 키 생성 로직이 명확하고 올바르게 구현되었습니다. BASIC_ISO_DATE 포맷 사용도 적절합니다.

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

26-26: LGTM!

랭킹 집계 서비스가 깔끔하게 통합되었습니다. 메트릭 집계 후 랭킹 집계를 수행하는 순서가 적절하며, 에러 처리는 기존 패턴대로 aspect에 위임되어 일관성이 유지됩니다.

Also applies to: 47-47

modules/kafka/src/testFixtures/java/com/loopers/testcontainers/KafkaTestContainersConfig.java (1)

28-46: LGTM!

정적 초기화 블록 패턴이 프로젝트의 testcontainers 설정 컨벤션과 일치합니다. 컨테이너 시작, 동적 포트 주입, 토픽 빈 정의가 적절하게 구현되어 있습니다. Based on learnings, 이 패턴은 프로젝트 전반에서 일관되게 유지되어야 합니다.
modules/redis/src/main/java/com/loopers/ranking/RankingZSetRepository.java (1)
35-40: NumberFormatException 처리 필요

ZSET 멤버가 숫자가 아닌 값을 포함할 경우 Long.parseLong()에서 예외가 발생합니다. 방어적 코딩을 위해 예외 처리를 추가하거나, 데이터 정합성이 보장되는지 확인이 필요합니다.
🔎 제안된 수정
         for(ZSetOperations.TypedTuple<String> tuple : tuples) {
             if(tuple.getValue() == null) continue;
-            long productId = Long.parseLong(tuple.getValue());
-            double score = tuple.getScore() == null ? 0d : tuple.getScore();
-            result.add(new RankingEntry(productId, score));
+            try {
+                long productId = Long.parseLong(tuple.getValue());
+                double score = tuple.getScore() == null ? 0d : tuple.getScore();
+                result.add(new RankingEntry(productId, score));
+            } catch (NumberFormatException e) {
+                // 잘못된 형식의 멤버는 건너뜀
+                continue;
+            }
         }
apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingAggregationServiceTest.java (1)

38-69: 테스트 커버리지 양호

Carry-over 로직의 핵심 시나리오(가중치 적용 및 TTL 설정)를 적절히 검증하고 있습니다. 추가로 엣지 케이스(빈 소스, 기존 타겟 존재 시)에 대한 테스트도 고려해 보세요.

modules/kafka/src/testFixtures/java/com/loopers/utils/KafkaCleanUp.java (1)

31-46: 테스트 격리 유틸리티 설계 양호

KafkaAdmin을 주입받아 동적으로 AdminClient를 생성하는 방식과, 토픽/컨슈머 그룹 관리 메서드들이 잘 구성되어 있습니다. 테스트 환경 격리에 효과적인 유틸리티입니다.

coderabbitai · 2025-12-26T04:16:25Z

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryService.java

+    private List<ProductLikeSummary> findProductSummaryFrom(List<RankingEntry> rankingEntries) {
+        List<ProductLikeSummary> result = new ArrayList<>();
+
+        for(RankingEntry rankingEntry : rankingEntries) {
+            ProductLikeSummary summary;
+            try {
+                summary = productQueryService.getProductLikeSummary(rankingEntry.productId());
+            } catch (CoreException e) {
+                if(e.getErrorType() == ErrorType.NOT_FOUND) {
+                    log.error("Could not find product like summary for {}", rankingEntry.productId());
+                }
+                summary =  null;
+            }
+            result.add(summary);
+        }
+        return result;
+    }


⚠️ Potential issue | 🟠 Major

N+1 쿼리 패턴 및 null 처리 개선 필요

N+1 쿼리: 각 랭킹 항목마다 개별 DB 조회가 발생합니다. productId 목록으로 일괄 조회하는 것이 효율적입니다.

Null 처리: 찾지 못한 상품에 대해 null을 리스트에 추가하면 클라이언트에서 NPE가 발생할 수 있습니다. 필터링하거나 명시적인 "삭제됨" 표시를 사용하세요.

예외 처리: NOT_FOUND가 아닌 다른 예외도 무시되고 있습니다.

🔎 제안된 수정

private List<ProductLikeSummary> findProductSummaryFrom(List<RankingEntry> rankingEntries) { - List<ProductLikeSummary> result = new ArrayList<>(); - - for(RankingEntry rankingEntry : rankingEntries) { - ProductLikeSummary summary; - try { - summary = productQueryService.getProductLikeSummary(rankingEntry.productId()); - } catch (CoreException e) { - if(e.getErrorType() == ErrorType.NOT_FOUND) { - log.error("Could not find product like summary for {}", rankingEntry.productId()); - } - summary = null; - } - result.add(summary); + List<Long> productIds = rankingEntries.stream() + .map(RankingEntry::productId) + .toList(); + + // TODO: ProductQueryService에 일괄 조회 메서드 추가 고려 + List<ProductLikeSummary> result = new ArrayList<>(); + for (RankingEntry rankingEntry : rankingEntries) { + try { + ProductLikeSummary summary = productQueryService.getProductLikeSummary(rankingEntry.productId()); + result.add(summary); + } catch (CoreException e) { + if (e.getErrorType() == ErrorType.NOT_FOUND) { + log.warn("Product not found for ranking entry: {}", rankingEntry.productId()); + // null 대신 건너뛰기 + } else { + throw e; // NOT_FOUND가 아닌 예외는 전파 + } + } } return result; }

🤖 Prompt for AI Agents

In apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingQueryService.java around lines 65-81, the current loop causes N+1 queries, inserts nulls for missing products and swallows non-NOT_FOUND exceptions; change to collect all productIds from rankingEntries and call productQueryService to fetch summaries in bulk, build a Map<productId,ProductLikeSummary>, iterate rankingEntries to map to summaries while skipping or marking missing products (do not add nulls), and for exceptions other than NOT_FOUND either log with details and rethrow or propagate so failures aren't silently ignored; preserve original ranking order in the final list.

coderabbitai · 2025-12-26T04:16:25Z

...mmerce-streamer/src/main/java/com/loopers/application/ranking/RankingAggregationService.java

+    private void setTTLOnlyOnce(String key) {
+        Boolean exists = redisTemplate.hasKey(key);
+        if (Boolean.FALSE.equals(exists)) {
+            redisTemplate.expire(key, TTL);
+        }
+    }


⚠️ Potential issue | 🔴 Critical

TTL이 설정되지 않는 심각한 버그

setTTLOnlyOnce가 incrementScore 이후에 호출되므로, 이 시점에서 키는 항상 존재합니다. 따라서 hasKey가 항상 true를 반환하여 TTL이 절대 설정되지 않습니다.

🔎 제안된 수정

- private void setTTLOnlyOnce(String key) { - Boolean exists = redisTemplate.hasKey(key); - if (Boolean.FALSE.equals(exists)) { - redisTemplate.expire(key, TTL); - } - } + /** + * TTL이 설정되지 않은 경우에만 TTL을 설정합니다. + */ + private void setTTLOnlyOnce(String key) { + Long currentTtl = redisTemplate.getExpire(key); + // TTL이 -1이면 만료 시간이 설정되지 않은 상태 + if (currentTtl != null && currentTtl == -1) { + redisTemplate.expire(key, TTL); + } + }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

private void setTTLOnlyOnce(String key) {

Boolean exists = redisTemplate.hasKey(key);

if (Boolean.FALSE.equals(exists)) {

redisTemplate.expire(key, TTL);

}

}

/**

* TTL이 설정되지 않은 경우에만 TTL을 설정합니다.

*/

private void setTTLOnlyOnce(String key) {

Long currentTtl = redisTemplate.getExpire(key);

// TTL이 -1이면 만료 시간이 설정되지 않은 상태

if (currentTtl != null && currentTtl == -1) {

redisTemplate.expire(key, TTL);

}

}

🤖 Prompt for AI Agents

In apps/commerce-streamer/src/main/java/com/loopers/application/ranking/RankingAggregationService.java around lines 71-76, setTTLOnlyOnce currently checks hasKey after incrementScore, so the key always exists and TTL is never set; change the logic to set TTL when the key is newly created — e.g., after performing redis increment, check the returned incremented value and call redisTemplate.expire(key, TTL) only if the increment result equals 1 (meaning the key was just created), or alternatively call a set-if-absent before increment and set TTL when that returns true; update setTTLOnlyOnce or incrementScore accordingly so TTL is applied exactly once when the key is created.

coderabbitai · 2025-12-26T04:16:25Z

...erce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java

+        Map<String, Object> consumerProps = kafkaProperties.buildConsumerProperties();
+        consumerProps.put(ConsumerConfig.GROUP_ID_CONFIG, "${spring.kafka.consumer.group-id}");
+


⚠️ Potential issue | 🟡 Minor

consumer properties 설정이 올바르지 않습니다.

Line 70에서 "${spring.kafka.consumer.group-id}" 문자열 리터럴을 사용하고 있는데, 이는 Spring 플레이스홀더 문법으로 런타임에 해석되지 않습니다. 또한 이렇게 생성한 consumerProps 맵이 실제로 사용되지 않고 있습니다.

실제 group-id 값을 사용하려면 다음과 같이 수정하세요:

🔎 제안하는 수정

- Map<String, Object> consumerProps = kafkaProperties.buildConsumerProperties(); - consumerProps.put(ConsumerConfig.GROUP_ID_CONFIG, "${spring.kafka.consumer.group-id}"); + // 테스트에서 사용할 실제 consumer group id + String actualGroupId = kafkaProperties.getConsumer().getGroupId();

만약 이 코드가 실제로 필요하지 않다면 제거하는 것을 권장합니다.

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In apps/commerce-streamer/src/test/java/com/loopers/application/idempotency/EventHandledServiceTest.java around lines 69 to 71, the test sets consumerProps.put(ConsumerConfig.GROUP_ID_CONFIG, "${spring.kafka.consumer.group-id}") which incorrectly uses a Spring placeholder string (and the consumerProps map is never used); either remove the unused consumerProps block entirely, or replace the placeholder with the real group-id value retrieved from the KafkaProperties object (e.g., kafkaProperties.getConsumer().getGroupId()) or from the Environment, and ensure the populated consumerProps map is actually passed into the consumer setup so the test uses the correct group-id at runtime.

coderabbitai · 2025-12-26T04:16:25Z

...ce-streamer/src/test/java/com/loopers/application/ranking/RankingAggregationServiceTest.java

+        // TTL 확인 (expire를 먼저 걸고 unionstore를 하므로 TTL이 존재해야 함)
+        Long ttl = redisTemplate.getExpire(targetKey); // seconds
+        assertThat(ttl).isNotNull();
+        assertThat(ttl).isGreaterThan(0);


⚠️ Potential issue | 🟡 Minor

주석과 실제 코드 동작 불일치

주석에 "expire를 먼저 걸고 unionstore를 하므로"라고 되어 있지만, RankingAggregationService.carryOver()는 ZUNIONSTORE 실행 후 EXPIRE를 설정합니다. 주석을 수정하거나 제거해 주세요.

🔎 제안된 수정

- // TTL 확인 (expire를 먼저 걸고 unionstore를 하므로 TTL이 존재해야 함) + // TTL 확인 (ZUNIONSTORE 후 EXPIRE를 설정하므로 TTL이 존재해야 함) Long ttl = redisTemplate.getExpire(targetKey); // seconds

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

// TTL 확인 (expire를 먼저 걸고 unionstore를 하므로 TTL이 존재해야 함)

Long ttl = redisTemplate.getExpire(targetKey); // seconds

assertThat(ttl).isNotNull();

assertThat(ttl).isGreaterThan(0);

// TTL 확인 (ZUNIONSTORE 후 EXPIRE를 설정하므로 TTL이 존재해야 함)

Long ttl = redisTemplate.getExpire(targetKey); // seconds

assertThat(ttl).isNotNull();

assertThat(ttl).isGreaterThan(0);

🤖 Prompt for AI Agents

In apps/commerce-streamer/src/test/java/com/loopers/application/ranking/RankingAggregationServiceTest.java around lines 65 to 68, the inline comment wrongly states that EXPIRE is set before unionstore whereas RankingAggregationService.carryOver() actually calls ZUNIONSTORE first and then sets EXPIRE; update or remove the comment to reflect the real order (e.g., "EXPIRE is set after ZUNIONSTORE in carryOver() so TTL must exist") and keep the existing TTL assertions unchanged.

coderabbitai · 2025-12-26T04:16:25Z

modules/kafka/src/testFixtures/java/com/loopers/utils/KafkaCleanUp.java

+                // 토픽 생성
+                NewTopic newTopic = TopicBuilder.name(topicName)
+                        .partitions(3)
+                        .replicas(1)
+                        .config("min.insync.replicas", "1")
+                        .build();
+
+                adminClient.createTopics(Collections.singletonList(newTopic))
+                        .all()
+                        .get(5, TimeUnit.SECONDS);


⚠️ Potential issue | 🟡 Minor

파티션 수 불일치

KafkaTestContainersConfig에서 product-like-events 토픽을 1개 파티션으로 생성하지만, 이 유틸리티는 재생성 시 3개 파티션으로 생성합니다. 테스트 동작에 일관성 문제가 발생할 수 있습니다.

🔎 제안된 수정

토픽별 설정을 정의하거나, KafkaTestContainersConfig와 동일한 파티션 수를 사용하세요:

NewTopic newTopic = TopicBuilder.name(topicName) - .partitions(3) + .partitions(1) .replicas(1) .config("min.insync.replicas", "1") .build();

🤖 Prompt for AI Agents

In modules/kafka/src/testFixtures/java/com/loopers/utils/KafkaCleanUp.java around lines 104 to 113, the topic is being recreated with 3 partitions which conflicts with KafkaTestContainersConfig that creates the product-like-events topic with 1 partition; change the NewTopic creation to use the same partition count as the test container config (e.g., set .partitions(1) for product-like-events) or implement per-topic partition configuration (lookup the expected partition count for each topic and use that value when building NewTopic) so topic recreation matches the test environment.

junoade and others added 8 commits December 22, 2025 02:56

Merge pull request #33 from junoade/week9-feature-redis

85a0bfb

Week9 feature redis 초기구현

init: redis를 통한 ranking 조회 api

3061196

> 일단 돌아가게 구현

feat: 일별 랭킹 ZSet 점수 carry over 구현

fb6d5c0

오늘 ZSET 점수를 0.1 가중치로 내일 키로 복사하고 TTL을 설정

feat: 이벤트 컨슈밍시 TTL 설정 개선

ed75d4e

- Redis에서 EXPIRE는 쓰기 연산이다. - 네트워크 RTT - 매번 ZINCRBY + EXPIRE = 왕복 2번 - Kafka 이벤트당 1~2 RTT → TPS 높아질수록 체감

feat: 랭킹 스코어별 상품상세정보 조회 및 상품id에 대한 금일 일별 랭킹점수 조회 추가

9f4f62a

Merge pull request #34 from junoade/week9-feature-redis

86dc621

Week9 feature redis

coderabbitai bot reviewed Dec 26, 2025

View reviewed changes

junoade merged commit 0f9f582 into Loopers-dev-lab:junoade Dec 31, 2025
1 check passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[volume-9] Product Ranking with Redis #215

[volume-9] Product Ranking with Redis #215

Uh oh!

junoade commented Dec 26, 2025 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Dec 26, 2025 •

edited

Loading

Uh oh!

coderabbitai bot left a comment

Uh oh!

coderabbitai bot Dec 26, 2025

Uh oh!

coderabbitai bot Dec 26, 2025

Uh oh!

coderabbitai bot Dec 26, 2025

Uh oh!

coderabbitai bot Dec 26, 2025

Uh oh!

coderabbitai bot Dec 26, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

		Map<String, Object> consumerProps = kafkaProperties.buildConsumerProperties();
		consumerProps.put(ConsumerConfig.GROUP_ID_CONFIG, "${spring.kafka.consumer.group-id}");

[volume-9] Product Ranking with Redis #215

[volume-9] Product Ranking with Redis #215

Uh oh!

Conversation

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

Uh oh!

📌 Summary

💬 Review Points

✅ Checklist

📈 Ranking Consumer

⚾ Ranking API

📎 References

Summary by CodeRabbit

Release Notes

Uh oh!

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

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Possibly related PRs

Suggested labels

Poem

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Dec 26, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Dec 26, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Dec 26, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Dec 26, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Dec 26, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

junoade commented Dec 26, 2025 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Dec 26, 2025 •

edited

Loading