worker 재계산 책임 경계 (오케스트레이션 vs 직접 연산·저장)
상태
승인
후보군
| 방안 | 설명 |
|---|
| worker 오케스트레이션 (입력=BE, 계산=ml, 저장=BE) | worker는 흐름만 조율, 연산·영속화는 기존 소유 서비스 |
| worker 직접 연산·자체 DB | worker가 예측을 계산하고 자체 테이블에 저장 |
| backend 내부 재계산 + worker는 트리거만 | worker는 BE 재계산 엔드포인트만 호출 |
결정
worker는 오케스트레이션만 한다. 입력은 backend read API에서 읽고, 예측 계산은 ml에 위임하고, 결과는 backend 영속화 API로 저장한다. worker는 상태를 갖지 않는다.
결정 이유
- ml은 stateless 계산, 영속화는 backend MySQL이라는 기존 방향(STK9)을 유지한다.
- 예측 데이터 소유권을 backend에 두어 단일 쓰기 주체를 보존한다 — worker가 자체 DB를 가지면 소유권·읽기 경로가 분산된다.
- worker가 thin하면 컨슈머 장애·재처리 영향이 작다.
검토 대안
| 방안 | 기각 이유 |
|---|
| worker 직접 연산·자체 DB | 데이터 소유권 분산, ml/BE와 로직 중복, 읽기 경로 복잡 |
| backend 내부 재계산 + worker 트리거만 | 재계산 로직이 BE로 가 worker가 사실상 불필요해짐 (ADR-008 격리 의도와 배치) |
트레이드 오프
| 구분 | 내용 |
|---|
| 득 | ml stateless·BE 영속화 소유권 유지, worker 경량, 책임 분리 명확 |
| 실 | worker↔BE↔ml 네트워크 홉 다수 (1일 1회라 비용 무시 가능) |