diff --git a/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md b/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
new file mode 100644
index 0000000..7b77c97
--- /dev/null
+++ b/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
@@ -0,0 +1,61 @@
+# 📊 [Catalog Service] Redis 캐시 도입을 통한 읽기(Read) 성능 최적화 리포트 (2차 부하테스트)
+
+본 문서는 AS-IS 아키텍처에서 발생했던 MongoDB Disk I/O 병목 현상(153 TPS 한계)을 해결하기 위해 **Redis 인메모리 캐시 (Cache-Aside 패턴)를** 도입한 후, 카탈로그 조회
+성능이 얼마나 향상되었는지 검증한 TO-BE 리포트입니다.
+
+---
+
+## 1. 캐시 도입 후 읽기 성능 측정 및 'Cache Warming' 효과 분석
+
+> **테스트 목적:** 카탈로그 메인 화면 및 단건 조회 API에 Redis 캐시(`@Cacheable`)를 적용한 후, Disk I/O 한계를 돌파하여 목표치인 200 TPS를 안정적으로 상회하는지 검증합니다.
+
+### 📌 부하테스트 결과 (JMeter)
+
+이번 테스트에서는 캐시 적중 상태에 따라 명확한 성능 차이가 나타나는 'Cache Warming' 현상이 뚜렷하게 관측되었습니다.
+
+- **부하 규모:** 100 Threads 동시 요청 (총 1,000건 스파이크)
+- **1차 타격 결과 (Cold Cache / Partial Hit):**
+    - **처리량:** `약 394 TPS`
+    - 분석: Redis에 데이터가 완전히 적재되지 않아 일부 요청이 MongoDB로 흘러 들어간(Cache Miss) 상태입니다. 그럼에도 불구하고 기존 AS-IS(153 TPS) 대비 2.5배 이상의 성능을
+      기록했습니다.
+
+<img width="856" height="233" alt="스크린샷 2026-05-18 오후 7 10 54" src="https://github.com/user-attachments/assets/4a36b2dc-d06f-47bd-83f9-22b87f176585" />
+
+- **2차 타격 결과 (Warm Cache / Full Hit) - 최종 지표:**
+    - **처리량(Throughput):** `993.0 / sec` **(AS-IS 대비 약 646% 성능 향상)**
+    - **평균 지연 시간(Average):** `25.8 ms` **(AS-IS 대비 약 95% 지연 시간 단축)**
+    - **최소 / 최대 지연 시간:** `1 ms` / `170 ms`
+    - **에러율(Error %):** `0.0%`
+
+<img width="854" height="252" alt="스크린샷 2026-05-18 오후 7 11 05" src="https://github.com/user-attachments/assets/e9475737-5fbb-4714-a9c4-434bb4c4d7a3" />
+
+### 🔍 성능 최적화 및 워밍(Warming) 효과 분석
+
+1차 타격(394 TPS)에서 2차 타격(993 TPS)으로의 성능 상승은 MSA 환경에서 **캐시 워밍(Cache Warming)** 전략의 효과를 데이터로 보여줍니다. 데이터가 Redis 메모리에 완전히 캐싱된(
+Full Hit) 2차 테스트에서는 MongoDB에 대한 추가 I/O가 발생하지 않아, 평균 응답 시간이 25.8ms를 기록했습니다. 이는 대규모 트래픽이 예상되는 이벤트(선착순 오픈 등) 발생 직전에 주요 데이터를
+메모리에 미리 적재하는 전략이 서비스 안정성에 직결됨을 시사합니다.
+
+---
+
+## 2. 성능 지표 비교 (AS-IS vs TO-BE)
+
+| 지표               | AS-IS (MongoDB 직접 조회) | TO-BE (Redis Cache Full Hit) | 개선 효과 (증감률)        |
+|:-----------------|:----------------------|:-----------------------------|:-------------------|
+| **Throughput**   | 153.5 TPS             | **993.0 TPS**                | **`+ 646% 수직 상승`** |
+| **Average Time** | 539 ms                | **25.8 ms**                  | **`- 95.2% 단축`**   |
+| **Max Time**     | 2,153 ms              | **170 ms**                   | **`- 92.1% 단축`**   |
+| **Error Rate**   | 0.0%                  | **0.0%**                     | 유지 (안정성 보장)        |
+
+---
+
+## 3. 종합 결론 및 데이터 정합성 방어 전략 (Cache Eviction)
+
+1. **압도적인 읽기 성능 확보:** 인메모리 데이터베이스인 Redis를 활용하여 카탈로그의 읽기 병목을 해소했습니다. 993 TPS라는 수치는 단일 서비스의 성능 향상뿐만 아니라, 이와 같은 방식으로
+   구성된 API를 동기적으로
+   호출하는 오더(Order) 서비스의 병목까지 연쇄적으로 해결하는 핵심 키가 되었습니다.
+2. **이벤트 기반 정합성(Consistency) 유지:** 성능을 위해 캐시를 도입할 때 가장 경계해야 할 문제는 과거 데이터가 노출되는 'Stale Data' 현상입니다. 이를 방어하기 위해 점주가 상품 정보를
+   수정하거나(`product.updated`), 품절 처리(`product.status-changed`)를 할 경우, **Kafka 이벤트를 수신하여 즉각적으로 다중 캐시(목록 캐시, 단건 캐시)를 무효화(
+   `@CacheEvict`)하도록** 설계했습니다.
+
+결과적으로 Miche-Let의 카탈로그 서비스는 1,000 TPS에 육박하는 처리 성능을 확보했으며, Kafka 이벤트 기반 무효화로 데이터 정합성 리스크를 낮췄습니다.  
+정합성은 운영 환경에서 이벤트 지연/누락 모니터링 지표와 함께 지속 검증이 필요합니다.