Skip to content

Conversation

kilhyeonjun
Copy link
Contributor

요구사항

  • 기존에 애플리케이션 이벤트를 카프카 메세지 발행으로 변경
  • 카프카의 발행이 실패하는 것을 방지하기 위해 Transactional Outbox Pattern를 적용
  • 카프카의 발행이 실패한 케이스에 대한 재처리를 구현 ( Scheduler or BatchProcess )

작업 내용

  • 기존에 애플리케이션 이벤트를 카프카 메세지 발행으로 변경
  • Transactional Outbox Pattern 적용
  • 카프카의 발행이 실패한 케이스에 대한 재처리를 구현

리뷰포인트

  • 궁금한 사항은 코멘트 남겨놨습니다. 확인 부탁드립니다!
  • 리뷰어님들이 생각했을 때 더 좋은 패턴이 보일 경우 공유해주시면 좋을 것 같습니다.
  • 테스트 코드의 추가로 있으면 좋을 부분 또는 불 필요해 보이는 부분도 확인 부탁드립니다.

private final DataPlatformSendService sendService;

@KafkaListener(topics = EventType.PAYMENT_SUCCESS, groupId = "payment-group")
public void consume(Long paymentId) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

수신 기록 Table을 두어 consume시 eventId를 같이 전달 받으면서 수신 기록 Table에 유니크 한 row를 추가하면서 중복 컨슘의 방지가 필요했을지 의문입니다.

Comment on lines +15 to +16
@Getter
private static final List<String> messages = new ArrayList<>();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

테스트 검증을 위해 사용한 값인데 실제 PRD 환경에서는 사용이 되면 안될 것 같은데 이벤트 수신 로그 table을 만들어서 해당 값을 조회하는 방식으로 가야했을지 의문이네요.

@kilhyeonjun kilhyeonjun merged commit 218b268 into master Nov 26, 2024
@kilhyeonjun kilhyeonjun deleted the step-18 branch December 1, 2024 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant