<aside> 🌃 DB를 빈번하게 조회하는 polling 방식의 api들 때문에, 다른 api들의 응답시간이 영향을 받는 것을 확인했습니다.

캐시를 도입해 문제를 해결하고자 했지만, 도입 과정에서 또 다른 문제에 직면합니다.

이번 글에서는 캐시를 도입하게 된 배경, 캐시 도입 과정에서 생기는 문제, 해당 문제를 transaction과 lua script로 해결한 방법에 대해 알아봅니다.

</aside>

1. 싸하다

1) 이거 괜찮나??

저희 서비스에는 고객 입장에서 현재 주문의 상태(대기, 수락, 거절, 완료)를 확인하는 기능과 점주 입장에서 새로 들어온 주문을 확인할 수 있는 기능이 있습니다.

각각의 정보는 변경 여부를 클라이언트 입장에서 확인할 수 없다는 점, 1초단위로 갱신될 필요까지는 없다는 점을 고려해 http poling 방식으로 구현하기로 결정했습니다.

나름 합리적이라는 판단이라 생각했지만, 이내 주기적으로 쏘는 API가 DB를 건든다는 것을 알아챕니다.

2) 확인해보자

각각의 API는 응답 속도가 느리다고 클라이언트 입장에서 불편해할만한 api는 아닙니다.

그러나 DB를 조회하는 다른 API들이 영향을 받을 수 있고, 문제가 될만 합니다.

응답 시간 확인

100개의 카페를 가정하고, 각각 10개의 대기중인 주문이 있다고 가정합니다.

1000명이 주문의 상태를 조회하기 위해 5초 간격으로 요청을 날렸을 때, 메뉴 상세 옵션을 조회하는 API(다른 API)가 영향을 받는지 확인해봅니다.

DB를 바로 조회했을 때를 확인해봅니다. 주문 데이터는 10만건 정도 쌓여있습니다.