왜 외부 API 데이터를 매번 호출하지 않고 캐시하는가

Source: Dev.to

Initial Approach

프로젝트에 외부 API를 처음 통합했을 때, 내 접근 방식은 간단했습니다:

Need data?
Call the API.

깨끗하고 논리적으로 보였지만, 실제 사용량이 늘어나면서 문제가 드러났습니다.

초기 구성은 다음과 같았습니다:

Client
↓
API Gateway
↓
External API

각 요청마다 다음이 발생했습니다:

• 새로운 API 호출
• 네트워크 왕복
• 타인의 가용성에 의존

트래픽이 적을 때는 괜찮아 보였지만, 실제 사용량이 급증하면서 결함이 드러났습니다.

Problems with Direct Calls

Cost

많은 API가 요청당 요금을 부과합니다. 처음엔 저렴해 보여도 백그라운드 작업, 재시도, 트래픽 급증이 발생하면 비용이 급증합니다.

Rate Limits

속도 제한에 걸리면:

• 기능이 실패하고
• 오류가 전파되며
• 방어 코드가 여기저기 퍼집니다

시스템이 타인의 규칙에 의해 형태를 잡게 됩니다.

Latency

빠른 외부 API라도:

• 네트워크에 의존하고
• 예측이 어렵고
• 내 제어 밖에 있습니다

Caching Strategy

요청 시마다 외부 API를 호출하는 대신, 다음과 같은 모델로 전환했습니다:

Worker / Cron
↓
External API
↓
Database

Client
↓
API Gateway
↓
Database

외부 API는 주기적으로 호출되고, 애플리케이션은 데이터베이스에서 읽습니다 — API가 아니라.

Benefits

• API 사용량을 측정하고 제어할 수 있습니다.
• 데이터베이스 읽기가 더 빠르고 최적화하기 쉽습니다.
• API가 다운되더라도 마지막으로 정상적인 데이터를 사용해 시스템이 계속 동작합니다.

핵심 질문은 “데이터가 최신인가?”가 아니라 “얼마나 최신이어야 하는가?” 입니다. 신선도는 비즈니스 결정이며, 반사적인 선택이 아닙니다.

When Direct API Calls Still Make Sense

• 실시간 금융 거래
• 인증 및 인가
• 신선도가 중요한 사용자 트리거 액션