신호 영속화 저장소 선택

상태

승인

후보군

방안설명
Backend MySQL 경유Aggregator → Backend API → MySQL, SignalCacheRepository 구현체를 BeSignalSnapshotRepositoryImpl로 교체
Aggregator 직접 MySQLAggregator에 JPA 추가하여 직접 MySQL 연결
Redis TTL 대폭 확대기존 Redis TTL을 24h로 늘려 캐시 기간 연장

결정

Backend에 signal_snapshots 테이블과 CRUD API를 추가하고, Aggregator는 기존 BeGateway 패턴으로 Backend를 호출한다. SignalCacheRepository 인터페이스는 유지하고 구현체만 RedisSignalCacheRepositoryImplBeSignalSnapshotRepositoryImpl로 교체한다.

결정 이유

  • 현재 아키텍처에서 MySQL 소유 주체는 Backend다.
  • 기존 도메인 패턴(Backend가 DB를 소유하고 API로 노출)과 일관성을 유지한다.
  • SignalCacheRepository 인터페이스를 유지하므로 Aggregator 내부 로직 변경이 최소화된다.

검토 대안

방안기각 이유
Aggregator 직접 MySQL아키텍처 일관성 훼손 (Aggregator가 DB 소유 주체를 침범)
Redis TTL 대폭 확대재시작 시 초기화, 영속성 없음, 근본적인 해결책이 아님

트레이드 오프

  • Backend API 호출이 추가되어 네트워크 홉이 발생한다.
  • 개인용 로컬 환경에서 추가 지연은 무시할 수준이며, 아키텍처 일관성을 유지한다.