docs: 내용 추가

_posts/2023-09-25-db-cache.md

@@ -122,7 +122,33 @@ vUser 50을 기준으로 평균 TPS는 117.1이었습니다.
 
 TPS를 비교해보면, 117 TPS -> 2386 TPS로 1943.59%의 성능 향상이 이루어졌습니다.
 
-## 6. 마무리
+## 6. Sequence Diagram 비교
+
+어떻게 API 흐름이 변경되었는지 Sequence Diagram을 통해 알아보도록 하겠습니다.
+
+**Cache 적용 이전**  
+<img width="412" alt="스크린샷 2023-09-26 오후 5 55 54" src="https://user-images.githubusercontent.com/115435784/270597901-98dbde0f-d415-4279-9fba-7f098383d014.png">
+
+서버에서 조회가 일어날 때마다 같은 데이터를 반환할 수 있음에도 불구하고, 매번 DB에 접근하며 부하를 일으키게 됩니다.
+
+**Cache 적용 이후(Cache Hit)**  
+<img width="479" alt="스크린샷 2023-09-26 오후 5 55 33" src="https://user-images.githubusercontent.com/115435784/270597770-29bcd8e7-86d8-49a3-a7b2-56264150b138.png">
+
+
+이렇게 Cache에 저장된 데이터가 있다면, DB에 접근하지 않고도 훨씬 빠른 속도로 데이터를 응답할 수 있게 됩니다.
+
+만약 캐싱된 데이터가 없다면 어떻게 될까요?
+
+**Cache Miss**  
+
+<img width="475" alt="스크린샷 2023-09-26 오후 5 55 03" src="https://user-images.githubusercontent.com/115435784/270597641-1e03abe1-b08f-42d2-b49b-d042dd8ee1a4.png">
+
+이처럼 캐시가 없을 경우 DB를 조회한 후 다시 캐싱해주는 과정을 거치게 됩니다.
+
+Cache Miss가 발생할 경우 이처럼 Sequence가 복잡해질 수 있고, 자주 사용되지 않는 데이터를 캐싱할 경우 리소스 낭비가 될 수 있기 때문에, 데이터 변경이 자주 일어나지 않고, 조회를 많이 하는 데이터만 캐싱하는 것이 성능상 유리합니다.
+
+
+## 7. 마무리
 
 이번 포스팅을 통해 DB에 캐시를 적용하는 방법을 알아보았습니다.