MySQL 미드레벨 시스템 설계 면접

주문 총액을 주문 테이블에 중복 저장하는 것이 실무에서 일반적으로 선호됩니다. 매번 계산하는 방식은 데이터 일관성은 보장하지만 조회 시마다 JOIN과 집계 연산이 필요해 성능이 저하되고, 주문 내역 조회가 빈번한 전자상거래 특성상 부적합합니다. 중복 저장 방식은 조회 성능이 우수하고 주문 확정 시점의 가격을 정확히 보존할 수 있으며, 트랜잭션 내에서 총액 계산 후 저장하고 애플리케이션 레벨에서 검증 로직을 추가하면 일관성도 충분히 보장할 수 있습니다. 또한 환불, 부분 취소 등 복잡한 비즈니스 로직 처리 시 히스토리 추적이 용이합니다.

Pull 방식은 게시 시 부하가 없고 저장 공간이 효율적이지만 조회 시 다중 JOIN과 정렬이 필요해 응답 속도가 느립니다. Push 방식은 조회 성능이 우수하지만 팔로워가 많은 인플루언서 게시 시 대량의 쓰기 작업이 발생하고 저장 공간이 증가합니다. 하이브리드 방식에서는 팔로워 수를 기준으로 일반 사용자는 Push 방식을, 팔로워 1만 명 이상 인플루언서는 Pull 방식을 적용합니다. 테이블 설계 시 user_feed 테이블(user_id, post_id, created_at)에 (user_id, created_at) 복합 인덱스를 생성하고, 인플루언서 게시물은 캐시(Redis)에 저장 후 조회 시 병합하는 방식으로 구현합니다.

Cache-Aside는 애플리케이션이 캐시 미스 시 DB 조회 후 캐시에 저장하는 방식으로 구현이 간단하지만 업데이트 시 캐시 무효화 타이밍 이슈가 있습니다. Write-Through는 DB 쓰기와 동시에 캐시를 업데이트해 일관성이 높지만 쓰기 지연이 발생합니다. Write-Behind는 캐시에 먼저 쓰고 비동기로 DB에 반영해 성능은 우수하나 장애 시 데이터 손실 위험이 있습니다. 재고 관리는 정합성이 매우 중요하므로 Write-Through 패턴이 적합하며, 재고 차감 시 DB 트랜잭션 내에서 UPDATE 후 캐시를 즉시 갱신하고, 추가로 분산 락을 활용해 동시성 제어를 강화해야 합니다.

Offset 방식은 LIMIT offset, count 형태로 구현되며 페이지 번호 기반 탐색이 가능하지만, offset이 커질수록 MySQL이 건너뛸 행을 모두 스캔해야 해 성능이 저하되고 데이터 변경 시 중복/누락이 발생할 수 있습니다. Cursor 방식은 WHERE id > last_id ORDER BY id LIMIT count 형태로 마지막 조회 지점을 기준으로 다음 데이터를 가져오며, 인덱스를 효율적으로 활용해 일정한 성능을 보장하고 실시간 데이터 변경에도 안정적입니다. SNS 타임라인은 최신순 조회가 주요 패턴이고 데이터가 실시간으로 변경되므로 Cursor 방식이 적합하며, created_at과 id를 조합한 복합 커서로 정확한 페이지네이션을 구현할 수 있습니다.

DB 분리 방식은 완벽한 격리와 테넌트별 최적화가 가능하지만 관리 복잡도와 비용이 높아 소수의 대규모 테넌트에 적합합니다. 스키마 분리는 적절한 격리와 성능을 제공하지만 수백 개 이상의 스키마 관리가 어렵고 마이그레이션이 복잡합니다. 테이블 내 컬럼 구분(tenant_id)은 관리가 단순하고 비용 효율적이지만 쿼리마다 tenant_id 조건 필수이며 인덱스 설계가 중요합니다. 1000개 이상 테넌트의 B2B SaaS에서는 기본적으로 테이블 내 컬럼 구분 방식을 사용하되, 모든 테이블의 첫 번째 인덱스 컬럼에 tenant_id를 포함하고, 데이터 크기가 큰 상위 5% 테넌트는 별도 DB로 분리하는 하이브리드 전략이 적합합니다.