PostgreSQL 주니어 시스템 설계 면접

주문 데이터는 Range 파티셔닝을 created_at(주문일시) 기준으로 월 단위로 나누는 것이 적합합니다. 이유는 주문 데이터가 시간순으로 누적되고 최근 1~3개월 데이터를 주로 조회하기 때문입니다. 각 월별 파티션을 별도 테이블로 분리하면 쿼리 성능이 향상되고, 오래된 파티션은 DROP TABLE로 빠르게 삭제하거나 별도 아카이브 스토리지로 이동할 수 있습니다. 파티션 생성은 매월 자동화 스크립트로 미리 생성하고, 인덱스도 각 파티션마다 독립적으로 관리합니다. 조회 쿼리에서 WHERE 절에 created_at 조건을 포함하면 Partition Pruning이 발생해 필요한 파티션만 스캔하므로 성능이 크게 개선됩니다. 추가로 status나 user_id 같은 자주 조회되는 컬럼에는 각 파티션별로 로컬 인덱스를 생성합니다.

애플리케이션에서 데이터베이스 커넥션을 마스터용과 복제본용으로 분리하여 관리합니다. 쓰기 작업과 강한 일관성이 필요한 읽기(방금 등록한 내 데이터 조회)는 마스터로, 통계나 목록 조회 같은 약한 일관성을 허용하는 읽기는 복제본으로 라우팅합니다. 복제본이 여러 개일 경우 애플리케이션 레벨에서 라운드로빈 또는 랜덤 방식으로 로드밸런싱하거나, PgBouncer나 HAProxy 같은 커넥션 풀러를 통해 분산합니다. 복제 지연이 중요한 경우 애플리케이션에서 pg_last_wal_replay_lsn을 확인하여 지연 시간을 체크하거나, 쓰기 후 일정 시간은 마스터에서 읽도록 세션 스티키 정책을 적용합니다. 모니터링에서는 복제 지연(replication lag)을 지속적으로 확인하고 임계치를 설정합니다.

상품 목록 API의 캐시 키는 'product:list:{category}:{sort}:{page}'처럼 조회 조건(카테고리, 정렬, 페이지)을 포함하여 설계합니다. 상품 상세 정보는 'product:detail:{product_id}' 형태로 개별 캐싱합니다. TTL은 상품 정보의 변경 빈도에 따라 5~10분 정도로 설정하되, 업데이트가 발생하면 즉시 무효화하는 하이브리드 방식을 사용합니다. 캐시 무효화 전략은 상품 정보 업데이트 시 해당 product_id의 상세 캐시를 DELETE하고, 관련된 목록 캐시는 카테고리별로 패턴 매칭(SCAN 또는 태그 기반)으로 삭제하거나 TTL에 의존합니다. Write-Through 방식으로 DB 업데이트와 동시에 캐시도 갱신하거나, Cache-Aside 패턴으로 캐시 미스 시 DB 조회 후 캐시에 저장하는 방식 중 선택합니다. 모니터링에서는 캐시 히트율과 응답 시간을 추적합니다.