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

종혁님, 안녕하세요!강의 통해서 잘 성장해주고 계시다니 감사하네요! 질문 주신 부분에 대해서는 팩토리 메소드의 장점에 대해서 찾아보면 더욱 와닿으실 것 같습니다.동일한 객체 생성이더라도 여러 의도로 나뉠 필요가 있다면, 메소드 네이밍으로 그 의도를 명확하게 드러낼 수 있을 것이고요.단순히 필드 값을 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로 변경 후 테스트 해보시겠어요?

findByPath에서 articleId로도 검색을 해야 할 것 같아요.

주주파파님, 안녕하세요!아이고 말씀하신대로 findByPath가 아니라 articleId도 쿼리에 포함되어야 합니다.이 부분 놓쳐졌었네요 ㅠ 제보 감사드리고 추후 수정해두도록 하겠습니다!

jpa ddl-auto none을 하는 이유와 join 방법

쵸잉님, 안녕하세요! 일단 먼저 말씀드리고 싶은 점은, 사고가 jpa에 종속되지 않는게 좋을 것 같습니다!실무에서는 jpa를 사용하지 않는 경우도 많고, 개인적으로도 선호하진 않습니다.제 주변에서도 딱히 선호하는 경향은 드물기도 하고, 사용하더라도 단순 crud만 쓰는 사례도 많습니다.그리고 결국 jpa가 만들어주는 것도 sql 스크립트일 뿐입니다. Q. SQL 로 미리 테이블 작성하거나 인덱스 설정을 SQL 로 직접하는데 이유가 궁금합니다인덱스 같은경우 jpa 에서 쓸수있는 옵션이 제한적이라 따로 SQL 로 관리한다고 듣긴했는데 테이블도 실제로 SQL 에서 하는지 궁금하고, SQL 로만 테이블 생성 인덱스 관리를 할경우 현업에서는 어떤 db 마이그레이션 라이브러리를 주로 사용하는지도 궁금합니다.테이블이나 인덱스 스크립트는 별도 문서 또는 툴이나 스크립트로 관리되는 것이 일반적일 것 같습니다.한번 생성 이후 자바 코드로 남겨둘 이유도 없고, 히스토리 관리도 어렵고, 오히려 불필요한 코드로 가독성만 나빠지게 될 것 같네요.ddl-auto none으로 설정하는 이유는, 운영 중 새롭게 배포된 자바 코드로 인해 갑작스레 스키마 또는 인덱스가 변경되면 시스템에 장애를 유발할 수 있습니다.db 마이그레이션은 어떤 질문을 주신건지 잘 이해를 못하였는데, jpa 코드로 인덱스를 생성한다고 해서 자바 라이브러리가 인덱스에 대한 마이그레이션을 수행해주는건 아닙니다. 인덱스 스크립트를 자바에서 만들어서 db로 전달해줄 뿐, 실제로는 모두 sql 기반으로 스크립트가 실행되어서 db 자체에서 인덱스가 생성됩니다. Q. 참조관계를 DB 에서 걸지않고 논리적으로만 걸었을때 참조테이블에대한 조인은 어떤식으로 하는지 궁금합니다.MSA 기준으론 데이터베이스가 아예 분리될텐데 어떤식으로 조인하나요?추가적으로 논리적으로 참조설계가 된 상황에서 @ManyToOne 사용이 가능한지궁급합니다. 예를들면 Comment 엔티티에서 parentCommentId 같은 같은 데이터베이스에 있는 테이블에 @ManyToOne 적용이 가능한지궁급합니다.MSA 기준으로 데이터베이스가 분리되면, 애플리케이션 레벨에서 각 마이크로서비스마다 필요한 데이터를 질의하여 조인하게 됩니다.이 경우에 조인을 위한 네트워크 통신 비용, 질의 비용, 응답 지연 등의 문제가 생기게 되는데, 이를 해결하는 방법은 마지막 챕터 최적화 전략에서 일부 살펴보게 되네요!@ManyToOne은 물리적 외래키를 강제하진 않고, 논리적 참조라고 하더라도 사용할 수 있습니다.논리적 참조되는 컬럼에 대해 인덱스만 잘 고려되면 될 것 같네요.하지만 위에서 JPA에 대해 회의적인 입장을 말씀 드렸듯이, @ManyToOne과 같은 연관 관계 애노테이션도 잘 사용하진 않습니다.객체 간 참조 강결합과 코드와 내부적인 쿼리 실행 방식 이해에 복잡함을 수반하기 때문에 개인적으로 지양하는 방향이고, 애초에 엔티티가 코드 또는 DB 레벨에서 물리적으로 격리되어 있다면 참조할 수도 없습니다. 충분한 답변이 되었을지 모르겠네요. 혹시 더 궁금한 점 있으시면 편히 남겨주세요!

팩터리 메소드와 response 객체 사용 이유가 궁금합니다!

88diaspora님, 안녕하세요!잘 배워주고 계시다니 감사하네요! 국비학원 프로젝트 하던 때를 생각해보면서 듣고 있는데, 그때는 엔티티에 생성자를 만들어서 서비스에서 그냥 썼는데 본 강의에서 팩토리 메소드 형태를 사용하는 이유가 궁금했습니다!! (기술적으로 더 진보한 형태인지요)동일한 클래스더라도 객체에 대한 생성 의도는 모두 다양할 수 있는데요, 생성자와 달리 팩토리 메소드는 네이밍으로 의도를 명확하게 드러낼 수 있습니다.예를 들어, User 객체를 생성한다면, 관리자(User.admin()), 일반 사용자(User.normal()), 단순 변환(User.from(dto)), 에러 시에 디폴트 객체 응답(User.empty()) 등 팩토리 메소드를 활용하면 코드의 의도가 더욱 명확하게 드러나게 됩니다.또, 매번 새로운 객체를 생성할 필요 없이 동일한 객체를 재사용해도 된다면, 팩토리 메소드에서 캐시된 객체를 반환하는 등 더욱 유연하게 활용할 수 있고요. (User.empty() 같은건 싱글톤 객체로 반환)다른 이점으로는 하위 타입으로 반환해줄 수도 있습니다. 예를 들어, List는 인터페이스인데 List.of(“a”)는 실제 하위 타입으로 구현체를 만들어줍니다.외에도, 팩토리 메소드와 생성자의 차이는 검색해 보시면 많은 자료를 찾아보실 수 있을 것 같네요! 그리고 객체마다 response를 만들어서 commentResponse, ArticleLikeResponse 같은걸 만들어 api 반환에 사용하는데, entity랑 필드도 다르지 않은데 굳이 이렇게 일일이 response 객체를 각각 만들어서 코드를 짜야하는지 궁금합니다!!반드시 그럴 필요는 없지만, 내부적인 도메인 모델과 응답 모델을 별도로 관리하는게 유리한 상황이 많습니다.클라이언트에게 불필요한 데이터까지 도메인 모델에 포함된 상황(보안, 데이터 크기, 전송 지연 등 문제) 클라이언트의 요구사항과 도메인 모델이 일치되지 않는 상황(여러 모델을 조합하거나 추가적인 가공이 필요할 수 있음)위와 같은 상황들을 생각해 보시면 이해가 편할 것 같네요!

RateLimitTest시 저는 2초로 해야 정상으로 나오는데

wisehero님, 안녕하세요! 네, 말씀하신대로 2초로 해야 성공하는게 정상입니다.1초는 환경이나 시점에 따라 성공할 수도 있고, 실패할 수 있습니다.왜 TTL은 1초인데 sleep은 2초나 필요한지 의문이실 수 있을 것 같은데요,컴퓨터가 물리적으로 완벽하게 정확한 시간을 보장할 수는 없어서,미세한 시간에 대해서는 오차와 지연이 생길 수 있기 때문입니다.실제로는 정확한 1초가 아니라, 약 1초라고 봐주시면 됩니다.그래서 테스트에서는 미세한 시간 차에 의한 타이밍 문제를 피하기 위해 그냥 여유롭게 2초 sleep으로 작성한 것입니다!

커서 기반 페이지네이션 과 무한 스크롤링

KMC님, 안녕하세요! 무한 스크롤링은 두 번째부터 보통 끝쪽 id 에 데이터를 기반으로 데이터를 불러오는 방식이보통 커서 기반 페이지네이션과 큰 차이가 없는 건가요? (claude 나 ) 블로그 보면서 이것도 비슷한 개념인 거 같아서 질문 드립니다.무한 스크롤 사용성에서 특정 기준점(강의에서는 마지막 ID)으로 다음 데이터를 불러오는 것이 커서 기반 페이지네이션입니다! 동일한 의미입니다.무한 스크롤은 실제 사용자 입장에서의 용어이고, 내부적인 구현 관점에서는 커서 기반으로 동작합니다.물론, 무한 스크롤이 항상 커서 기반으로 동작해야한다는 것은 아니고, offset/limit 방식으로도 무한 스크롤링을 구현할 수는 있습니다. 다만, 무한 스크롤링이라 하면 커서 기반 구현을 일반적으로 사용하긴 하네요. 이렇게 엔티티에 인덱스를 만들어서 사용하는지 궁금합니다. 강의에서 처럼 SnowFlake도 보통 저렇게 인덱스를 만들어서 활용하는지도 궁금합니다.Snowflake는 그저 오름차순 수를 충돌없이 빠르게 생성하기 위한 알고리즘이고, 이러한 특성으로 인해 primary key로 사용될 뿐 인덱스와는 무관합니다.아무튼 엔티티에 인덱스, 연관 관계 등의 애노테이션을 질문주신 것으로 이해했는데요.그렇게 해도 되고, 안해도 됩니다. 강제될 부분도 없고 자유롭게 하면 됩니다.하지만 조금 더 실무 관점에서 본다면, 인덱스를 코드에 애노테이션으로 정의하는 경우는 잘 없습니다.물론, 위처럼 사용하는 사람도 있겠지만, 한번 사용되고 말 코드이고 DDL은 별도 스크립트 또는 문서로 관리하거나 db에 생성된걸 직접 보는게 일반적인 것 같네요.연관 관계 애노테이션도 객체 간에 강결합되면 유지보수도 어렵고, 애초에 분산 환경이라면 객체 참조 자체가 어려울 수 있어서 굳이 사용하진 않네요.저와 주변의 경우를 보면, 애초에 JPA 자체를 안쓰는 경우가 더욱 일반적이라고 생각되네요.

섹션3에 22번째 강의에서 에러발생합니다..

MinKyu Song님, 안녕하세요! 코드가 아닌 로컬 환경에 관한 부분은, 제가 정확한 원인을 추적할 수 없다보니 직접 해결해 드리기엔 어려움이 있네요..! 이전에 RedisTestContainerSupport 처음 만들고 테스크 수행했던건 정상적으로 돌아가고 있고,SplitShardedBloomFilterRedisHandlerTest.mightContain 테스트만 실패하고 있다는 말씀이실까요? 로컬에 도커가 잘 실행되고 있는지 다시 한번 점검해보시고,구글에 Could not find a valid Docker environment 검색해보면 비슷한 사례들이 나오는데 하나씩 확인해보시겠어요?

게시글 생성 로직에서 오류 발생시 redis 게시글 수 되돌리기

songso0412님, 안녕하세요! 강의에서는 게시글 생성과 게시글 수의 정합성을 위해 모두 rdb에 저장하고 단일한 트랜잭션으로 관리하는 전략을 취하고 있는데요,그와 별개로 redis에 게시글 수를 저장하는 상황을 말씀하시는 것일까요?rdb 트랜잭션이 커밋된 후에 redis 증가가 실패하거나,redis 증가된 후에 rdb 트랜잭션이 롤백되는 경우가 있겠네요. 정합성을 반드시 100% 완벽하게 지켜야하는지에 대해서도 고민해볼 수 있을 것 같습니다.이러한 상황이라면 트랜잭션이 롤백될 때의 예외를 캐치해서, 애플리케이션에서 redis 카운트를 다시 감소시켜주면 됩니다.물론 이렇게 하면 redis 감소 코드가 실패할 수도 있기 때문에 정합성은 완벽하게 보장되진 않습니다.하지만 오류로 인해 정합성이 깨지는 상황이 흔하게 발생하는 것도 아니고, 어떤 데이터인지에 따라서 깨지는게 문제되지 않을 수도 있습니다.후처리 보정을 넣는 전략도 겸할 수 있는 것이고요. 감지가 되었을 때, 문의가 들어왔을 때, 주기적으로 검사(샘플링 등)할 때 등 데이터의 정합성을 뒤늦게 보정 시켜줘도 시스템 운영에 크게 문제가 없을 수 있습니다.무튼 이렇게 애플리케이션에서 보상 트랜잭션을 수행해서 해결할 수 있습니다. (별도의 트랜잭션 또는 로직으로 정합성을 맞춘다는 의미입니다. 하지만 보상 트랜잭션에 대한 실패에 대한 고려도 필요하네요.) 근데 정합성이 주요하다면, rdb 트랜잭션으로 묶어내는게 가장 간단하고 확실한 해결책일 수 있습니다.정합성을 위한 다른 방법으로는, 마지막 챕터에서 소개하는 Transactional Outbox 전략과 컨슈머의 멱등 또는 중복 방지 전략을 취할 수도 있습니다.게시글 생성 트랜잭션이 완벽하게 종료되었을 때에 이벤트를 유실 없이 보내고, 컨슈머에서는 게시글 수를 증가시켜줍니다. 물론 중복 이벤트에 대한 문제가 발생할 수 있기 때문에 일정 시간 버퍼해두거나 처리한 이벤트에 대해서는 관리하는 전략을 겸해야겠네요. 어떠한 사유로 redis에 관리하시려는 의도인지 정확히 파악한건 아니지만,저라면 정합성이 필요한 데이터를 rdb/redis에 분리 저장하면서까지 인프라와 운영 복잡도를 높일 바에야 rdb 단일 트랜잭션을 이용할 것 같습니다.조회 성능에 대한 우려가 있다면(공간에 대한 우려는 오히려 없을 것이고요), rdb에 먼저 쓰기 작업을 한 뒤에 redis에 읽기용으로 따로 데이터를 캐시해둘 수도 있는 것이고요. 딱히 정답은 없고 시스템 운영 방식에 따라서 해결책도 다양할 수 있어서, 상황에 알맞게 적당한 방법을 찾아나가는게 좋을 것 같네요!