Substack 1년 제공

프로모션 중복 제공 또는 악의적인 이용을 예방하기 위해 수강생 이름등이 확인되지 않을 시 제공되지 않고 있습니다.다시 한번 요청 부탁드립니다.https://forms.gle/diKHUhvUe61JwzXF7감사합니다.

Substack 1년 제공

안녕하세요. 김성재님,요청해주신 부분을 확인해보았습니다.현재 새로 요청된 사항에서 확인되고 있는수강생 닉네임은 다음과 같습니다. sj9***k*m4*** 이와 같이 인프런 수강 이름이 확인되었으나, 해당 수강생이 없어 누락처리 되어있는 상태입니다. 감사합니다.

특별 학습 자료 프로모션 1년 멤버십 무료 제공 문의드립니다

안녕하세요. 환경님 수강 감사드립니다.캘리포니아 서부에 있다보니 조금 응답 지연이 있습니다.Substack 1년 무료 제공 완료되었습니다. 이메일을 확인해주세요!감사합니다.

특별 학습 자료 프로모션 1년 멤버십 제공 관련 문의 드립니다.

안녕하세요. 현재 제출해주신 정보를 확인하였으나 substack 계정 무료 구독 상태인 해당 이메일 사용자분은 확인 되지 않고 있습니다https://open.substack.com/pub/1234373801해당 계정을 무료 구독 먼저 해주시는 것을 부탁드립니다

simcached를 검색을 했을때 해당 자료가 나오지 않는데 혹시 MemcachedGPU 라고 불리는 기술을 말씀하시는건가요?

안녕하세요. BBB AAA 님,감사합니다. 좋은 질문 해주셨습니다. “Sim cached”라는 표현은 주로 시스템 디자인 인터뷰나 아키텍처 토론에서 나오는 슬랭/약어 입니다.제가 인도계, 미국 빅테크 구글, 메타, OpenAI, 어도비 등의 엔지니어 분들과 직접 토론하며, 배웠었는데 그러다보니, 저도 모르게 슬랭/약어를 사용하게 되었습니다.실제 Memcached, Redis, ElastiCache 같은 분산 캐시(distributed cache)를 쓰지 않고 → 그냥 한 서버(한 프로세스) 안에서 HashMap, dict, LRU Cache 등으로 흉내 내서 구현한 캐시를 의미합니다. 감사합니다. 좋은 하루 되세요!

유튜브 예제에서 흐름 관련 질문있습니다

안녕하세요. 고병찬님. 질문을 늦게 해결하게 되어 매우 죄송한 말씀 드리며, 다음 부터는 늦는 일이 없도록 하겠습니다. 양해를 구하며 답을 작성합니다. 좋은 질문 감사드립니다. 영상 스트리밍 요청은 일반적으로 API Gateway를 거치지 않고, CNAME으로 매핑된 CDN Edge로 바로 전달됩니다. API Gateway는 메타데이터 조회, 권한 검증, 추천 API와 같은 제어 요청만 처리하고, 실제 대용량 비디오 데이터는 성능과 확장성을 위해 CDN이 직접 서빙합니다.따라서,스트리밍 서비스에서는 메타데이터 요청과 실제 비디오 데이터 요청이 분리되어 처리됩니다.메타데이터나 권한 확인 같은 제어 요청은 API Gateway를 통해 처리되고,실제 대용량 비디오 스트림(적응형 스트리밍 매니페스트 및 조각)은 CDN으로 직접 서빙됩니다.CDN 도메인은 CNAME으로 매핑되어 있어 클라이언트가 직접 요청하며,cache hit 시 edge에서 바로 응답되고 miss 시에는 origin blob storage에서 읽어옵니다.경우에 따라 권한 체크나 signed URL 발급이 필요하면 API Gateway를 통해 토큰/URL을 받은 뒤,클라이언트가 해당 URL로 CDN에 직접 스트리밍 요청을 보내는 방식으로 처리합니다. 감사합니다. 다시 한 번 늦어서 죄송하다는 말씀 드립니다.좋은 하루 되세요!

Spotify 서비스 설계에서 transcoder service에 대해 문의 드립니다.

안녕하세요. 바쁜 일 때문에 늦어진 질문이 있는지 파악하지 못했습니다. 죄송한 말씀 드립니다. 네 이해하신 게 맞습니다. Transcoder는 업로드된 원본 음악 파일을 여러 비트레이트 및 스트리밍 포맷으로 변환한 뒤, 그 결과 파일을 object storage에 저장하는 역할입니다. 특별히 다른 의미라기보다는, 스트리밍 최적화를 위한 인코딩/변환 서비스로 보시면 됩니다. 그부분은 구두로 설명하거나 생략을 해도 무방하다고 고려되었으나, 추후에 다시 업데이트가 필요한 부분인 것 같습니다.감사합니다.

[위치 이름 기반으로 호텔을 조회하는 메서드] 코드 질문 드립니다.

안녕하세요 :) 질문 정말 좋습니다.1) Hotel ↔ Location 서로 참조 관계에 대해결론부터 말씀드리면 둘 다 가능하지만, 실무에서는 보통 “단방향”을 더 많이 선택합니다.Location이 “호텔을 위해 만들어진 종속 모델”이라면말씀하신 것처럼 Location → Hotel 단방향도 논리적으로 말이 됩니다.다만 Booking 같은 도메인에서는 Location이 특정 Hotel만을 위해 존재한다기보다는“주소/도시/지역” 같은 공통 개념(값 객체/별도 엔티티) 로 보는 경우가 많아서,보통은 Hotel이 locationId(또는 Location)를 참조하는 단방향이 더 흔합니다.강의에서 양쪽 참조처럼 보이게 둔 건, 관계를 직관적으로 보여주기 위한 교육용 표현이었고,실무에서는 한쪽만 참조 + 조회는 별도 계층에서 처리하는 쪽이 유지보수성이 좋습니다.2) 위치 기반 호텔 조회 메서드는 어디에 있어야 하나?이 부분도 아주 좋은 질문이에요.findHotelsByLocationName() 같은 기능은Location “자기 자신”의 행위라기보다는 데이터 조회(Query) 성격이 강합니다.그래서 OOD 관점에서는 보통Location 엔티티 안에 넣기보다는HotelRepository / SearchService / AvailabilityService 같은 조회 전용 계층에 두는 게 더 자연스럽습니다.이유는 간단합니다.조회 로직에는 보통 인덱스/DB 조인/캐시/검색엔진 같은 인프라 최적화가 붙고,그걸 Location 엔티티에 넣으면 오히려 엔티티가 “도메인 모델”이 아니라 “DB 접근 객체”처럼 변해버리는 문제가 생깁니다.즉,Location: 값/정보 모델로 단순하게 유지조회: Service/Repository에서 처리이 구조가 가장 깔끔하다고 할 수 있습니다.3) bruteforce 탐색은 의도된 baseline 예시입니다네, 질문하신 것처럼 강의의 전체 탐색 로직은 일단 동작하는 baseline(개념 검증용) 입니다.좋은 피드백이에요. Object Oriented Design 설계 강의 이기 때문에 이 강의 단계에서는코어 로직에 대한 최적화는 포함되지 않았습니다. 현재 오픈소스 강의 개선작업중이기 때문에이 작업이 완료되면 OOD 강의 또한 주신 피드백을 반영해서 업데이트 될 예정입니다.피드백 감사합니다.4) 최적화 방향최적화 방법들은 다음 시스템 디자인 강의 섹션에서 배우실 수 있습니다.질문 주신 “조인/인덱싱/2-step 조회”가 실무에서 가장 흔한 방식입니다.대표적인 최적화는 아래처럼 단계적으로 갑니다.가장 정석: DB 인덱스 + 조인Location(name) 인덱스Hotel(location_id) 인덱스WHERE location.name = ? 로 조인해서 바로 조회2-step 조회locationName -> locationIdlocationId -> hotels 조회High Availability - 캐시/역인덱스Redis에 locationName -> hotelIds 저장상세는 hotelId로 조회검색 요구가 커지면 Search 분리자동완성/오타/동의어/필터까지 붙으면OpenSearch/Elasticsearch로 분리하는 게 일반적입니다.질문 감사합니다. 다른 질문 있으시면 언제든지 남겨주세요!좋은 하루 되세요!

특별 학습 자료 프로모션 1년 멤버십 무료 제공 지원 확인 방법

https://forms.gle/diKHUhvUe61JwzXF7이 구글 폼을 통해 수강 닉네임과 substack 계정 이름 또는 이메일을 입력해주시면 구매자 검토후유료 멤버십을 1년간 무료로 제공해드립니다 감사합니다

14강. 영화 DVD 대여 시스템 데이터베이스 스키마 설계에서 Inventory 테이블 질문있습니다.

안녕하세요. 3831568님,쉽지 않은 생각과 사고로 질문해주신 부분 대단하신 것 같습니다.너무 좋은 질문 해주셔서 감사합니다.제가 방금 캐나다 벤쿠버에서 오는 바람에 늦게 답을 하게 되었습니다.먼저 분리하는 게 좋다고만 말씀드린 부분 설명부족에 대해 동의하면서 개선할 부분으로메모를 해두겠습니다. 피드백 감사합니다.질문해주신 부분에 대해 의견을 드려보자면, Inventory 테이블로 분리하는 것입니다. DVD 가 한 타이틀의 재고가 10만건이든, 10건이든, Items 테이블은 그 타이틀 하나당 딱 한 행입니다.재고가 초당 수백번 차감되거나 복구된다면 그 한 행에 WRITE lock 이 계속 걸리고 동시에 관리자가이 영화 설명 좀 수정하기를 원한다면, 그 행을 기다려야 합니다. 그래서 정적 메타데이터 테이블 Movies, Books, Games 등과 같이 구성되고 Inventory 테이블을 movie_id (FK)store_id / location_id (옵션)status (‘available’, ‘rented’, ‘lost’ 등)available_copies (또는 개별 copy를 한 행씩 관리)이렇게 하면재고 차감 → Inventory 행만 UPDATE (핫스팟은 여전히 있지만 메타데이터 행은 안 건드림)관리자가 영화 설명 수정 → Movies 행만 UPDATE (재고 트래픽과 완전 분리)따라서, 분리하는 것을 권장드립니다.두번째는유형별 재고 관리 정책인데 초기에는 모든 아이템이 그냥 수량만 있다면 OK 될 수 있습니다.예를 들어, Inventory { item_id, available_count } 이렇게 구성되는 것입니다.하지만 나중에 요구사항이 생기게 되면 확장이 필요합니다.유형별로 요구사항은 아래와 같을 것 입니다.DVD/블루레이 → 만료일 없음식품 → 유통기한 필요콘서트 티켓 → 좌석 번호, 구역 필요전자책 → 만료일 + 동시 대여 수 제한 필요NFT 렌탈 → 소유권 이전 로직 필요다양한 제한과 확장이 필요할 것입니다.그래서 아래와 같이 1번 초기부터 3번으로 점점 업그레이드 하는 것을 권장드릴 수 있을 것 같습니다.JSONB / JSON 컬럼으로 유연 속성 보관 (PostgreSQL, DynamoDB 등) – 초중반에 제일 많이 씀수직 분할 (Vertical Partitioning)공통: InventoryCommonDVD용: InventoryDVD (expires_at 등)Food용: InventoryFood (expiry_date, batch_no) → JOIN은 귀찮지만 타입 안정성 최고수평 분할 + Polymorphic Association (제가 제일 추천하는 최종 진화형) Inventory { id, item_id, item_type, available_count, reserved_count, … }별도 확장 테이블들 → item_type이 ‘dvd’면 InventoryDVD 테이블 조인 → item_type이 ‘ticket’면 InventoryTicket 테이블 조인 (Uber는 결제 수단, Netflix는 콘텐츠별 권한 이렇게 사용될 수 있습니다.)초기엔 JSONB로 한 다음, 특정 아이템 유형이 너무 복잡해지면 그때 3번으로 분리합니다.그리고 말씀하신 트래픽이 정말 많아지면 available_count 차감은 결국 Redis / DynamoDB 같은 분산 카운터로 옮기고, DB는 이벤트 소싱이나 사가 패턴으로 최종 일관성만 맞춥니다. (넷플릭스 DVD 재고, 아마존 재고 모두 이렇게 구성될 수 있습니다.)감사합니다.좋은 하루 되세요!