대규모 시스템 설계 미드레벨 기술면접
새 면접Q. 일일 1억 건의 주문을 처리하는 이커머스 플랫폼의 주문 조회 API를 설계한다고 가정합니다. 사용자는 자신의 주문 목록을 조회하고, 관리자는 모든 주문을 검색할 수 있어야 합니다. RESTful API 엔드포인트 구조와 페이지네이션 전략을 어떻게 설계하시겠습니까?
사용자와 관리자의 접근 패턴이 다르다는 점을 고려하고, 대용량 데이터 조회 시 성능과 사용자 경험을 함께 생각해보세요.
사용자용 API는 GET /users/{userId}/orders로 설계하고, 관리자용은 GET /admin/orders로 분리합니다. 페이지네이션은 Cursor 기반 방식을 채택하여 cursor 파라미터와 limit을 사용합니다. Offset 기반 페이지네이션은 대용량 데이터에서 OFFSET 값이 클수록 성능이 저하되므로 피합니다. 응답에는 next_cursor와 has_more 필드를 포함하여 클라이언트가 다음 페이지 존재 여부를 알 수 있게 합니다. 필터링은 쿼리 파라미터로 처리하되(status, date_from, date_to), 관리자 API는 복잡한 검색을 위해 POST /admin/orders/search 엔드포인트를 추가로 제공합니다. Rate limiting을 적용하여 사용자는 분당 100회, 관리자는 1000회로 차등 설정합니다.
- • 사용자와 관리자 API를 명확히 분리하여 권한과 성능 최적화를 다르게 적용
- • Cursor 기반 페이지네이션을 통해 대용량 데이터 조회 성능 확보
- • 복잡한 검색 조건은 POST 방식의 별도 엔드포인트로 처리
- • Rate limiting으로 시스템 보호 및 공정한 리소스 사용
대규모 전자상거래 플랫폼에서 수백만 건의 주문 데이터를 효율적으로 조회하고 관리하는 API를 설계할 때 필수적인 고려사항입니다.
Cursor 기반 페이지네이션에서 정렬 순서가 변경되거나 데이터가 실시간으로 추가/삭제될 때 발생할 수 있는 문제와 해결 방법은 무엇인가요?
Q. 실시간 재고 정보를 제공하는 쇼핑몰 서비스에서 상품 상세 페이지의 조회 성능을 개선하기 위해 캐싱을 도입하려고 합니다. 상품 기본 정보는 자주 변경되지 않지만, 재고 수량은 실시간으로 변동됩니다. 어떤 캐싱 전략을 사용하고, 캐시 invalidation은 어떻게 처리하시겠습니까?
데이터의 변경 빈도와 일관성 요구사항이 다른 정보들을 어떻게 분리해서 캐싱할지 고민해보세요.
상품 정보를 변경 빈도에 따라 분리하여 캐싱합니다. 상품 기본 정보(이름, 설명, 이미지)는 Redis에 TTL 1시간으로 캐싱하고, Write-Through 패턴으로 상품 정보 수정 시 즉시 캐시를 갱신합니다. 재고 수량은 별도 키로 관리하며 TTL 30초로 짧게 설정하고, 주문 발생 시 Cache-Aside 패턴으로 해당 상품의 재고 캐시만 삭제합니다. 가격 정보는 민감하므로 캐싱하되 상품 수정 이벤트 발생 시 Message Queue를 통해 캐시 무효화 이벤트를 발행하여 분산 환경의 모든 캐시를 동기화합니다. 캐시 키는 product:{id}:info와 product:{id}:stock으로 분리하여 독립적으로 관리합니다. 동시성 문제는 Redis의 WATCH 명령이나 Lua 스크립트로 원자성을 보장합니다.
- • 데이터 특성에 따라 캐시 키와 TTL을 분리하여 효율적 관리
- • Write-Through와 Cache-Aside 패턴을 데이터 유형별로 선택적 적용
- • Message Queue를 통한 분산 캐시 무효화로 일관성 유지
- • 동시성 제어를 위한 원자적 연산 보장
대규모 이커머스에서 수천만 명의 동시 접속자가 상품을 조회할 때 DB 부하를 줄이고 응답 속도를 개선하는 핵심 전략입니다.
캐시 stampede 문제가 발생할 수 있는 상황과 이를 방지하기 위한 방법은 무엇인가요?
Q. 월간 활성 사용자 1천만 명 규모의 소셜 미디어 서비스에서 팔로워들에게 실시간으로 피드를 제공하는 시스템을 설계해야 합니다. 유명인은 수백만 명의 팔로워를 가질 수 있고, 일반 사용자는 수십~수백 명의 팔로워를 가집니다. Fan-out 전략과 전체 아키텍처를 어떻게 설계하시겠습니까?
모든 사용자에게 동일한 전략을 적용하는 것이 효율적일까요? 사용자 유형에 따라 다른 접근 방식을 고려해보세요.
하이브리드 Fan-out 전략을 채택합니다. 팔로워 10만 명 이하의 일반 사용자는 Fan-out on Write 방식으로, 게시글 작성 시 Kafka를 통해 비동기로 모든 팔로워의 타임라인 캐시(Redis)에 미리 기록합니다. 팔로워 10만 명 이상의 유명인은 Fan-out on Read 방식으로, 게시글을 별도 테이블에 저장하고 사용자가 피드 조회 시 실시간으로 조합합니다. 아키텍처는 API Gateway, 게시글 작성 서비스, Fan-out 워커(Kafka Consumer), 피드 조회 서비스로 구성합니다. Fan-out 워커는 수평 확장 가능하도록 파티션 기반으로 설계하고, 타임라인 캐시는 Sorted Set으로 최근 1000개만 유지합니다. 피드 조회 시 일반 사용자 게시글은 캐시에서, 유명인 게시글은 DB에서 조회하여 병합한 후 시간순 정렬하여 반환합니다. Circuit Breaker 패턴으로 특정 서비스 장애 시에도 부분적인 피드 제공을 보장합니다.
- • 하이브리드 Fan-out 전략으로 일반 사용자와 유명인을 다르게 처리하여 효율성 극대화
- • Kafka 기반 비동기 처리로 쓰기 작업의 응답 속도 보장
- • Redis Sorted Set으로 타임라인 캐시 관리 및 메모리 효율성 확보
- • Circuit Breaker로 장애 격리 및 서비스 가용성 유지
트위터, 인스타그램 같은 대규모 소셜 미디어 플랫폼에서 수억 명의 사용자에게 실시간 피드를 제공하는 핵심 아키텍처 패턴입니다.
유명인의 팔로워가 계속 증가하여 Fan-out on Read 조회 성능도 저하된다면 어떤 추가 최적화 방안을 고려할 수 있을까요?
Q. 글로벌 서비스를 운영 중인데, 한국과 미국 사용자 모두 낮은 지연시간으로 서비스를 이용해야 합니다. 사용자 데이터는 GDPR 등 규제로 인해 지역별로 저장되어야 하고, 일부 공통 데이터(상품 카탈로그)는 전 지역에서 접근 가능해야 합니다. Multi-region 아키텍처를 어떻게 설계하시겠습니까?
데이터의 성격에 따라 저장 위치와 복제 전략을 다르게 가져가야 하며, 네트워크 지연과 법적 요구사항을 모두 고려해야 합니다.
Active-Active Multi-region 아키텍처를 구성하되 데이터를 세 가지 유형으로 분류합니다. 첫째, 사용자 개인정보는 지역별 독립 데이터베이스에 저장하고 Cross-region 복제를 하지 않습니다. 둘째, 상품 카탈로그 같은 공통 데이터는 Primary region(한국)에서 관리하고 Aurora Global Database나 Cosmos DB를 사용해 읽기 전용 복제본을 미국에 배치합니다. 셋째, 주문 같은 트랜잭션 데이터는 생성 지역에 저장하되, 메타데이터는 양방향 복제합니다. 각 지역에 독립적인 API 서버와 캐시를 배치하고, GeoDNS로 사용자를 가까운 지역으로 라우팅합니다. 지역 간 동기화가 필요한 경우 Kafka를 통한 이벤트 기반 비동기 복제를 사용하고, Saga 패턴으로 분산 트랜잭션을 처리합니다. 한 지역 장애 시 다른 지역에서 읽기 전용 모드로 서비스를 유지하며, 개인정보 접근은 차단합니다.
- • 데이터 특성에 따른 저장 및 복제 전략 차별화로 규제 준수와 성능 최적화
- • Aurora Global Database 등 관리형 서비스 활용으로 지역 간 복제 간소화
- • GeoDNS와 지역별 독립 인프라로 지연시간 최소화
- • 이벤트 기반 비동기 복제와 Saga 패턴으로 분산 트랜잭션 처리
넷플릭스, 에어비앤비 같은 글로벌 서비스에서 전 세계 사용자에게 낮은 지연시간을 제공하면서 지역별 규제를 준수하는 핵심 아키텍처입니다.
두 지역에서 동시에 같은 리소스를 수정하려고 할 때 발생하는 충돌을 어떻게 해결하시겠습니까?
Q. 대시보드에서 복잡한 통계 쿼리(최근 30일간 일별 매출, 카테고리별 판매량, 지역별 분포 등)를 실행하는데 응답시간이 10초 이상 걸립니다. 수백만 건의 주문 데이터를 실시간으로 집계해야 하는 상황입니다. 이 문제를 어떻게 해결하시겠습니까?
실시간으로 모든 데이터를 집계하는 것이 유일한 방법일까요? 데이터의 시간 특성과 정확도 요구사항을 고려해보세요.
CQRS 패턴을 적용하여 읽기와 쓰기를 분리합니다. 주문 생성 시 이벤트를 발행하고, 별도의 집계 서비스가 이를 구독하여 materialized view를 실시간으로 업데이트합니다. 일별 매출 같은 시계열 데이터는 ClickHouse나 TimescaleDB에 사전 집계하여 저장하고, 카테고리별 통계는 Redis의 HyperLogLog나 Sorted Set으로 실시간 카운팅합니다. 완전한 정확도가 필요 없는 지표는 확률적 자료구조를 사용해 메모리 효율성을 높입니다. 배치 작업으로 매시간 상세 집계 테이블을 갱신하고, 최근 1시간 데이터만 실시간 쿼리로 보완하여 하이브리드 방식으로 처리합니다. 대시보드 조회 시 사전 집계된 데이터를 Redis에서 캐싱하여 응답시간을 100ms 이하로 단축합니다. 복잡한 다차원 분석은 Elasticsearch나 Apache Druid를 활용합니다.
- • CQRS 패턴으로 읽기 최적화된 별도 데이터 저장소 구성
- • 시계열 DB와 확률적 자료구조를 활용한 효율적인 집계
- • 실시간과 배치 처리의 하이브리드 접근으로 정확도와 성능 균형
- • 다차원 분석을 위한 전용 분석 엔진 도입
대규모 이커머스나 SaaS 플랫폼에서 실시간 대시보드와 복잡한 비즈니스 리포트를 빠르게 제공하기 위해 필수적인 아키텍처 패턴입니다.
사전 집계된 데이터와 실시간 데이터 간에 불일치가 발생할 수 있는데, 이를 어떻게 모니터링하고 보정하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!