신호 영속화 저장소 선택
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| Backend MySQL 경유 | Aggregator → Backend API → MySQL, SignalCacheRepository 구현체를 BeSignalSnapshotRepositoryImpl로 교체 |
| Aggregator 직접 MySQL | Aggregator에 JPA 추가하여 직접 MySQL 연결 |
| Redis TTL 대폭 확대 | 기존 Redis TTL을 24h로 늘려 캐시 기간 연장 |
결정
Backend에 signal_snapshots 테이블과 CRUD API를 추가하고, Aggregator는 기존 BeGateway 패턴으로 Backend를 호출한다. SignalCacheRepository 인터페이스는 유지하고 구현체만 RedisSignalCacheRepositoryImpl → BeSignalSnapshotRepositoryImpl로 교체한다.
결정 이유
- 현재 아키텍처에서 MySQL 소유 주체는 Backend다.
- 기존 도메인 패턴(Backend가 DB를 소유하고 API로 노출)과 일관성을 유지한다.
SignalCacheRepository인터페이스를 유지하므로 Aggregator 내부 로직 변경이 최소화된다.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| Aggregator 직접 MySQL | 아키텍처 일관성 훼손 (Aggregator가 DB 소유 주체를 침범) |
| Redis TTL 대폭 확대 | 재시작 시 초기화, 영속성 없음, 근본적인 해결책이 아님 |
트레이드 오프
- Backend API 호출이 추가되어 네트워크 홉이 발생한다.
- 개인용 로컬 환경에서 추가 지연은 무시할 수준이며, 아키텍처 일관성을 유지한다.