AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요, 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 간 동기화가 필요한지 궁금합니다. 감사합니다.
안녕하세요 강의 듣고 복습을 하고 있는 수강생입니다. 영화예매 시스템의 데이터베이스 설계의 관점에서 봤을때, 처음 생각나는 도메인은 영화, 예매 두개의 도메인을 고민했습니다. 하지만 영화, 예매는 N:M 관계로 판단이 됐으며, 다대다 관계를 해소하기 위하여 상영이라는 도메인이 나왔나? 라고 생각했습니다. 이 관점으로 상영이라는 도메인을 고려하였는지 궁금합니다. 그게 아니라면 상영이라는 도메인이 나올 수 있었던 과정에 대해 설명해주시면 감사드리겠습니다.
실무에서도 복수 항목에 대해서 원자성을 고려해 테이블을 분리하는지 궁금합니다. 예를 들어, 카드 정보라는 테이블이 있을 때, 혜택이라는 컬럼에는 '캐시백', '쿠폰 할인' 이런 식으로 복수의 데이터가 들어가게 되는데, 그럼 따로 카드 혜택이라는 하위 테이블을 만들어서 관리하나요? 이런 복수 항목이 늘어날 때마다 테이블을 하나씩 만들어야 하는지... 테이블 구조가 복잡해지는 느낌이 들어 질문드립니다.
역할 및 발생 시점에 따른 엔티티 분류를 설명하는 파트에서 궁금한 점이 있습니다. 지난 강의까지 주문 엔티티는 사건 발생의 결과물(즉, 주문 이력)이 기록되는 엔티티라고 이해했었는데요. "엔티티 분류1" 강의에서는 기본, 중심, 행위 엔티티 로 나눠서 생각해볼 수 있다고 했습니다. 그때 중심 엔티티 에서도 예시가 주문 으로 나와있고, 행위 엔티티 에서도 주문 이력 으로 나와 있는데, 이 두 개가 다른 경우인가요? 중심 엔티티의 주문 과 행위 엔티티의 차이 가 무엇인가요? 감사합니다.
안녕하세요. 사이드 프로젝트를 설계하다 보면 테이블의 키를 어떻게 가져갈지 고민을 많이 하게됩니다. 영한님의 말씀대로 대부분 대체키로 만들지만 숫자 대체키의 경우 1부터 순차적으로 올라가게 대부분 구조가 만들어지게 됩니다. 이게 혹여나 보안에 우려가 있을까 염려됩니다. 안전하게 UUID로 대체키를 주면 강의에서 말씀해 주신것 처럼 성능 부분에서 trade off가 있어서 이 방법도 고민됩니다. 예를 들어서 회원이라면 회원 정보를 조회하는 GET API에 회원ID(숫자 대리키, pk) 를 보내면 해당 유저 정보를 조회하게 되는데 숫자를 임의로 바꿔서 다른 유저 정보를 조회하는 이런 부분에서 혹여나 보안 관점에서 우려가 있지 않을까? 생각을 갖게 됩니다. 그러다 보니 두 가지 방안이 떠오르는데 실무에서 추천해주실 방안이 있는지 궁금합니다. 대체키(숫자)를 사용하되 애플리케이션에서 validation을 확실하게 설정 pk는 대체키(숫자, pk)를 하되 db에서 join, 외래키로만 사용하고 외부로 나갈 때는 다른 대체키(UUID, unique)로만 보내는 방식 영한님을 기다리며... 답변에 미리 감사드립니다.
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
시스템 디자인 관련 질문 서버가 PreSigned URL 을 발급하면 클라이언트가 URL 을 기반으로 Blob Storage에 다이렉트로 파일을 업로드 한 것으로 이해했습니다. 클라이언트가 업로드를 하는데 서버가 현재 청크의 진행상황을 탐지하여 Key-Value 에 업데이트 하는 메커니즘이 궁금합니다. 가령 서버가 Blob Storage 를 주기적으로 찔러 업데이트하는 과정일지 궁금합니다. 그림 상으로는 서버가 청크 진행상황을 알기위해서 추가적인 메커니즘이 있을까 생각이 들어서요.
유니크 제약조건에 대해 질문드립니다. 예를 들어 핸드폰 번호당 계정을 하나만 가질 수 있어서 핸드폰 컬럼을 유니크제약을 걸었습니다. 특정 회원이 탈퇴할 때 하드 딜리트가 아니라 소프트 딜리트를 하는 정책일 경우, 탈퇴 했던 유저가 다시 가입하게되면 어떻게 해줘야할까요.? 그럼 결국 유니크 제약을 디비에서 없애고, 애플리케이션 단에서 제어를 해야할까요?
정규화와 정규형을 생각할 때는 자연키를 사용한다는 것을 가정해야할까요? 예를 들어, 회원 테이블을 회원id (대리키), 아이디(자연키), 비밀번호, 이메일 속성으로 정의할 때, 회원id 는 아이디를 결정하고 (회원id -> 아이디), 아이디는 비밀번호, 이메일을 결정하므로 (아이디 -> 비밀번호, 아이디 -> 이메일) 이행함수 종속이 발생하는 것처럼 보입니다. 이처럼 정규화와 정규형을 생각할 때에는 대리키 개념을 배제하고, 자연키를 기준으로 생각해야할까요?
안녕하세요. 강의 잘 듣고 있습니다. Secure Access 요약부분을 듣다가 궁금한점이 생기게 되어서 질문 남깁니다. 상위 ECU에서 하위 ECU에게 SEED 값을 요청했고, 하위 ECU가 상위 ECU에게 랜덤한 SEED값을 보내준다고 하셨습니다. 그럼 SEED 값을 받은 상위 ECU는 받은 'SEED값'을 대칭키 알고리즘을 사용하여 암호화되어 전달된다라고 이해했는데 맞게 이해한걸까요? 그러면 암호화된 SEED값이 하위 ECU에게 보내지는건데, 그 과정에서 "ClientSendKey"라고 되어있는건 그 암호화된 데이터가 Key가 되어서 전달되는건가요? 아니면 암호화된 데이터 자체를 key라고 지칭하는건가요? 혼동이 되어 질문드립니다! 감사합니다.
안녕하세요 영한님. 강의를 들으면서 파편화된 정보를 정리하고 있어 너무 즐겁게 강의를 듣고 있습니다. 그런데 AI 퀴즈를 풀던 중 해당 퀴즈에서 뭔가 의아함을 느껴 질문드립니다. 물론 A를 토대로, 외래 키 컬럼에 NULL을 허용함으로써 선택적 참여를 구현할 수 있다는 것까지는 이해할 수 있겠습니다. 다만 [별도 참여 테이블 생성]이 위에 말씀 주신 member를 생성하는 것이라면 B가 더 적합한 선택지라는 생각이 듭니다. 혹시 [별도 참여 테이블 생성]이라는 선택지는 team / member 외의 테이블을 하나 더 만드는 것을 의미했던 걸까요? 비롯해서 해설에 있는 [맞을까요?]라는 질문이 적절하지 않게 느껴지는데요. 인프런으로 문의드릴까 하다가, 문제에 대한 질문을 드리는 것은 이쪽이 맞을 것 같아서 QnA로 질문드립니다!
안녕하세요. 좋은 강의 감사합니다. 사소하지만 더 나은 품질을 위해 제보 드립니다. 6-4. 캡슐화 강의 = 7분19초 SOLID 원칙 개방-폐쇄 원칙 약어 수정 필요 LSP > OCP 개방-폐쇄 원칙의 약어가 이전 설명의 리스코프 치환 원칙의 약어로 잘 못 표기된것으로 보입니다. 항상 좋은 강의 감사합니다.
6-4 캡슐화에서 서브타입이 슈퍼타입을 대체할 수 있는 것이 SOLID 원칙 중 리스코프 치환원칙이라고 하셨는데 제가 알고있는 리스코프 치환원칙은 서브타입은 슈퍼타입을 대체 할 수 있어야 하고 슈퍼타입에서의 행위를 서브타입에서도 동일한 결과값이 예상될 수 있어야한다로 알고있습니다! e.g) Collection의 add 메소드는 어떤 서브타입이여도 "추가"한다는 행위가 되어야한다 "서브타입이 슈퍼타입을 대체할 수 있다" 도 리스코프치환원칙의 특징이 맞지만 해당 원칙이 전하려는 주된 내용은 행위의 같은 예상 결과값으로 보여서요! 어떻게 생각하시는 지 궁금합니다!
A, B, C 이렇게 세 개의 테이블이 있는데요, A → B, B → C, C → A 이렇게 서로 참조하고 있는 구조입니다. 문제는 이렇게 되어 있으니까, 예를 들어 B를 지우려면 A가 걸리고, A를 지우려면 또 C가 걸리고, C를 지우려면 다시 A가 걸려서 결국 서로 물려서 삭제가 안 되는 상황이 생깁니다. 예를 들면 A = 학생(Student) → 어떤 수업(B) 에 참여하고, B = 수업(Class) → 그 수업은 교사(C) 가 담당하며, C = 교사(Teacher) → 교사는 자신이 가르치는 학생(A) 들의 리스트를 참조(관리용). 이 예시는 정확한 상황은 아니고 제가 생각해서 만들어낸 예시입니다 조금 안맞을수 있는데 만약에 이런 경우에 보통 어떻게 처리해야하나요?
어떻게 보면 이 수업과는 조금은 먼 이야기일수도 있는데 실제 프로젝트에서 JPA를 다루다보니 엔티티 선언시에 시간 타입 정의를 어떻게 처리해야 할지가 항상 고민이 되더라구요. 현재 프로젝트에서는 Entity 정의시에는 Instant를 사용을 하는데, 혹시 추천하시는 방법이 있을까요??
