안녕하세요 무한스크롤 강의듣다가 질문이 있습니다.

동훈님, 안녕하세요! 쿼리 플랜에서 나오는 rows는 통계치 기반이고 실제로 그렇게 스캔하는게 아니므로 문제될 부분은 없습니다.줄이는 방법에 대해서 고민해본 적은 없고, 줄여야하는 이유에 대해서도 크게 신경 쓸 필요는 없을 것 같습니다.플랜은 실제로 스캔하는게 아니라 말 그대로 예상치를 기반으로 만들어진 계획으로 인지하시면 됩니다.반드시 플랜과 동일한 방식으로 수행되는 것도 아니고요.rows 수가 강의와 다르게 나오는 것에 대해서도, 각 환경의 데이터 분포나 통계치 갱신 시점 등에 따라서 차이가 있다고 봐주시면 될 것 같습니다.실제 쿼리는 LIMIT만큼 스캔하고 종료됩니다!

조회수 조회 로직 질문

쵸잉님, 안녕하세요! 말씀하신대로 레디스에 값이 없을 경우, 백업용 rdb를 추가로 확인해볼 수도 있습니다.해당 부분은 구현하기 나름이고 전략적인 부분으로 봐주시면 될 것 같네요.실시간으로 백업용 rdb를 조회해서 자동으로 복구 가능하도록 하거나,사람이 수동 개입해서 자동으로 복구 가능하도록 하거나 등 어떤 정책을 삼을지는 개발자의 선택이 될 수 있을 것 같습니다.일단 백업용 rdb는 이름 그대로 백업을 위해 설계된 것이고, 현 설계 특성 상 항상 데이터가 동일하진 않습니다.레디스 자체에서 복구 가능한 문제일 수 있는데, rdb로 모든 트래픽을 유입시키거나 레디스의 데이터를 아예 날려버리는게 문제가 되는 선택일 수 있습니다.그래서 정책을 정하기 나름인 것이고, 비슷한 개념으로 standby와 replica 차이에 대해서도 한번 고민해보시면 좋을 것 같네요!

비로그인 유저도 어뷰징 방지 정책

쵸잉님, 안녕하세요! 비로그인 사용자에 대한 완벽한 해결책은 없습니다.말씀하신대로 IP는 계속 변할 수 있고, User-Agent와 브라우저 쿠키 모두 조작이 가능한 값입니다.말씀 주신 http only 쿠키도 마찬가지고요.User-Agent와 쿠키는 서버에서 지정해둔 값들만 허용하도록 한다면, 조작하는 방법을 모르는 비정상 사용자만큼은 적어도 방지할 수 있습니다.그래도 조작이 있다면 IP와 같이 매번 바꾸기 어려운 값을 보고, 특정 임계치를 넘어간다면 제한을 걸어버릴 수도 있네요.도메인의 성격에 따라서 정책으로 풀어내는 것도 방법일 것이고요.강의에서는 동기적으로 처리하는 방식이지만, 모든 요청을 따로 쌓아놓고 비정상으로 판단되는 요청들은 필터링하는 등의 비동기 전략을 취할 수도 있습니다.또는, 애초에 비로그인 사용자 요청은 집계 안하거나 어떠한 문제를 풀게 해서 봇이 아닌 사람이라는 사실을 확인시키는 등의 방법들이 있을 것 같네요!꼭 한 가지 방법으로 해결할 수 있는 문제는 아니고, 시스템 특성에 따라서 다양한 방법을 고민해볼 수 있습니다. 실제로도 여러 방법들을 종합하게 되네요!

CommentServiceTest의 테스트 로직 질문

bebe님, 안녕하세요! 저도 다시 살펴보니 위 가정에서는 굳이 1로 반환할 필요가 없네요.테스트 결과에 영향은 없지만 commentId=2의 자식은 아무도 없으므로 0으로 반환하는게 이치 상 맞고 이해도 수월할 것 같습니다.결론은 bebe님이 이해하신 부분이 맞습니다! 혼란을 드려 죄송합니다.

무한 스크롤 방식에서 페이지 번호 방식 쿼리의 문제점 의문

재량님, 안녕하세요!사용성과 실제 쿼리 사이에서 혼동이 있으셨을 것 같습니다.무한 스크롤은 사용성 기준이고, offset/limit 방식의 쿼리에서 위 문제가 발생한다는 의미입니다.무한 스크롤 사용성이든, 페이지 번호 사용성이든, offset/limit 방식의 쿼리에서는 위 문제가 여전히 발생합니다.무한 스크롤 사용성에서는 위 문제가 사용자에게 혼란을 야기할 수 있기 때문에 새로운 쿼리 방식을 설명하게 되는 것입니다!

path 쿼리 관련 질문드립니다!

안녕하세요!이 부분은 제보 받고 저도 뒤늦게 인지된 부분인데요, 말씀하신대로 findByArticleIdAndPath가 맞습니다..!강의 메모 남겨둬야겠네요. 제보 감사합니다.

프로젝트 구조

rmcns님, 안녕하세요! 실제 프로젝트 구조는 팀마다 다를 수 있고 세부적인 사항까지 제가 모두 다 알 수 없기 때문에 "주로" 사용한다고 말씀 드리긴 어렵지만, 현업에서도 사용해도 충분한 구조이고 더욱 개선해서 사용할 수도 있습니다.현업에서는 도메인이나 애플리케이션이 더욱 많기 때문에 네이밍 또는 구조 등으로 더욱 체계적인 구성이 필요할 수 있네요.업무 진행하시는 환경처럼 멀티레포로 관리할 수도 있고, 모노레포에서 멀티모듈 구조를 관리할 수도 있는 것이므로 꼭 특정한 구조가 정답이라고 생각하실 필요는 없습니다.처음에 모노레포 운영하다가 멀티레포로 분리하는 상황이 생길 수도 있고, 멀티레포를 모노레포로 합쳐야할 수도 있고, 프로젝트마다 구조가 다를 수도 있기도 합니다.개인적으로는 강의 구조보다 더욱 복잡하고 세분화된 구조를 운영하고 있는데, 여기에서 근거 등을 담아내기엔 어려움이 있네요.각 도메인의 비즈니스를 체계적으로 잘 관리할 수 있다면, 처한 환경에 알맞은 구조를 만들어나가면 충분할 것 같습니다.

이벤트 페이로드 객체의 생성 방식이 팩토리 메서드 패턴이 아닌 빌더 패턴인 이유가 궁금합니다!.

종혁님, 안녕하세요!강의 통해서 잘 성장해주고 계시다니 감사하네요! 질문 주신 부분에 대해서는 팩토리 메소드의 장점에 대해서 찾아보면 더욱 와닿으실 것 같습니다.동일한 객체 생성이더라도 여러 의도로 나뉠 필요가 있다면, 메소드 네이밍으로 그 의도를 명확하게 드러낼 수 있을 것이고요.단순히 필드 값을 assign 하고 어떠한 의도를 드러낼 필요가 없다면 그냥 빌더 패턴을 써도 무방합니다.하지만 그 의도를 명확하게 드러내고 싶거나, 부가적인 로직이 필요할 때 팩토리 메소드 내부로 캡슐화할 수도 있습니다.null에 대해서도 결국 값에 대한 검증이나 부가적인 로직이 필요한 상황을 말씀하신 것 같아요, 이 경우에도 말씀하신대로 빌더 보단 팩토리 메소드를 활용하는게 위에 언급된 이점들이 있습니다.그렇기 때문에 개인적으로 팩토리 메소드를 선호하고 활용하고 있네요! 최근에 유사한 질문을 받았던 게 있어서 참고해보셔도 좋을 것 같습니다!https://inf.run/WgKso

article_like_count api test

안녕하세요! 비관적 락은 실패 없이 모두 정상적으로 처리되는게 맞지만,낙관적 락은 멀티스레드로 처리하기 때문에 일부 요청들은 분명 실패할 수 있을텐데 전부 성공 했다는건 이상하네요.낙관적 락 방식에 대해 멀티스레드로 동시 요청을 보낸 것이 맞을까요?

[33. 좋아요 수 구현] 에서 테스트 하는 화면 동시성 문제

주주파파님, 안녕하세요! 이전에도 동일한 질문이 있었는데요(https://inf.run/f8wTm),제가 데이터베이스 개발자는 아니다보니 각 DB별 상세한 내부 동작까지는 저도 명쾌하게 답변드리긴 어렵기 때문에, 일단 강의와 동일한 환경으로 진행하는 것을 권장 드리고 있습니다. 추가로 원인 관련해서는 찾아보았는데요, 정확히 어떤 쿼리와 어떤 db 버전에서 해당 에러가 발생했다는 말씀이실까요?https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-system-variables#innodb_snapshot_isolationinnodb_snapshot_isolation 설정이 디폴트로 ON이라면, 위 에러가 발생할 수 있을 것 같습니다. (설정에 대한 설명과 버전별 차이에 대해서는 위 문서 참고)강의에서 진행하는 mysql 실습 환경은 단일 레코드에 대한 동시 업데이트 시에 락을 획득하려고 대기하게 되지만,maria db에서 snapshot isolation 설정이 ON이라면 언급 주신 에러를 던지게 되는 동작이네요.innodb_snapshot_isolation 설정을 OFF로 변경 후 테스트 해보시겠어요?