보유종목·거래내역 읽기 동기화 방식 선택

상태

승인

후보군

방안	설명
조회 요청마다 Toss fetch 후 MySQL upsert	요청 시점에 Toss API를 호출하고, 결과를 unique 제약으로 MySQL에 upsert
별도 동기화 스케줄러	주기적으로 Toss API를 폴링해 MySQL에 upsert
Toss만 조회, MySQL 저장 없음	조회 시 Toss 응답을 그대로 반환. 오프라인 조회 불가

결정

조회 요청마다 Toss API를 호출하고, 결과를 toss_transaction_id/(account_number, symbol) unique 제약으로 MySQL에 upsert한다. 별도 동기화 스케줄러 없이 조회 요청이 트리거 역할을 한다.

결정 이유

• 보유종목과 거래내역은 Toss가 항상 최신이므로, 조회 시점에 Toss에서 fetch해 MySQL에 캐싱하면 실시간성과 오프라인 조회 모두 확보된다.
• unique 제약(toss_transaction_id, (account_number, symbol))으로 중복 적재를 방지해 멱등성을 보장한다.
• 별도 스케줄러 없이 조회 요청 자체가 동기화를 트리거하므로 구현 단순성 유지.

검토 대안

방안	기각 이유
별도 동기화 스케줄러	사용하지 않는 시간에도 Toss API를 호출해 불필요한 트래픽 발생. 현 단계 요구사항 초과
Toss만 조회, MySQL 저장 없음	앱 종료 후 마지막 상태 확인 불가. 오프라인 조회 요구사항 미충족

트레이드 오프

• 득: 실시간성 확보(조회마다 최신 데이터). 스케줄러 불필요로 구현 단순. 오프라인에서 마지막 upsert 데이터 참조 가능.
• 실: 요청마다 Toss API 호출 발생. Toss 미접속 환경에서 신규 데이터 갱신 불가(마지막 upsert 데이터 fallback은 현 단계 범위 밖).