⚠️ 특정 비즈니스 상황을 천천히 생각해 보면서 작성한 글입니다. 허술함에 주의하세요.
이벤트 '시작 시각'과 이벤트 '종료 시각'을 담고 있는 데이터가 있다.
| ID | 시작시각 | 종료시각 | |
| 1 | 2023. 8. 20 00:00 | 2023. 8. 25 23:59 | |
| 2 | 2023. 8. 26 00:00 | 2023. 8. 30 00:00 |
특정 시점(=현재시각)을 기준으로 이벤트 중인 데이터를 조회
특정 시점을 기준으로 이벤트 중인 데이터를 조회하는 기능이 있다고 하자, 위 데이터가 SQL 서버에 저장되어 있다면 손쉽게 쿼리로 원하는 데이터를 추출할 수 있을 것이다.
캐시 적용
데이터가 매우 많고, 호출이 많아 위 기능에 캐시를 적용하기로 하였다. 어떻게 적용하면 좋을까?
아마도 위 기능을 구현하는 함수는 아래와 같은 형태이고, 인자 값인 `at` 은 호출 시점마다 다른 값으로 호출한다면, `@Cacheable` 로 좋은 성능을 얻기 힘들 것이다.
fun getInProgressEvents(at: LocalDateTime)제약 조건
캐시를 효율적으로 설계하기 위해서 막강한 함수에 제약 조건을 조금 추가해서 상황을 좀 더 단순화 할 필요가 있어 보인다.
제약 1. '현재' 유효한 이벤트만 읽어올 수 있으면 된다.
위 데이터 기준으로 21일 유효한 이벤트만 가져오면, 레코드. 1을 가져오게 된다.
이 데이터를 캐싱하게 되면, 2023. 8. 26일 00시에 이벤트 2가 리턴돼야 함으로 기존 캐시가 만료되어야 한다. 즉, 제약조건이 포함되기 전 문제가 여전히 발생함
방법 1. '현재' 이후, 가능한 이벤트를 모두 가져온다.
'종료시각' 기준으로 현재 진행 중인 이벤트와 예정 중인 이벤트를 모두 가져온다. 그리고 이 값을 캐싱한다.
실제 진행 중 인 이벤트는 웹서비스에서 판단해서 응답한다.
@Cacheable
fun getInProgressAndFutureEvents()
예정된 이벤트가 매우 많다면,
적당히 효율적인 단위로 낮춰서 캐시를 적용하는 수밖에 없을 것 같다.
@Cacheable
fun getInProgressEvents(on: LocalDate)