[Backend] 데이터의 유형 정리

자주 쓰는 구분

• 상태(State) 지금 현재값이 핵심인 데이터. 덮어써도 됨. 예: 현재 배터리 %, 현재 온라인 여부, 현재 토큰 잔액
• 이벤트(Event) “무슨 일이 일어났다”가 핵심인 데이터. 보통 append-only. 예: 배터리 73% 수신, 충전 시작됨, 사용자 로그인함
• 명령(Command) 누군가에게 뭔가를 하라고 시키는 데이터. 처리 보장이 중 요함. 예: 이 알림 보내라, 이 작업 실행해라
• 조회 결과 / 읽기 모델(Read Model) 화면이나 API 응답용으로 가공된 데이터. 예: 기기별 최신 배터리 목록, 최근 1시간 배터리 변화
• 로그 / 감사 기록(Audit Log) 나중에 추적하기 위해 남기는 기록. 예: 누가 언제 어떤 값을 보냈는지
• 메트릭 / 시계열(Time Series) 시간에 따라 계속 쌓이는 측정값. 예: CPU 사용률, 온도, 배터리 변화 히스토리

실전 결정 트리

1. 최신 값만 중요하다 그러면 상태
2. 변화 하나하나가 중요하다 그러면 이벤트 또는 시계열
3. 나중에 붙은 소비자도 과거를 알아야 한다 그러면 pub/sub 단독은 안 됨 DB / 파일 / Redis Streams / Kafka 쪽
4. 지금 연결된 소비자에게 실시간 전달만 하면 된다 그러면 pub/sub 가능
5. 반드시 처리되어야 하고 유실되면 안 된다 그러면 명령 큐 / stream / durable log
6. 화면에서 보기 좋게 정리된 응답이 필요하다 그러면 read model을 따로 둠

네 배터리 예시에 적용 배터리 시스템은 사실 하나가 아니라 세 가지가 섞여 있습니 다.

• 현재 배터리 71% 이건 상태
• 18:55에 71%가 들어왔다 이건 이벤트
• 최근 20개 변화 내역 이건 시계열/히스토리
• 클라이언트에게 바로 알려주기 이건 실시간 전달

그래서 보통 구조는 이렇게 갑니다.

• 최신 상태 저장소 파일/DB/Redis key
• 이벤트 히스토리 저장소 JSONL/DB/Timeseries
• 실시간 전달 채널 메모리 큐, Redis pub/sub, SSE, WebSocket

간단한 선택 기준

• 최신 값만 보면 된다 상태 저장소만
• 실시간 알림도 필요하다 상태 저장소 + pub/sub/SSE
• 과거 이력도 필요하다 상태 저장소 + 히스토리 저장소
• 늦게 붙은 소비자도 과거부터 재생해야 한다 Streams/Kafka류 고려

네 케이스는 가장 자연스럽게 말하면:

• latest.json = 상태
• history.jsonl = 이벤트/히스토리
• SSE = 실시간 전달

즉 이미 꽤 좋은 방향으로 가고 있습니다.