> For the complete documentation index, see [llms.txt](https://wonjoon.gitbook.io/joons-til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wonjoon.gitbook.io/joons-til/k6-optimization-project/leetcode-project/optimization1-java-application/get-problemdetail.md).

# GET ProblemDetail

문제 상세 정보 가져오기 API 최적화

### 📗 문제 상세 정보 가져오기 API

**`GET /problems/{problem_id}`**

* ✅ **캐싱 적용:** 자주 조회되는 상세 정보를 Redis에 캐싱하여, 캐싱된 데이터를 빠르게 가져올 수 있습니다.

#### 가설:

* Redis 캐시 적용 시 API의 응답 속도가 빨라질 것 입니다.
* 자주 조회되는 문제 상세 정보를 Redis에 key로 저장하고 조회하면, DB 접근 빈도가 줄어들 것입니다.

#### 실험/과정:

1. 캐싱 전략 수립:
   * 문제 상세 정보를 Redis에 저장
   * 요청 시 캐시에 데이터가 있으면 바로 반환, 없으면 DB 조회 후 캐시에 저장
2. 성능 측정
   * 캐싱 적용 전/후로 API 응답 시간 측정
   * 동일한 문제를 반복 요청하여 응답 시간 측정
   * 응답 시간 측정 후 개선율 확인
3. 테스트 환경
   * 로컬 개발 환경에서 레디스 캐시와 연동

<figure><img src="broken://files/ERiIyKfMIzyGPUJFrRI2" alt=""><figcaption><p>결과</p></figcaption></figure>

* 캐싱 적용 결과, 문제 상세 정보 조회 API의 응답 속도가 50% 이상 개선되었습니다.
* 캐시 히트가 100%라면 자주 조회되는 문제에 대해서는 DB 접근 빈도가 줄어 서버 부하가 감소함을 예상할 수 있습니다.

#### 평가:

🟩 장점:

* **API 응답 속도 개선**: 실험 결과, API 응답 속도가 **50% 이상 향상**되었습니다.
* **DB 부하 감소**: 캐시 히트율이 100%라면, **자주 조회되는 문제에 대한 데이터베이스 접근 빈도가 크게 줄어듭니다.**
* **서버 자원 효율성 증대**: 불필요한 DB I/O를 줄이고 캐시 서버(Redis)를 활용함으로써, 시스템의 전반적인 자원 활용 효율성을 높일 수 있습니다.

🟥 단점:

* **캐시 무효화 및 일관성 관리 필요**: 데이터가 업데이트될 경우 캐시를 최신 상태로 유지하기 위한 **캐시 무효화(Cache Invalidation) 전략**이 필요합니다. 이를 잘못 관리하면 stale data(오래된 데이터)를 사용자에게 보여줄 위험이 있습니다.
* **캐시 서버 관리 오버헤드**: Redis와 같은 별도의 캐시 서버를 운영해야 하므로, 배포, 모니터링, 유지보수 등 **추가적인 관리 오버헤드**가 발생합니다.

#### 결론:

* 문제 상세 정보 가져오기 API에 대한 캐싱 적용은 매우 효과적이며, 전반적으로 강력히 권장되는 개선 사항입니다.
* 특히, 문제라는 서비스 특성상 데이터가 거의 변경될 가능성이 낮아 캐시 효율을 극대화할 수 있다는 점은 캐싱 도입의 핵심 근거로 내세울 수 있습니다.