adr websocket streams

ADR - Dashboard 실시간 푸시: WebSocket + DynamoDB Streams

메타데이터	값
상태	accepted
결정일	2026-05-18
현재 유효 여부	유효
관련 결정	ElastiCache Redis(ADR 0014), ECS Fargate Backend(adr-ecs-fargate-backend), 공식 factory-status table(ADR 0022)
구현 근거	apps/dashboard-backend(WebSocket route), Lambda notifier, DynamoDB Streams ESM
검증 근거	DDB write 후 1초 이내 push 수신, JWT 미인증 연결 거부

---

결정

Dashboard 실시간 갱신을 폴링이 아니라 WebSocket 푸시로 처리한다. Lambda data processor가 DynamoDB에 write하면 DynamoDB Streams가 발화해 클라이언트까지 변경을 전달한다.

Lambda data processor → DynamoDB LATEST (write)
  → DynamoDB Streams
  → Lambda notifier (VPC-attach, Redis publish)
  → ElastiCache Redis Pub/Sub
  → ECS Fargate Backend × N (subscribe)
  → WebSocket → Dashboard Web

• WebSocket endpoint: /ws/factories/{factory_id}, 인증은 ?token=<JWT>
• 단절 시 REST 폴링으로 자동 degradation, 재연결은 exponential backoff

이유

• 폴링 한계: 동시 사용자 5명 × 5초 폴링이면 no-change 응답이 폭증해 DynamoDB read 비용과 무의미한 트래픽이 늘고, 갱신 지연이 폴링 주기에 묶인다. WebSocket 전환으로 read를 90%+ 줄인다.
• WebSocket on Fargate 선택: ECS Backend(adr-ecs-fargate-backend)가 이미 있어 추가 인프라가 0이고, Redis Pub/Sub fan-out으로 scale-out이 자연스럽다. SSE(단방향), AppSync(자유도·학습곡선), API Gateway WebSocket(중복·메시지 과금)은 비채택.
• DynamoDB Streams를 트리거로: 데이터가 실제 저장된 시점에 발화해 정확하고, notifier를 분리해 retry·DLQ·관측을 독립적으로 관리한다.

영향

• DynamoDB 공식 hot store에 Streams 활성화(NEW_AND_OLD_IMAGES).
• Lambda notifier(VPC-attach) + DynamoDB Streams event source mapping + Redis 6379 inbound 보안그룹.
• 추가 비용은 거의 0(Streams read 소액, notifier는 Free Tier 내, Redis는 ADR 0014에서 계상).
• RiskAlertDispatcher와 notifier는 이름이 비슷하지만 역할이 다르다 — notifier는 Dashboard WebSocket push, dispatcher는 Slack alert를 담당한다.

관련 문서

• 실시간 갱신 구조
• API 명세
• Dashboard Backend
• ADR 인덱스