프로젝트 배경
모의 투자 서비스에서 주식 대회 기능을 구현하고 있다.
- 사용자는 가상의 돈으로 주식을 매수/매도
- 대회 종료 시점에 보유 주식의 최종 가격 + 잔고 기준으로 수익률을 계산
- 이를 기반으로 순위를 산정
즉, 대회 종료 시점에는 모든 참가자의 보유 주식에 대해 종목별 최종 가격을 조회하는 과정이 필요하다.
문제 상황
여러 사용자가 동일한 종목을 보유할 수 있기 때문에 가격 조회 과정에서 중복 호출이 발생할 수 있다.
- 사용자1: A, B, C 보유
- 사용자2: B, C 보유
- → B, C는 여러 번 조회될 수 있음
같은 시점의 가격인데도 반복 조회가 발생하는 구조다.
고민
최종 가격은 DB에 저장해야한다.
하지만 DB에 저장하기 전에 가격을 조회하는 과정에서 중복 API호출이 발생하는 문제가 있었다.
그래서 캐싱을 고민하게 되었다.
캐싱을 선택한 이유
같은 대회 종료 시점에서 동일 종목의 가격은 같은 값으로 사용된다.
따라서 한 번 조회한 종목 가격을 캐시에 저장해두면, 이후 같은 종목 가격이 필요할 때 외부 API를 다시 호출하지 않아도 된다.
- B 가격 최초 조회 → 외부 API 호출 → Redis 캐시에 저장
- B 가격 재조회 → Redis 캐시에서 조회
적용 흐름
대회 종료 정산 시작
↓
사용자별 보유 주식 조회
↓
종목 가격 조회
↓
Redis 캐시 확인
↓
캐시에 있으면 해당 가격 사용
↓
캐시에 없으면 외부 API 호출
↓
Redis에 저장
↓
최종 가격 DB 저장
결론
이번 고민의 핵심은 최종 가격 저장 여부가 아니라, 저장하기 위한 가격 조회 과정에서 중복 호출을 어떻게 줄일 것인가였다.
나는 이 문제를 해결하기 위해 Redis 캐싱을 적용하는 방식을 선택했다.
'Project' 카테고리의 다른 글
| 모의 주식 프로젝트에서 Kafka로 서비스 간 이벤트를 주고받기 (0) | 2026.05.03 |
|---|---|
| 모의 주식 대회 프로젝트에서 잘못된 상태 판단 로직을 수정한 과정 (0) | 2026.04.29 |
| 테이블 필요성에 대한 설계 고민과 소통 (0) | 2026.04.20 |
| 보유 주식 정보의 서비스 위치에 대한 고민 (0) | 2026.04.18 |
| 프로젝트 1차 회고 - 팀 소통 문제 (0) | 2026.04.08 |