고성능 실시간 분산 시스템 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을 사용 하지않는 이유는 뭘까요?

URL 생성 write 시나리오에서,short url을 생성하고redis counter를 증가시키고db에 저장하고캐시를 업데이트하는 부분이 있는데요.이때 redis counter를 어떤 용도로 사용하는 것인지 이해가 잘 가지 않습니다. 추측으로는, redis counter를 통해 발생한 새로운 값으로 인코딩해 shortUrl을 생성하는 케이스였다면 redis counter를 증가시키고, short url을 생성해주었을 것 같습니다. non functional 요구사항인 100억개의 url limit을 체크하기 위함이 제일 합리적일 것 같은데, 그렇다면 db에 저장하는 부분이 이해가 안돼서요. 이부분 추가 설명 부탁드려도 될까요?

1권에 대한 범위가 커버되고 있는 것으로 보이는데요~! 2권이나 머신러닝에 대한 추가 계획도 있으실까요? 너무 귀중한 자료가 될 것 같아요

visitor는 short url 로만 접근user는 자신의 short url list를 검색할때 userid 기반으로 파티셔닝 탐색 위 두가지 유즈케이스일거라, 강의 중에 말씀해주신 traffic distribution이 어떤 의미인지 잘 모르겠어요   

(알고리즘 코드 작성이나, 스키마 설계까지는 인터뷰에서 해본적은 있는데 아직 객체 모델링이나 수도코드 작성까진 해본 적이 없어서요) 강의와 비슷한 과정으로 진행되는걸까요?

제시해주신 테이블 설계에서 요것을 어떤 방식으로 구할 수 있을까요?score_level 테이블 설계에서 참조키가 누락된거같아요 enrollments 테이블에 대한 참조키를 넣는게 적당할까요?

 인벤토리 테이블의 성격이 재고 개념으로 정규화된 것으로 보이는데, 컬럼값이 옮겨가야하지않을까 싶습니다

시스템 디자인 관련 질문강의 말미에 서비스 fail 시에 use backup clusters로 언급만하고 넘어가셨는데 좀 더 자세하게 설명 부탁드리겠습니다fail 되는 특정 시점을 기준으로 내부의 시스템들이 어떻게 동작하는지 궁금합니다fail에서 정상으로 복구하게 되면 어떤 절차에 따라서 다시 원래의 서비스로 전환되는지도 궁금합니다 

강의자료 어디서 받나요?

안녕하세요!강의 마지막 부분의 scaling - partitioning 관련해서 이해가 안가는 부분이 있어서 질문 드립니다. partitioning key를 userId로 했을 때, 장단점에서장점의 '트래픽을 줄일 수 있다'에서 어떤 트래픽을 의미하는지 잘 모르겠습니다.  단점에서도 모든 방문객을 scan해야 한다고 말씀해주셨는데 이 부분도 더 자세한 설명을 해주실 수 있을까요? partition key를 userId로 할 때는 url을 생성하고 관리하는 User의 성능을 높일 때 사용하는걸까요? 

Ex1)User -> Message Queue -> OrderService(그림에서도 드레이크가 고개를 가로 젓고 있는데..) 이점이 별로 없어보입니다 불필요한 Network Hop이 생기는거같아요Ex2)Google Server -> Queue -> <- Results Store 이 그림에서도 검색결과를 집계하는 프로세스를 분리하여 리소스를 효율적으로 사용한다는것 외엔 오히려 응답속도를 저하시킬거같아요..

지하철에서 복습하려는데 영상으로 보려니 불편하네요 ㅠ

안녕하세요~ 섹션 2 General Service 서비스 컴포넌트의 마지막 부분에 질문이 있습니다. 이번 강의 마지막 부분에서 설명해주신 내용과 그림에는 게이트웨이가 모놀리스 서비스에만 적용이 가능하고 마이크로서비스에는 로드밸런서를 사용해야 하는 걸로 나와있는데요~보통 MSA에는 게이트웨이로 설명하고, 동일한 서비스들에 트래픽을 분산시키거나 장애 조치를 할 때 로드밸런서를 둔다고 하지 않나요?혹시나 제가 잘못 알고 있는 부분을 짚어 주셨으면 해서 질문 드립니다! 그리고 이전 강의에서 LB와 게이트웨이를 다르게 설명해주신 부분도 굳이 분리할 수도 있지만... 보통 게이트웨이에는 로드 밸런싱 기능이 포함되는 것으로 보는 것 같던데 이 부분도 궁금합니다!