[REFACTOR] 채팅 기능 리팩토링 #317
Description
리팩토링 대상
채팅 시스템의 이벤트 기반 시스템 메시지 전송 파이프라인 전반을 리팩토링합니다.
Business Event → Chat Internal Event → System Message 전송(저장/브로드캐스트) 흐름
멱등성(ProcessedEventStore) / 재시도(Spring Retry) / DLQ 처리(FailedEventDlq)
WebSocket 브로드캐스트(user-topic 포함) 및 인가 흐름 보강
ChatRoom 최신 메시지/읽음 처리 동시성(CAS update) 관련 로직 점검
현재 상태
현재 구현은 전반적으로 구조가 안정적이나, 운영 안정성과 관측 가능성 관점에서 아래 개선 여지가 있습니다.
멱등성 선점(SETNX) 이후 프로세스 다운 시 조용한 유실 가능성
markIfNotProcessed 선점 직후 프로세스가 종료되면, 키 TTL 동안 재처리가 스킵되어 메시지가 유실될 수 있음(“in-progress 락” 문제)
AFTER_COMMIT → 내부 publish/@async 사이 이벤트 유실 가능성
커밋은 됐지만 publish/async 실행 전에 프로세스가 죽으면 이벤트가 남지 않아 유실될 수 있음
user-topic 브로드캐스트 구조가 인터셉터 인가에 과도 의존
destination 추가/변경 시 인가 검증 누락 가능성이 있으며, 안전장치를 더 두껍게 할 필요가 있음
최신성 판단 기준(lastMessageAt 단독 비교) 경계 케이스
timestamp 정밀도/동일 시각 발생 시 최신 메시지 미반영 등의 경계 문제가 생길 수 있음
논리 실패(채팅방 없음 등) 관측성 부족
DLQ 정책상 제외하는 경우라도, 운영에서 패턴 분석/알림을 위한 지표/로그 체계가 더 필요함
DLQ가 Redis List 단일 구조
리팩토링 목표
- 코드 가독성 향상
- 성능 개선
- 중복 코드 제거
- 디자인 패턴 적용
- 테스트 용이성 향상
- 기타
변경 계획
리팩토링 방법과 계획을 구체적으로 작성해주세요.
영향 받는 파일/모듈
예: src/main/java/com/example/service/...
예상 결과
리팩토링 후 기대되는 개선 사항을 설명해주세요.
테스트 계획
리팩토링 후 검증 방법을 설명해주세요.
추가 정보
리팩토링에 대한 추가적인 맥락이 있다면 작성해주세요.