시스템 설계

질문 일 요청 수로 QPS를 어떻게 구하나요?

답변 포인트 일 요청 수를 86,400으로 나누면 평균 QPS가 됩니다. 최대 QPS는 실제 패턴이나 명시한 peak factor를 적용해야 합니다.

질문 네트워크 분할 상황에서 강한 일관성과 모든 요청에 대한 응답 가능성을 동시에 보장할 수 없다면 무엇을 선택하나요?

답변 포인트 성공한 쓰기의 유실을 허용하지 않는 원본 경로는 quorum을 얻지 못하면 쓰기를 거부하고 일관성을 우선합니다. 허용 시간 안의 stale 데이터로도 가치가 있는 조회 경로는 캐시나 지역 복제본으로 응답 가능성을 높일 수 있으며 경로별 정책을 분리합니다.

질문 최대 트래픽이 예상보다 10배 커졌을 때 무엇부터 확인하나요?

답변 포인트 CPU만 늘리기보다 지연 분포, DB 연결·IO, 캐시 적중률, 큐 lag와 hot key를 확인해 실제 포화 자원을 찾습니다. Stateless API는 수평 확장하기 쉽지만 원본 DB 병목은 쿼리·인덱스 개선과 읽기 분리 이후에 파티셔닝을 검토합니다.

질문 설계 때 사용한 규모 추정이 맞는지 운영에서 어떻게 검증하나요?

답변 포인트 요청 유형별 QPS, payload 크기, 읽기·쓰기 비율, 성장률과 peak factor를 계측하고 예상치와 정기적으로 비교합니다. 차이가 용량 계획과 SLO에 미치는 영향을 갱신하며 근거 없는 여유 용량을 무한히 추가하지 않습니다.

질문 같은 긴 URL에는 항상 같은 키를 반환해야 하나요?

답변 포인트 필수는 아닙니다. 사용자·권한·만료·캠페인마다 별도 링크가 필요할 수 있어 중복 제거 정책을 요구사항으로 결정합니다.

질문 유명 링크 하나에 트래픽이 집중되면 어떻게 하나요?

답변 포인트 CDN·엣지 캐시와 애플리케이션 캐시를 사용하고 통계 이벤트는 비동기로 분산 처리합니다.

질문 생성 직후 단축 URL이 일부 서버에서 404가 되면 어떻게 진단하고 막나요?

답변 포인트 읽기 복제본 lag와 negative cache를 먼저 확인합니다. 생성 commit과 함께 캐시를 채우거나 최근 키는 primary로 fallback하고, 존재하지 않음의 negative TTL은 짧게 둬 복제 지연이 장기 404로 고착되지 않게 합니다.

질문 리다이렉트에서 301, 302와 307을 어떻게 선택하나요?

답변 포인트 301은 영구 이동으로 클라이언트·중간 캐시가 강하게 저장할 수 있어 불변 링크에 적합합니다. 302는 일반적인 임시 리다이렉트, 307은 원래 HTTP method와 body 보존이 필요할 때 사용하며 목적지 변경·차단·통계 통제 가능성과 캐시 효율을 비교합니다.

질문 팔로워가 수천만 명인 사용자가 글을 쓰면 어떻게 하나요?

답변 포인트 모든 팔로워에게 즉시 복제하지 않고 유명 계정 게시물을 읽을 때 병합하거나 단계적으로 배포합니다.

질문 삭제된 게시물이 피드 캐시에 남으면 어떻게 하나요?

답변 포인트 원본 tombstone과 즉시 반영되는 권한 deny cache를 읽기 경로에서 검사해 노출부터 차단합니다. 삭제 이벤트로 타임라인과 캐시를 비동기 정리하되 이 정리가 끝날 때까지 접근 제어를 미루지 않습니다.

질문 Fan-out worker가 일부 팔로워만 처리한 뒤 죽으면 어떻게 복구하나요?

답변 포인트 게시물·팔로워 구간별 checkpoint를 저장하고 같은 작업을 재실행합니다. FeedItem에 post ID와 follower ID 유일 키를 두면 재시도가 중복 항목을 만들지 않으며 lag를 기준으로 누락 구간을 재수집할 수 있습니다.

질문 페이지를 넘기는 동안 새 게시물이 추가돼도 중복과 누락을 어떻게 줄이나요?

답변 포인트 offset 대신 마지막 항목의 정렬 시각과 고유 post ID를 묶은 cursor를 사용하고 그보다 이전인 항목만 조회합니다. 완전한 snapshot이 필요하지 않다면 새 게시물은 새로고침 때 위쪽에 표시합니다.

질문 여러 서버를 거쳐도 메시지 순서를 어떻게 지키나요?

답변 포인트 같은 대화방을 같은 파티션에 라우팅하고 서버가 부여한 sequence로 정렬합니다. 전역 순서는 보통 필요하지 않습니다.

질문 온라인 상태는 강한 일관성이 필요한가요?

답변 포인트 대부분 heartbeat와 TTL 기반의 근사 상태로 충분하며 연결 종료 감지가 늦을 수 있음을 허용합니다.

질문 서버는 메시지를 저장했지만 송신 ACK가 유실되면 어떻게 하나요?

답변 포인트 클라이언트가 같은 clientMessageId로 재전송하고 서버는 송신자 범위의 유일 키로 기존 message ID와 sequence를 반환합니다. 새 ID로 다시 저장하면 상대 화면에 중복이 생깁니다.

질문 매우 활발한 대형 그룹 하나가 단일 파티션을 포화시키면 순서를 유지하면서 어떻게 확장하나요?

답변 포인트 대화방 sequence 부여는 한 논리적 순서 영역으로 유지하고 저장 이후 fan-out을 수신자 구간별로 병렬화합니다. 처리 한계를 넘으면 대형 방 전용 파티션·서비스로 격리하되 임의 shard별 sequence로 방 전체 순서를 깨지 않습니다.

질문 같은 알림의 중복 발송을 어떻게 막나요?

답변 포인트 요청 ID와 채널별 발송 키로 내부 중복을 막고, 제공자가 멱등 키를 지원하면 같은 키를 전달합니다. 지원하지 않으면 조회 API, delivery receipt와 주기적인 대조 작업으로 불명확한 발송 결과를 확인합니다.

질문 대형 이벤트로 알림이 폭증하면 어떻게 하나요?

답변 포인트 우선순위 큐, 채널별 rate limit, 예약·배치 처리와 backpressure로 긴급 알림을 보호합니다.

질문 알림이 큐에 들어간 뒤 사용자가 수신을 거부하면 어떻게 하나요?

답변 포인트 오래된 preference snapshot만 메시지에 고정하지 않고 실제 외부 발송 직전에 최신 수신 설정을 다시 확인합니다. 법적·필수 트랜잭션 알림은 일반 마케팅 수신 거부와 별도 정책으로 분류합니다.

질문 Template 오류를 고친 뒤 DLQ를 재처리하면 어떤 버전을 사용하나요?

답변 포인트 감사와 동일한 결과 재현이 필요하면 요청에 고정된 template version을 사용합니다. 잘못된 template 자체가 실패 원인이면 승인된 새 version으로 명시적으로 migration한 재처리 작업을 만들고 무심코 현재 최신본을 적용하지 않습니다.

질문 업로드가 중간에 끊기면 어떻게 복구하나요?

답변 포인트 upload ID와 완료된 part를 저장하고 누락된 part만 다시 보내며 오래된 미완료 업로드는 수명 주기로 제거합니다.

질문 악성 파일이 즉시 배포되지 않게 하려면 어떻게 하나요?

답변 포인트 검사 전에는 격리 상태로 저장하고 검사 완료 이벤트 이후에만 공개 다운로드를 활성화합니다.

질문 Presigned URL로 선언한 크기보다 큰 파일이나 다른 content type을 올리는 것을 어떻게 막나요?

답변 포인트 발급 전에 사용자 quota를 확인하고 서명 조건에 object key, 만료, part와 허용 크기·content type을 제한합니다. 완료 API에서도 실제 객체 크기와 checksum을 다시 검증하고 조건이 다르면 확정하지 않습니다.

질문 권한을 회수했는데 이미 발급된 다운로드 URL과 CDN 캐시가 남아 있으면 어떻게 하나요?

답변 포인트 서명 URL을 짧게 만료시키고 민감 파일은 매 요청 권한 검사가 가능한 CDN signed cookie·edge authorization을 사용합니다. 긴 캐시가 필요하면 object version을 폐기 목록에 올리고 purge하되 전파 지연을 보안 정책에 포함합니다.

질문 새로운 인기 검색어를 얼마나 빨리 반영하나요?

답변 포인트 스트리밍 집계로 최근 delta를 만들고 안정된 결과는 배치 인덱스에 병합해 정확성과 비용을 조절합니다.

질문 오타까지 지원하려면 어떻게 하나요?

답변 포인트 편집 거리, n-gram 같은 후보 생성 방식을 사용하되 지연과 후보 폭증을 제한합니다.

질문 Trie와 prefix별 Top-K Key-Value 인덱스는 어떤 조건에서 선택하나요?

답변 포인트 Trie는 임의 prefix와 동적 탐색에 유리하지만 큰 문자 집합과 1억 후보를 메모리에 유지하는 비용이 큽니다. 요청 prefix가 반복되고 Top-K가 작다면 사전 계산한 KV 인덱스가 지연과 분산 배포에 유리하지만 갱신과 저장 중복 비용이 늘어납니다.

질문 한두 글자 prefix가 hot key가 되면 어떻게 처리하나요?

답변 포인트 값이 작고 자주 바뀌지 않으므로 여러 읽기 노드와 프로세스 로컬 캐시에 복제합니다. 단순히 prefix를 hash shard로 더 쪼개면 한 요청이 모든 shard를 병합해야 하므로 hot prefix 전용 복제와 갱신 version 관리가 더 적합할 수 있습니다.

질문 서버별 로컬 카운터만 사용하면 어떤 문제가 있나요?

답변 포인트 서버 수에 비례해 제한을 초과하고 재배치 때 상태가 사라지므로 중앙 카운터나 quota 분배가 필요합니다.

질문 특정 고객 카운터가 hot key가 되면 어떻게 하나요?

답변 포인트 정확한 전역 한도의 원자적 갱신은 병목이 될 수 있습니다. 로컬 quota 임대나 계층형 limiter로 분산하되 허용할 일시 초과량을 명시하고, 하위 키 분산은 정확도와 집계 비용의 trade-off를 함께 설명합니다.

질문 서버 시계가 뒤로 이동하거나 리전별 시간이 다르면 token refill은 어떻게 하나요?

답변 포인트 Token refill은 상태 저장소 기준 시각으로 원자 계산하고 큰 시간 도약도 capacity로 clamp합니다. Lease는 발급·수신 ACK 뒤 duration을 로컬 monotonic deadline으로 바꾸고 안전 여유만큼 일찍 중단하며, allocator는 최대 시계 오차와 전파 지연까지 지난 뒤에만 quota를 재발급합니다. 이 상한을 보장할 수 없으면 겹치는 재발급을 하지 않습니다.

질문 중앙 상태 저장소가 장애 나면 모든 API를 같은 방식으로 처리하나요?

답변 포인트 아닙니다. 결제·쓰기처럼 남용 비용이 큰 경로는 fail-closed하고, 공개 조회는 짧은 시간 보수적 로컬 한도로 fail-open할 수 있습니다. 정책별 지속 시간과 복구 후 quota 재동기화 방법을 미리 정합니다.

질문 DB 갱신과 캐시 삭제 중 무엇을 먼저 하나요?

답변 포인트 DB commit 후 삭제가 기본이지만, 이전 값을 읽던 요청이 삭제 뒤 stale 값을 다시 채울 수 있습니다. 값과 별도로 단조 증가하는 version tombstone을 남겨 낮은 source version의 cache fill을 CAS로 거부하거나, current-version pointer와 versioned value를 분리해야 합니다. Outbox는 무효화를 재전달하지만 비교할 fence 자체를 대신하지는 않습니다.

질문 모든 데이터에 긴 TTL을 적용하면 안 되나요?

답변 포인트 적중률은 높아져도 오래된 값과 무효화 부담이 커지므로 변경 빈도와 stale 허용 시간을 기준으로 정합니다.

질문 인기 상품의 TTL이 만료될 때 DB 요청이 동시에 폭증하면 어떻게 하나요?

답변 포인트 TTL jitter로 만료 시점을 분산하고 같은 키의 miss를 single-flight로 합칩니다. 허용된 stale 값을 먼저 반환하며 한 worker만 갱신하는 stale-while-revalidate도 사용할 수 있습니다.

질문 캐시 클러스터 전체가 장애 나면 DB fallback만 하면 되나요?

답변 포인트 전체 30만 QPS를 DB로 보내면 연쇄 장애가 날 수 있습니다. 요청 우선순위와 admission control로 원본 용량만큼만 통과시키고 circuit breaker와 점진적 cache warm-up으로 복구합니다. 로컬 stale-if-error도 필드별 한도 안에서만 사용하므로 가격·재고는 2초를 넘겨 반환하지 않고, 설명만 5분 한도까지 허용합니다.

질문 DB 저장 후 이벤트 발행 전에 서버가 죽으면 어떻게 하나요?

답변 포인트 같은 DB 트랜잭션에 outbox를 저장하고 별도 relay가 큐로 전달하는 Transactional Outbox를 사용할 수 있습니다.

질문 계속 실패하는 메시지가 파티션을 막으면 어떻게 하나요?

답변 포인트 순서 완화가 가능하면 제한된 재시도 후 DLQ로 격리합니다. 같은 키의 엄격한 순서가 필요하면 해당 키나 파티션을 중지·격리하고, 원인을 수정한 뒤 원래 순서로 재처리합니다.

질문 소비자가 DB commit 후 offset ACK 전에 죽으면 어떻게 되나요?

답변 포인트 이벤트가 다시 전달됩니다. Event ID를 업무 변경과 같은 트랜잭션의 inbox에 기록하면 로컬 DB 변경은 중복되지 않지만, 트랜잭션 밖의 외부 API 호출까지 보호하지는 못합니다. 외부 효과는 effect outbox, 제공자에게 전달하는 안정된 idempotency key와 결과 조회·대사로 별도 보호해야 하며 제공자가 이를 지원하지 않으면 정확히 한 번 실행을 보장할 수 없습니다.

질문 7일 전 이벤트를 재생할 때 새 소비자 코드와 스키마가 달라졌다면 어떻게 하나요?

답변 포인트 Envelope의 schema version으로 호환 decoder를 선택하고 additive 변경을 우선합니다. Replay 전용 consumer와 출력 namespace를 사용해 검증한 뒤 전환하며 알림·결제 같은 side effect는 replay mode에서 억제하거나 멱등 키로 차단합니다.

질문 결제사 호출은 성공했지만 응답이 시간 초과되면 어떻게 하나요?

답변 포인트 같은 idempotency key로 상태를 조회하고 주문을 Pending에 둔 뒤 webhook과 정산으로 확정합니다.

질문 재고 예약 후 결제가 실패하면 어떻게 하나요?

답변 포인트 예약 만료와 보상 이벤트로 재고를 해제하며 해제 작업도 중복 실행에 안전해야 합니다.

질문 같은 idempotency key로 금액이 다른 요청이 오면 어떻게 하나요?

답변 포인트 키와 최초 payload hash를 함께 저장하고 payload가 다르면 기존 주문을 반환하지 않고 충돌 오류로 거부합니다. 키는 고객·업무 범위와 만료 정책을 가져야 다른 사용자의 요청과 충돌하지 않습니다.

질문 결제 성공 webhook 뒤에 더 오래된 실패 webhook이 도착하면 어떻게 하나요?

답변 포인트 제공자 event ID와 payment attempt version을 저장하고 상태 머신에서 허용된 전이만 조건부 적용합니다. 이미 확정된 성공을 오래된 실패가 되돌리지 못하게 하고 서로 모순된 상태는 정산 대상으로 보냅니다.

질문 같은 작업을 여러 scheduler가 동시에 발견하면 어떻게 하나요?

답변 포인트 조건부 갱신, row claim과 lease로 한 scheduler가 enqueue 권한을 얻고 작업 ID로 중복을 제어합니다. Fencing token은 보호 자원에서 오래된 소유자의 쓰기를 거부하는 장치입니다.

질문 서버 시간이 서로 다르면 어떻게 하나요?

답변 포인트 시간원을 동기화하고 DB 시간 같은 기준을 사용하며 허용 오차와 misfire 정책을 둡니다.

질문 Worker가 작업을 완료했지만 ACK 전에 죽으면 어떻게 하나요?

답변 포인트 Visibility timeout 후 같은 run이 다시 전달될 수 있습니다. Handler가 run ID 또는 업무 idempotency key로 결과를 기록하고 이미 완료된 run이면 side effect를 반복하지 않아야 합니다.

질문 DST 전환 때 존재하지 않거나 두 번 나타나는 지역 시각의 cron은 어떻게 처리하나요?

답변 포인트 Job의 IANA time zone과 정책 version을 저장하고 건너뛴 시각은 skip 또는 다음 유효 시각 실행, 중복 시각은 한 번 또는 두 번 실행 중 명시된 정책을 따릅니다. 계산 결과와 실행한 local time·UTC를 이력에 남깁니다.

질문 Gateway가 단일 장애점이 되지 않나요?

답변 포인트 여러 stateless 인스턴스를 장애 영역에 분산하고 고가용성 로드밸런서로 앞단을 구성합니다.

질문 registry 연결이 끊기면 기존 인스턴스를 바로 제거해야 하나요?

답변 포인트 즉시 제거하면 정상 트래픽도 멈출 수 있어 마지막 version snapshot을 유지합니다. Registry lease와 active health check, 실제 요청 실패를 구분하고 data plane이 stale endpoint를 임시 제외하되 control plane 복구 후 최신 snapshot과 조정합니다.

질문 Client-side discovery와 Gateway·프록시 기반 server-side discovery는 어떻게 선택하나요?

답변 포인트 Client-side는 hop과 프록시 병목을 줄이지만 모든 언어 클라이언트에 resolver·LB·갱신 로직을 배포해야 합니다. Server-side는 정책을 중앙화하고 클라이언트를 단순화하지만 data plane 용량과 가용성을 별도로 확보해야 합니다.

질문 새 인스턴스가 등록됐지만 아직 준비되지 않았거나 종료 중이면 어떻게 막나요?

답변 포인트 Startup과 readiness가 통과한 뒤 등록하고 종료 시 draining 상태로 새 요청을 막은 뒤 기존 연결을 끝냅니다. Heartbeat만 살아 있다는 이유로 트래픽을 보내지 않고 애플리케이션 readiness와 실제 요청 결과를 함께 사용합니다.

질문 두 리전에서 같은 데이터를 동시에 수정하면 어떻게 하나요?

답변 포인트 단일 쓰기 리전, 버전 기반 조건부 쓰기, 업무 규칙 병합이나 CRDT처럼 데이터에 맞는 충돌 정책이 필요합니다.

질문 DNS만 바꾸면 즉시 장애 조치가 되나요?

답변 포인트 DNS cache와 TTL 때문에 늦을 수 있어 글로벌 로드밸런서, 연결 draining과 데이터 준비 상태도 고려합니다.

질문 장애 난 기존 writer가 네트워크 복구 후 다시 쓰기 시작하는 split-brain을 어떻게 막나요?

답변 포인트 승격 때 단조 증가 fencing epoch를 발급하고 저장 계층이 현재 epoch보다 오래된 writer의 쓰기를 거부해야 합니다. 라우팅 전환만으로는 기존 연결과 지연 요청의 쓰기를 막을 수 없습니다.

질문 장애 리전이 복구되면 바로 원래 구조로 failback해도 되나요?

답변 포인트 먼저 새 writer의 로그와 snapshot으로 복구 리전을 따라잡고 checksum·lag를 검증합니다. 읽기 canary부터 점진 전환한 뒤 계획된 새 epoch로 쓰기를 옮기며 급한 자동 failback보다 안정된 현 writer 유지가 안전할 수 있습니다.

질문 재시도가 왜 장애를 더 크게 만들 수 있나요?

답변 포인트 실패 요청이 동시에 재시도되면 retry storm이 발생하므로 retry budget, backoff, jitter와 멱등성이 필요합니다.

질문 평균 응답시간은 정상인데 사용자가 느리다고 하면 무엇을 보나요?

답변 포인트 평균이 숨기는 p95·p99 tail latency를 경로, 리전, 고객군과 의존성별로 분해합니다.

질문 요청별 correlation ID를 metric label로 넣으면 왜 문제가 되나요?

답변 포인트 요청마다 새로운 label 조합이 생겨 time series 수와 메모리·저장 비용이 폭증합니다. Metric은 service·route·status처럼 제한된 값을 사용하고 요청 연결은 log·trace ID와 exemplar로 수행합니다.

질문 Telemetry 백엔드가 장애 났을 때 서비스 요청도 실패시켜야 하나요?

답변 포인트 일반적으로 요청 경로와 격리하고 로컬 bounded buffer, batch와 sampling으로 서비스를 보호합니다. Buffer가 차면 우선순위 낮은 telemetry를 버리되 drop 비율과 collector 상태는 독립 경로로 경보해야 합니다.