연습 목표
푸시·이메일·SMS의 실패와 중복 발송을 제어합니다. 이 연습에서는 완성된 아키텍처를 외우지 않고, 요구사항에서 비동기 큐 결정을 끌어내는 과정을 말로 설명합니다.
1. 면접에서 먼저 확인할 조건
알림의 핵심 사용자 흐름, 일일 요청량, 읽기/쓰기 비율, 허용 지연 시간, 데이터 보존 기간을 확인합니다. 재시도, 순서, 중복 소비, DLQ를 설계합니다.
- 정상 흐름 하나와 실패 흐름 하나를 문장으로 적는다.
- 강한 정합성이 필요한 데이터와 지연 허용 가능한 데이터를 구분한다.
- 성공 기준을 오류율·지연 시간·처리량 중 하나 이상으로 정한다.
2. 설계 답변 뼈대
클라이언트 → API → 도메인 서비스 → 저장소/비동기 작업의 경계를 먼저 그립니다. 이후 비동기 큐에 필요한 구성요소를 추가하고, 왜 지금 필요한지와 나중에 확장할 지점을 나눠 설명합니다.
- 요청·응답 계약과 멱등성 여부를 설명한다.
- 데이터 모델 또는 이벤트 모델의 불변 조건을 하나 이상 말한다.
- 장애 시 사용자에게 보이는 동작과 운영자의 복구 절차를 말한다.
3. 검증과 트레이드오프
선택한 구조가 알림의 요구를 만족하는지 부하 테스트, 장애 주입, 로그 추적으로 검증합니다. 비용·복잡도·일관성 중 무엇을 우선했는지 명시해야 답변이 설득력을 얻습니다.
- 가장 위험한 가정을 하나 고르고 측정 방법을 정한다.
- 캐시·큐·복제본을 쓰지 않는 단순한 대안도 비교한다.
- 배포와 롤백 때 데이터 호환성을 확인한다.