일반 요청

  1. /user 기본 ttl은 30이다.
  2. GET /user/1 → 메인 서버 요청 → 캐시 생성
  3. GET /user/2 → 메인 서버 요청 → 캐시 생성
  4. GET /user/3 → 메인 서버 요청 → 캐시 생성
  5. GET /user/1 → (메인 서버 조회 없이) 캐시 반환

ttl 수정

  1. GET /user/1 → (메인 서버 조회 없이) 캐시 반환
  2. POST /user → ttl 20 수정 → /user 매칭 캐시, 모두 삭제
  3. GET /user/1 → 메인 서버 요청 → 캐시 생성
  4. GET /user/1 → (메인 서버 조회 없이) 캐시 반환

자동 만료

<aside> 💡 각각의 캐시들은 생성 초기에 정의된 TTL 설정에 의해 시스템 내부적으로 자동 삭제된다.

</aside>

활성캐시개수가 왜 필요할까?

삭제했을 때, 삭제 여부를 반환해주지 않음

그 말은 즉슨, 관리자가 자신의 요청의 결과를 확인할 수 없다는 뜻

캐시가 삭제된 것을 확인하는 방법은 요청이 반영될 자료구조에 저장된 객체의 개수로 판단

삭제를 진행하기 전의 개수를 가져오고, 삭제 기능 수행, 삭제 기능을 수행한 이후의 개수를 가져와서 비교

@우진 김 > 캐시 만료 기한을 수정했을 때, 이에 대한 결과를 반환하는지: 결과값 없음