[SRLT-151] 알림 발행 유실 방지를 위한 Outbox 구조 도입#93
Hidden character warning
Conversation
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (48)
Note
|
Test Results262 tests 262 ✅ 11s ⏱️ Results for commit 6fc755e. ♻️ This comment has been updated with latest results. |
🚀 Why - 해결하려는 문제가 무엇인가요?
Notification을 DB에 저장한 뒤, 트랜잭션 커밋 이후 Redis Pub/Sub로 실시간 알림을 발행하는 방식이었습니다.✅ What - 무엇이 변경됐나요?
NotificationOutbox엔티티를 추가했습니다.Notification과NotificationOutbox를 같은 트랜잭션에 저장하도록 변경했습니다.PENDING,PROCESSING,SENT,FAILED,DISCARDED로 관리하도록 했습니다.FAILED로 남기고, 설정된 지연 시간 이후 재처리할 수 있도록 했습니다.🛠️ How - 어떻게 해결했나요?
NotificationService.notifyMember(...)에서 알림을 저장한 뒤 즉시NotificationOutbox를 함께 생성합니다.NotificationCreatedEventHandler가 outbox id를 받아NotificationOutboxPublishService에 발행을 위임합니다.NotificationOutboxPublishService는 outbox를 먼저PROCESSING상태로 claim한 뒤 Redis publish를 수행합니다.SENT로 변경합니다.FAILED로 변경하고nextRetryAt을 설정해 재처리 대상으로 남깁니다.DISCARDED로 분리합니다.NotificationOutboxPublishScheduler는 주기적으로PENDING, 재시도 가능한FAILED, 오래된PROCESSINGoutbox를 조회해 다시 발행합니다.@Version기반 낙관적 락과 claim 단계로 방어합니다.