스냅샷 적재·조회 주체 선택 (aggregator vs backend)

상태

승인

후보군

방안	설명
aggregator writer/reader	aggregator가 ML 계산 → backend `PUT` 적재, 조회 시 backend `GET` cache-first
backend writer/reader	backend에 ML 게이트웨이·스케줄러 신설, FE가 backend 스냅샷 API 직접 조회

결정

aggregator를 스냅샷 적재·조회 주체로 한다.

결정 이유

backend에 스냅샷 테이블·도메인·PUT/GET API가 이미 있고, aggregator에 be.base-url 설정도 있으나 미사용이다 → 원래 의도된 설계가 aggregator writer임을 시사한다.
aggregator는 이미 ML 게이트웨이(SignalGateway)와 Redis 캐시를 보유한다. cache-first의 L1(Redis)·L3(ML)이 aggregator에 있으므로 L2(MySQL 스냅샷)도 aggregator가 묶는 것이 일관적이다.
FE 단일 진입점(Aggregator) 원칙을 유지한다. backend 조회로 전환하면 FE가 다시 두 서버를 알아야 한다.
backend·ML 코드 무변경. 신규 테이블 0.

검토 대안

방안	기각 이유
backend writer/reader	backend에 ML 게이트웨이 중복 신설 필요, FE 진입점 단일화 위배

트레이드 오프

구분	내용
득	기존 자산 재사용, backend 무변경, 진입점 단일 유지
실	aggregator → backend HTTP 1홉 추가(스냅샷 PUT/GET). 단 자정 1회 적재라 비용 미미