현재가(실시간) 처리 저장소 선택

상태

승인

후보군

방안	설명
A. 요청마다 토스 API 직접 호출	FE 또는 BE가 매 조회 시 토스 API 호출
B. BE 캐시 + FE 30초 폴링	BE 캐시 저장 후 FE가 30초마다 REST 재호출
C. SSE + BE 스케줄러	BE 30초마다 토스 API 배치 조회 → 캐시 갱신 → 연결된 FE에 push
D. FE 직접 폴링	FE가 30초마다 토스 API 직접 호출

결정

방안 C — SSE + BE 스케줄러

StockPriceScheduler: 30초마다 토스 API 배치 조회 → stock_price_cache 갱신 → SseEmitterRegistry에 등록된 모든 emitter에 push
GET /api/v1/stocks/prices/stream: SseEmitter 반환 (Spring MVC 내장)
FE: new EventSource('/api/v1/stocks/prices/stream') → onmessage로 상태 갱신 (자동 재연결 내장)
REST fallback: GET /api/v1/stocks/prices?symbols= 유지 (초기 로딩용 스냅샷)

결정 이유

토스 API에 WebSocket·Push·SSE가 없어 BE에서 배치 조회 후 push하는 구조가 최적
FE는 EventSource 1줄만 추가하면 되어 복잡도가 낮음
갱신 타이밍이 서버 기준으로 통일되어 클라이언트별 타이밍 불일치 없음
개인 투자 도구 수준에서 최대 30초 지연 허용 가능

검토 대안

방안	기각 이유
A. 요청마다 토스 API 직접 호출	Rate limit 위험. 종목 N개 × 클라이언트 수만큼 호출 발생
B. BE 캐시 + FE 30초 폴링	FE 각 페이지·탭에서 `useInterval` 분산 관리 복잡. 갱신 타이밍이 클라이언트별로 달라짐
D. FE 직접 폴링	CORS·보안키 노출·Rate limit 분산 불가

트레이드 오프

득: FE 복잡도 최소화 (useInterval 불필요), 토스 API 호출 1회 배치 (클라이언트 수와 무관), 갱신 타이밍 서버 통일
실: BE 추가 구현 필요 (SseEmitterRegistry emitter 등록·해제·timeout 관리 약 50줄), 최대 30초 지연