환경은 windows 11 64비트이구요,자바 21, redis는 물론 docker 8.2.1 실행 중이엇구요 하지만SplitShardedBloomFilterRedisHandlerTest 클래스에 mightContain 테스트 함수 실행 하면 첨부한 이미지 처럼 에러가 출력 됩니다. 아래는 docker 버전 정보입니다. 

현재 강의에서는 Inventory table을 따로 분리해두었습니다.그런데 Inventory Table을 분리한 이유에 대해 말씀해 주실 때, 분리하는 게 좋다고만 말씀해주신 것 같아서 설명이 부족하다는 생각이 들었습니다. Inventory가 재고라는 의미를 가지는 것으로 알고 있어서 items table에 있는 수량을 Inventory로 옮기는 것이 더 옳은 설계가 아닌가라는 생각이 들었습니다.물론 지금 강사님께서 설명해주신 구조도 맞다고 보지만, 그 구조를 유지한다면 현재 Inventory table에 유의미한 칼럼이 없기 때문에 Inventory table이 없어야 하지 않나라는 생각을 했습니다. 그리고 재고가 자주 바뀌는 상황이 발생한다고 한다면 오히려 Inventory table에 재고를 넘겨줘야한다고 생각을 하는데요. 왜냐하면 Items table에 재고 칼럼이 있다면 재고가 바뀌는 순간에는 Items table의 데이터를 수정할 수 없게 됩니다. 그러면 관리자가 Item을 수정하려고 할 때, 재고가 많이 바뀌는 상황에는 그만큼 수정 쿼리가 대기를 하게 될 것이라고 생각하는데요. (물론 이 정도까지의 문제는 생기지 않을 것이라고 생각합니다.) 또한 이 글에서 강사님께서 말씀해주신 유형별 재고 관리 정책 부분은 Inventory가 재고라는 성격을 나타낸다는 점에서 Inventory table에서 관리할 것 같고, 트래픽 증가 시 성능 문제가 생긴다면 여기서 또 테이블 분리를 시도하거나 레디스 같은 memory DB를 생각해볼 수 있을 것 같습니다. 그래서 질문은현재 재고 칼럼의 위치를 어디에 두는 게 맞는지, 트래픽 증가의 성능 문제가 있다면 오히려 Inventory 테이블로 넘겨주는 게 맞는게 아닌지유형별 재고 관리 정책이 필요한 경우에 강사님께서 생각하시는 확장성 있는 구조는 무엇인지가 궁금합니다.  혹시 제가 잘못 알고 있거나 잘못 이해한 부분이 있다면 같이 짚어주시면 감사하겠습니다!

안녕하세요 백엔드 개발자를 희망하고 있는 학생입니다.유저별 포인트 같은 정합성이 중요한 데이터로 로그를 따로 관리 해야한다고 말씀 해 주셨는데 이런 경우(배치 도구를 스프링 배치를 사용할 경우에) 로그 테이블을 따로 만들어서 관리 해주는게 나중에 자소서 쓸 때도 도움이 되나요?   

안녕하세요!강의를 통해 많은 인사이트를 얻었습니다. 좋은 강의 제공해주셔서 감사합니다. 강의를 수강하는 과정에서 궁금한 점이 생겨 질문 남깁니다. 시스템 디자인 단계에서 응답 시간(P95/P99)이나 TPS 같은 성능 목표를 설정할 때,인스턴스 스펙이나 인프라 제약도 함께 고려해야 하는지가 궁금합니다. 특히 학생이나 개인 프로젝트의 경우 프리티어처럼 제한된 리소스를 사용하는 일이 많은데,이런 환경에서는 인프라 제약을 기준으로 현실적인 목표치를 설정하는 것이 맞는지,아니면 인프라 스펙을 별도로 고려하지 않고 일반적인 목표값을 그대로 설정하는 것이 더 바람직한지 조언 부탁드립니다. 감사합니다!

 ------------------------------ 해결 방안-------------------------------저와 비슷한 이슈가 있으신분은 이렇게 처리 부탁드립니다! 인텔리제이 설정에서 Preferences > Build, Execution, Deployment > Build Tools > Gradle에서Build and run using : GradleRun tests using : Gradle 이렇게 수정 하고 다시 시도 부탁드립니다!!!  쿠케님 감사합니다 :)    안녕하세요 우선 좋은 강의 만들어주셔서 정말 감사드립니다.GET - http://localhost:8080/cache-strategy/NONE/items/{{itemId}} 해당 API 를 호출 하게 되면ItemController -> KukeCacheAspect -> KukeCacheKeyGenerator -> ItemNoneCacheService  대충 이런 흐름으로 가게 되는데요.KukeCacheKeyGenerator 객체에서 for (int i = 0; i<args.length; i++) { context.setVariable(parameterNames[i], args[i]); } parameterNames 객체에 NPE 에러가 발생 되고 있습니다.코드는 강의 자료실 통해 제공해주신 코드로 실행 해보았습니다. 이 부분 어떻게 수정을 해야 할까요?  

안녕하세요, Tinder 설계 강의 내용에 궁금한 점이 생겨 질문 드립니다. Matching Service와 Cassandra 사용에 대한 질문입니다.Matching Service의 MQ와 /swipe의 matching 응답값 강의에서는 REST API는 지연이 발생할 수 있으므로 MQ를 사용했다고 말씀하셨습니다. 이때 API 명세에 있는 matching 값의 해석이 헷갈립니다. matching은 swipe 시점에서 자신이 상대와 매칭되었는지 알 수 있는 값이라고 생각되는데, 그러면 동기 처리가 필요한 것 아닌가 생각이 듭니다. 즉 Cassandra에서 inverse swipe이 존재하는지를 확인한 뒤에야 API 응답을 보낼 수 있는 것 아닌가요?Cassandra의 필요성RDB 조회만으로 inverse swipe 여부를 파악할 수 있을 것 같습니다. 그러면 Cassandra는 캐싱 용도로 사용한 것이라고 보아야 하나요? 원래 설계에서 Cassandra가 자연스럽게 도입된 이유가 궁금합니다.Cassandra - RDB 동기화 여부swipe 기록을 RDB와 Cassandra에도 모두 저장할 때, 일시적 오류 등으로 한쪽에만 저장될 수도 있을 것 같은데, 이런 상황에 대비해 RDB와 Cassandra 간 동기화가 필요한지 궁금합니다.감사합니다.

시스템 디자인 관련 질문서버가 PreSigned URL 을 발급하면 클라이언트가 URL 을 기반으로 Blob Storage에 다이렉트로 파일을 업로드 한 것으로 이해했습니다.클라이언트가 업로드를 하는데 서버가 현재 청크의 진행상황을 탐지하여 Key-Value 에 업데이트 하는 메커니즘이 궁금합니다.가령 서버가 Blob Storage 를 주기적으로 찔러 업데이트하는 과정일지 궁금합니다. 그림 상으로는 서버가 청크 진행상황을 알기위해서 추가적인 메커니즘이 있을까 생각이 들어서요.

안녕하세요!덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다.모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요?물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다.예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다.감사합니다!

안녕하세요 강사님! 강의 잘 듣고 있습니다.실제 서비스 환경에서 로드 밸런서를 두는 시점(예: 트래픽 기준이나 서버 수 기준)을 어떻게 판단하시는지 궁금합니다.단순히 서버 부하율이 높아졌을 때 적용하는 건지, 아니면 아키텍처 설계 초기에 미리 구성하는 경우가 더 일반적인지도 궁금합니다.

안녕하세요!시스템 개발 및 설계 과정에서 '대규모 시스템', '분산 환경', '분산 데이터 모델링'과 같은 개념들을 본격적으로 고려하고 도입해야 하는 시점은 언제일까요?실무에서 경험해보지 못해서 '대규모' 라는 말이 막연해서 실무에서 어떤 것을 기준으로 고려하는지 혹은 지표 같은 것을 측정하는 방법이 있는지 궁금해서 질문 드립니다!

일반적으로 websocket 연결은 클라이언트 쪽에서 먼저 하나요? 혹은 서버쪽에서 먼저 하게 되나요?또한 연결을 끊을때도 클라이언트/서버 어느쪽에서 먼저 하게 되는지 궁금합니다!백그라운드 상태에서도 websocket 연결은 계속 유지되고 있나요?

예시로 들었던 '게시판 별 게시글' 같은 인덱스 테이블에서 B Tree 인덱스를 사용하면 된다는 식으로 말씀하셨습니다.근데 전통적인 RDBMS에는 샤딩 기능조차 존재하지 않는데, 분산된 데이터베이스에서도 테이블 수준의 B Tree 인덱스처럼 동작하는 것처럼 말씀하신 것 같아, 이것이 맞는지 문의 드립니다.

고성능 실시간 분산 시스템 RabbitMQ + Kafka + Redis 실전 프로젝트쿠폰이 비활성화되었다고 나오는데 혹시 새로운 쿠폰 링크를 업데이트해주실 수 있나요?

우와아 아키텍처에 대해 고민하게 된 비전공자인데올려주신 강의가 많은 도움이 되었습니다.감사합니다 :)!

안녕하세요.채팅시스템 1:1 메시지 플로우에서 질문드립니다chat server ichat server j... chat server n존재할때 각 클라이언트는 서로다른 서버에 websocket 프로토콜로 연결이 되어있을꺼 같은데요이때 i 서버에 있는 sender 가 j 서버에 있는 receiver 에서 메시지를 전송한다고 했을때 온라인시점에서 i 서버에서 메시지를 전송했다는 이벤트(혹은 시점)를 j 서버가 인지해야 각 서버의 websocket 에 연결되어있는 클라이언트들에게 메시지를 push 를 해줄수 있을꺼같은데요키 벨류 스토어 외에 메시징 관련 시스템이 별도로 있어야 할꺼같은데 강의에서 해당 내용을 어떻게 설명해주신지 (큐를 통해 설명해주신건지) 명확하게 이해를 못한부분이 있어 질문드리게 됐습니다감사합니다

Redis에 랜덤한 값을 키에 저장할 시 해당 키 탐색을 위해 FULL SCAN O(1) 대신 메타데이터를 통해서 탐색한다고 말씀하셨는데이 메타데이터 자체도 Redis에 저장하는건가요? 아니면 programmatically하게 Map이나 딕셔너리에 저장한다는 의미인가요?

이정도 스콥만 어느정도 완전히 인지하면 시니어 레벨 엔지니어 시스템 디자인 인터뷰는 어느정도 커버 될까요?

용량이 큰 파일의 binary를 기반으로 해시화해서 동시 업로드 할 경우 동일한 파일이 업로드 될 수 있을 것 같습니다. 이럴 경우 해결책이 있을까요?

같은 요청이 여러 번 들어와도 한 번만 처리하는 것. 여러 번의 요청이 들어왔을 때 이 요청이 '같은 요청' 이라는 것을 정확하게 판단할 수가 있을까요?예를 들어 똑같은 점포의 똑같은 POS에서 똑같은 액수의 포인트 적립/사용이 두 번 들어왔을 때,이 두 요청이 각자 다른 요청인지? 클라이언트 단의 문제로 인해 같은 요청을 두 번 보낸 것인지? 정확하게 판단할 수 있는 걸까요?두 요청의 도착 시간 간격이 매우 짧을 때-> 일반적인 상황에서 같은 동작이라고 판단할 수야 있겠지만.. 매우 빠르게 요청을 계속해서 받아야 하는 상황이라면?도메인 특성에 따라 같은 요청임을 판단할 수 있는 기준이나 상황이 달라지기야 하겠지만 정확하게 보장 받을 수 있는 기준은 존재하기 어렵지 않나 하는 생각이 듭니다.실제 사례를 통해 예시를 들어주실 수 있는 게 있을까요?

채팅은 강결합할 트랜잭션이 불필요해보이는데 nosql을 사용 하지않는 이유는 뭘까요?