Redis 선택 이유

• 도입 배경 MOMO 플랫폼은 모임 정보 조회, 사용자 세션 관리, 시간 기반 알림 시스템 등에서 실시간성과 성능이 중요했습니다. MySQL의 디스크 기반 조회만으로는 빈번한 데이터 접근에서 성능 병목이 발생했고(평균 200-300ms), 효과적인 캐싱 솔루션이 필요했습니다.
• 선택지
  • In-Memory 캐싱 (Caffeine, EhCache)
    • 네트워크 오버헤드 없는 극도로 빠른 성능
    • 분산 환경에서 캐시 공유 불가능
    • 서버 재시작 시 모든 캐시 데이터 손실
  • 데이터베이스 레벨 최적화
    • 기존 인프라 활용으로 추가 도입 비용 없음
    • 디스크 기반으로 메모리 캐시 대비 현저히 느림
    • TTL, 시간 기반 조회 등 캐시 특화 기능 부족
  • Redis
    • 메모리 기반 고성능 캐싱 (응답시간 200ms → 10ms)
    • 분산 환경에서 캐시 공유 가능
    • ZSET을 활용한 시간 기반 스케줄링 최적화
    • Spring Cache와 완벽한 통합
• 최종 결정 In-Memory 캐싱은 분산 환경에서 캐시 공유가 불가능하기 때문에 제외했습니다. 데이터베이스 최적화는 성능 요구사항을 충족하지 못하고 캐시 특화 기능이 부족해 제외했습니다. 따라서 Redis로 결정했습니다.