@slowCoyle
의견 감사합니다.
코일말대로 현재로써는 Question에서 java 해시태그를 만들었다가 바로 해시태그만 삭제하는 Question수정이 일어난다면 Hashtag에서 지워지지는 않겠군요. 현재는 Question 삭제에만 이벤트 트리거를 걸었는데 수정에도 똑같이 걸어주면 어떨까요?

처음에 스케쥴링 방식을 생각했는데, 추후 비효율적이라 생각하여 이벤트 방식으로 구현했습니다.
만약 100개의 질문과 100개의 해시태그가 존재한다면 스케줄링 주기마다 모든 질문 모든 해시태그를 검사해야하기 때문에, 10000번 확인을 해야하는데, 1개 질문에 1개의 해시태그가 있다면, 질문의 삭제 혹은 수정이 일어날 때, 100번만 검사하면 되기 때문에 훨씬 더 부담이 적지 않을까 싶습니다.

예를 들어 한번 생각해보겠습니다.
스케줄링이 더 이득인 극단의 케이스를 생각해본다면, 만약 전체 질문 갯수가 1개이고, 해시태그가 100개 달려있는 경우 하루에 한번 스케줄링 시, 100번 검사가 일어나고 이벤트 방식으로는 삭제 혹은 수정이 일어날 때마다 100번 검사가 일어나겠죠. 이때는 하루에 질문 수정/삭제가 2번이상 일어나는 경우 스케줄링이 더 이득이라고 할 수 있겠습니다.

하지만 좀 더 평균적인 관점에서 계산해보면, 질문이 300개 있고 각각 해시태그가 2개씩 달려있고, 그 중 절반은 중복 해시태그라고 가정하면 총 300개의 해시태그가 있습니다. 이때 스케줄링을 할 경우, 90000번 조회가 일어나고 이벤트 방식으로라면 매번 600번의 조회가 일어나겠군요.
그럼 하루에 최소 150개 이상의 질문이 수정/혹은 삭제 되어야 스케줄링 방식이 더 효과가 있을 것 같은데 질문답변 도메인 특성상 그렇게 빈번한 호출이 필요할 것 같지는 않을 것이라고 생각했습니다.
(스케줄링 주기를 하루로 잡았지만 더 짧을 수록 더 이벤트 방식이 낫겟죠)

제가 생각하는 이벤트 방식의 장점

1. 질문의 삭제 혹은 수정이 일어나고 거의 바로 db싱크가 맞춰지기 때문에 사용자 입장에서 해시태그로 검색하는데 이상이 없다.
2. 실제 삭제되는 해시태그 갯수만큼만 검사하면 되므로 한번에 테이블을 검사하는 양이 적고, 하루 평균 질문의 수정/삭제가 일어날 횟수를 예상했을 때, 스케줄링 방식이 더 효과적이라고 보기 힘들다.

제가 생각하는 계산법으로 적은 거라 오류가 있을 수도 있습니다. 혹시 제가 놓치고 있는 부분이 있다면 편하게 지적해주세요 코일!