깃허브 저장소를 어디에 첨부하셨나요?
미해결
프론트엔드 시스템 설계: 분산시스템으로서의 프론트엔드
깃허브 기반으로 실습예제를 진행한다면서요. 어디에 공개되어있나요?
- javascript
- react
- React-Context
- frontend
- 시스템-디자인
- react.js
173만명의 커뮤니티!! 함께 토론해봐요.
미해결
프론트엔드 시스템 설계: 분산시스템으로서의 프론트엔드
깃허브 기반으로 실습예제를 진행한다면서요. 어디에 공개되어있나요?
미해결
프론트엔드 시스템 설계: 분산시스템으로서의 프론트엔드
스타터 저장소가 있는듯 한데 누락된 것 같아요
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 Substack 1년 제공에 대해 google form 신청완료했는데 확인 부탁드려요.
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 Substack 1년 제공에 대해 google form 신청완료했는데 아직 처리가 안된건지 확인차 문의드려요
해결됨
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
헌데 아직까지는 잘모르겠어요 할인된 가격6만원주고 샀지만 아직까지는 실제 현업에서 발생하는 것들에대해서 실질적으로 도움이될만한 내용을 다루고있는것같지는 않은것같아요. 이론적인부분들만 얕게 나열해주시는데 6만원도 아직까지는 아깝다는 생각이듭니다. 그래도 이왕 들은거 끝까지듣고 판단하려고합니다.
해결됨
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
궁금해요!!
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 수업 내용중에 포함된 Slide와 설명이 맞지 않는 부분이 있는거 같아서 문의 드립니다. 영상에서는 단점으로 Vertical scaling만 가능하다고 언급하셨는데, 슬라이드에서는 수평적으로만 확장이 가능하다고 하셔서요. 제가 생각하기에도 하나의 코드 베이스에서 모든 기능이 작동해야하다 보니 Vertical scaling이 맞는거 같고 Slide내용이 잘못된거 같은데, 제가 잘못이해하고 있는것인지 확인부탁드리겠습니다. 이제 막 시작했지만 열심히 완주해보겠습니다. 감사합니다.
해결됨
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
안녕하세요 강사님 강의를 보면서 섹션3는 혹시 언제 나오고 강의구성은 어떻게되는지 궁금해서 문의드려요
해결됨
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
먼저 좋은 강의 감사합니다. Monolith와 Modular 까지는 코드나 폴더구조들이 대충 상상이 가는데 MFE 1 강의를 들었을때 필요성이나 고려사항 등등 이론적으로 이해를 했으나 강의 2에서 remote나 shell 은 설명만으로 어떤식으로 프로젝트가 세팅되는지 이해가 잘안되네요. 정말 간단하게 코드 구현하는 강의 추가해주시면 안될까요
해결됨
모르면 승진 안되는 시스템 디자인
안녕하세요, 좋은 강의 감사드립니다. 현재 해외 취업을 목표로 시스템 디자인 인터뷰를 준비 중인 수강생입니다. 낯선 문제를 만났을 때 하이레벨 디자인에서 딥다이브로 넘어가는 과정에 어려움이 있어 조언을 구하고자 합니다. 강의 시퀀스인 [요구사항 정의 -> 하이레벨 디자인 -> 딥다이브(API, 모델링 등) -> 리뷰]를 준수하며 연습하고 있으나, 익숙하지 않은 도메인에서는 하이레벨 디자인 단계에서 예외 케이스나 컴포넌트를 제대로 커버하지 못하는 경우가 많습니다. 그러다 보니 딥다이브(c)를 진행하는 도중에 설계 오류를 발견하고 다시 하이레벨(b)을 번복하게 됩니다. 처음 보는 문제에서도 하이레벨 디자인을 탄탄하게 잡고 갈 수 있는 접근법이나, 이러한 번복 플로우를 줄일 수 있는 인터뷰 팁이 있을지 여쭤보고 싶습니다.
해결됨
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
안녕하세요, 강사님. 강의 잘 보고 있습니다. Design a Toast Notification System 미션을 진행하고 있는데요, 작성한 내용을 채점하고 리뷰하기 위한 프롬프트가 있으면 좋을 것 같습니다. 강사님의 미션 평가 기준이 담긴 프롬프트로 커리큘럼을 잘 따라가고 있는지 점검하는 기회, 강사님과 수강생의 시간을 모두 아낄 수 있지 않을까 생각이 들어서 의견 남깁니다. 남은 강의도 잘 보겠습니다. 좋은 강의 제공해주셔서 감사합니다!
해결됨
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
2. UI 구현자를 넘어 Product Engineer로 가는 T-아키텍처 그리고 AI 시대의 프론트엔드 엔지니어 많은 분량은 아니지만 해당강의 자료가 .excalidraw 파일에 누락되어있습니다.
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
WhatsApp 채팅 아키텍처 설계에 대한 질문입니다. 영상에서는 참가자가 ws 서버에 메시지를 보내면 바로 Redis pub/sub으로 들어가고, 람다나 Stream을 통해 DB로 저장하는 방식을 설명하고 있습니다. 하지만 DB 저장에 앞서 채팅방 참가 여부 검증, 메시지 전송 차단/해제, 구독자만 전송 가능 등의 검증(validation)이 필요 한 경우가 있을 것 같습니다. 또한 이 경우 사용자에게 메시지 전송 실패/불가라는 즉각적인 피드백 도 제공해줘야 할 것입니다. ws 서버에서는 보통 검증 로직은 담당하지 않는 것으로 알고 있는데, 이 경우 어디에 검증 로직을 넣는 게 적당 할까요?
미해결
시스템 디자인 첫걸음: 면접에서 돋보이는 백엔드 아키텍처 설계하기
안녕하세요. 강사님 캐시전략 - Write-behind 전략을 설명해주셨는데, 인스타라이브나 유튜브라이브에서 좋아요를 한 사용자가 여러번 누를 수 있는데, 이때가 아마 Write-behind 전략을 적용할 수 있을 거 같습니다. 1. 좋아요를 레디스 캐시에 카운트 증가 2. 좋아요 누른 개수를 몇 초마다 flush로 카프카 큐에 발행 3. 카프카 consumer에서 db저장 이런 방식으로 설계가 가능할 거 같습니다. 강의에서는 Write-behind DB에 나중에 저장한다고 말씀하셨는데 그럼 이런 라이브 상황에서 DB에 좋아요를 언제 저장하는 것이 바람직할까요? 그 기준을 어떤 식으로 잡으면 좋을지도 선생님의 고견이 듣고 싶습니다. 좋은 강의 감사합니다.
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요. 강의 잘 수강하고 있습니다. SubStack 1년 무료 제공 링크를 통해 신청했는데, 신청 처리 되었는지 확인 부탁 드립니다.
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요, 강의 잘 듣고 있습니다 감사합니다! SubStack 1년 무료 제공 관련해서 https://forms.gle/diKHUhvUe61JwzXF7 링크를 통해 신청했는데, 신청 정상적으로 되었는지 확인 부탁드립니다! 감사합니다!
미해결
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 캐시 전략
안녕하세요, 선생님! 강의 들으면서 Service 및 Cache Handler 구성간 Create/Update <-> Delete 간의 Return Record 여부 차이에 대해 질문드리고자 합니다. 서비스도 그렇고, 핸들러도 그렇고, Return type이 Create/Update는 전달받은 Record를 Entity Context에 적용한 객체인데, delete의 경우 void로 운용하시는 것을 보고 어떤 차이점이 있는지 궁금하여 질문드리게 되었습니다. create, update 모두 반영 이후의 내역을 바로 반환하여 보여준다는 의미로 생각하였는데, delete를 보면 그런 것 같지는 않아서 따로 다른 의미가 있는지(실무에서 이렇게 많이 사용한다던가), 별 의미가 없는지 구체적으로 문의드리고자 합니다. 감사합니다.
해결됨
분산 데이터 모델링
안녕하세요, 선생님! 6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다. 데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지 저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지 일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다. 제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 미국 달팽이님! 강의 잘 듣고 있습니다. https://inf.run/JxEdX 에서 안내주신 구글 폼 링크로 수강 닉네임과 substack 이메일을 제출했는데, 혹시 제가 입력한 정보가 잘못됐을까요? 확인 한번 부탁드립니다.!
해결됨
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 캐시 전략
m=32MB짜리 10개와 m=512MB짜리 1개의 경우를 비교해주셨습니다. 그런데 이는 샤딩을 통해서 메모리 효율적으로 됐다기 보다는 메모리 총량이 512MB->320MB로 감소했기 때문에 오차율이 조금 증가하는 대신 메모리를 덜 쓸 수 있는 것 아닌가요? 예를 들어 320MB 짜리 1개인 경우와 32MB짜리 10개인 경우의 오차율이 똑같지 않나 하는 생각이 들어서 질문드립니다!