캐시 구현에서 Redis - MongoDB 스코프

Question

제가 이해한 구조는 아래와 같습니다. Request -> API -> Service -> Entity   Redis에서 캐시 조회 실패하면 redis에서 몽고 db collection 관련 함수를 직접 조회 하는 게 아니라 서비스로 돌아가서 서비스단에서 몽고 db collection 관련 함수를 호출하는게 맞지 않나요?   아니면 주신 코드 처럼 Entity 단에서는 서로를 호출하면서 작동하는게 맞나요?

recordable07111249 · Answer

파사님 안녕하세요! 이건 제 강의에서만의 규칙인데요~ entity 는 repository 와 collection 을 가질 수 있다고 보았습니다~ redis 를 직접 호출하는 채임은 redis repository 안으로 제한하구요

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 파사님, 질문해주신 내용은 백엔드 설계에서 중요한 개념인 캐싱 전략과 레이어 간의 상호작용에 대한 것입니다. 먼저 이해하고 계신 구조를 살펴보면, 일반적으로 API 요청은 Service 레이어를 통해 Entity와 데이터베이스에 접근하는 것이 맞습니다. 이는 레이어 간의 명확한 책임 분리를 통해 유지보수성과 코드의 가독성을 높이기 위함입니다. Redis를 캐시로 사용할 때, 다음과 같은 흐름이 주로 사용됩니다: 사전 조회: 요청이 오면 먼저 Redis에서 데이터를 조회합니다. 캐시 미스 시: Redis에 데이터가 없는 경우, Service 레이어를 통해 MongoDB를 조회하여 데이터를 얻습니다. 캐시 갱신: MongoDB에서 데이터를 가져온 후 Redis에 데이터를 갱신합니다. 응답: 최종적으로 데이터를 사용자에게 반환합니다. 이와 같은 흐름에서, Entity 레이어가 직접 Redis나 MongoDB와 상호작용하는 것은 권장되지 않습니다. 대신, Entity는 데이터를 추상화하고, 비즈니스 로직을 처리하는 역할을 Service가 담당하며, 데이터베이스와의 상호작용은 Repository 패턴에서 처리합니다. 관련된 기존 질문으로는 다음을 참고할 수 있습니다: 테스트를 실행했을 때 RuntimeError: Event loop is closed 에러가 발생합니다. - 데이터베이스와의 연결 및 비동기 처리 관련 질문입니다. 각 레이어의 역할과 책임을 명확히 하고, 서비스 레이어를 통해 모든 데이터베이스 접근을 관리하면 보다 안전하고 유지보수하기 쉬운 구조를 갖출 수 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.