tenant + Idempotency-Key로 재시도 요청은 같은 message를 재사용합니다.
분산 이메일
서비스 설계
API accepted나 SMTP remote accepted를 사용자의 inbox 도착으로 말할 수는 없습니다. 도메인별 queue·재시도·bounce·complaint를 분리해 확인 가능한 상태만 표시합니다.
개념 이해전송 경로인증·평판장애 대응진도 저장
30초 핵심 요약
API accepted, SMTP remote accepted, bounce·complaint, mailbox placement를 별도 상태로 둡니다. 4xx는 domain별 backoff, 5xx는 상세 사유에 따라 처리하며 확인된 주소 오류·complaint는 suppression에 반영하고 확인하지 못한 inbox 도착은 보장하지 않습니다.
요청 경계Idempotency + outbox
전송 경계Domain queue + MTA
결과 경계Accepted ≠ inbox
01 · REQUIREMENTS
# 요구사항보냈다는 말을 단계별 상태로 나눈다
SMTP의 원격 수락, inbox placement, 열람은 같은 신호가 아닙니다. 이 설계는 transaction·marketing 목적과 수신자별 결과를 먼저 모델링하고, 발신 서비스에는 SMTP credential과 retry 정책을 숨깁니다.
fan-out 뒤 queue·attempt·bounce를 recipient 단위로 기록합니다.
suppression, unsubscribe, domain rate, abuse 검사를 전송 직전에 적용합니다.
API accepted, SMTP accepted, deferred, bounced, complained를 합치지 않습니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처메시지, 수신자, transport feedback을 분리한다
outbox는 API 수락과 전송 작업 발행의 틈을 줄입니다. composer는 변경되지 않는 MIME 원본을 만들고, domain queue와 MTA pool은 원격 도메인의 실패·속도·평판을 다른 tenant와 격리합니다.
이메일 제출부터 feedback까지의 독립 경로 SVG DIAGRAM · message / recipient / MTA / DSN
중요: SMTP timeout 뒤 원격 MTA가 실제로 받았을 수 있습니다. 따라서 queue의 at-least-once 재처리는 허용하되 새 message를 만들지 않고, message·recipient·attempt ID와 retry budget으로 중복 위험을 줄입니다.
SMTP 수락 이후 어디까지를 전달 성공이라고 말할 수 있는가?
예시 이메일 요청
600만/day
설계 가정
예시 피크 job
약 1,670/s
계산 결과
예시 MIME 원본
230GB/day
계산 결과
recipient state + domain queue + verified MTA feedback
API accepted, 원격 MTA accepted, bounce·complaint를 수신자별 상태로 나눕니다. domain queue에서 4xx backoff와 rate control을 적용하고 검증된 feedback을 suppression에 반영합니다.
선택 이유
- SMTP 250을 받은편지함 도착으로 과장하지 않습니다.
- 특정 domain 장애와 평판 문제를 다른 발송에서 격리합니다.
- bounce·complaint·unsubscribe 뒤 재발송을 빠르게 차단합니다.
API 요청 안에서 SMTP를 동기 호출하고 성공으로 종료
외부 timeout이 업무 latency에 결합되고 이후 bounce·complaint와 domain별 retry 상태를 추적하기 어렵습니다.
감수한 단점
- domain별 queue·rate·IP reputation 운영이 필요합니다.
- SMTP timeout 뒤 중복 가능성을 완전히 제거할 수 없습니다.
- MIME·첨부·feedback 보존이 storage와 보안 비용을 늘립니다.
03 · SUBMISSION / DELIVERY FLOW
# 요청 흐름수락, 조립, 전송, 피드백을 순서대로 남긴다
첨부를 포함한 이메일의 raw MIME은 재시도 중에 조용히 바뀌지 않아야 합니다. 수신자별 job이 도메인 정책·suppression을 다시 확인하고, MTA의 응답과 DSN을 event로 추가합니다.
API가 identity, template, 멱등 키를 검증해 message와 outbox를 함께 기록합니다.
scan 완료 object를 stream하고 versioned template·Message-ID·DKIM 서명을 준비합니다.
수신 domain queue에서 unsubscribe, suppression, quota, rate·TLS 정책을 확인합니다.
submission/MTA가 MX로 relay하고 recipient별 reply class와 attempt를 남깁니다.
bounce·complaint·DSN을 dedupe해 state와 suppression, 평판 지표에 반영합니다.
04 · TRADEOFFS
# 대안과 트레이드오프처리량보다 도메인별 제어가 전달 품질을 지킨다
재시도 기간을 늘리면 일시 장애 복구율은 오르지만 늦은 메일과 비용도 늘어납니다. 전역 처리량보다 domain별 반응과 sender reputation을 우선해 속도를 조절합니다.
| 선택 | 장점 | 제약 | 권장 판단 |
|---|---|---|---|
| 앱이 SMTP 직접 호출 | 초기 구현 짧음 | credential·timeout·retry가 업무 요청에 섞임 | 소규모 내부 도구 외에는 지양 |
| API + outbox + MTA pool | 전송 장애 격리·감사·재처리 | 상태 모델과 운영 구성 증가 | 거래성 또는 multi-tenant 기본 |
| 단일 전역 queue | 운영 단순 | 캠페인·문제 domain이 전체를 막음 | 매우 작은 volume에 한정 |
| domain queue + token bucket | 원격 제한·평판·backlog 격리 | coordinator와 domain dashboard 필요 | 인터넷 발송의 기본 |
| inline 첨부 | 수신자 UX 단순 | queue·scan·storage 비용 증가 | 작고 scan 완료된 파일만 |
| signed download URL | 큰 payload와 민감 파일 통제 | 만료·수신자 인증 UX 필요 | 대용량 또는 민감 첨부에 검토 |
05 · FAILURE MODES
# 장애 6가지여섯 가지 실패를 transport와 평판 신호로 다룬다
outbox relay 중단
API는 accepted인데 recipient job이 큐에 만들어지지 않아 이메일이 출발하지 않습니다.
대응 · outbox lag·message/job 차이로 감지하고 idempotent replay와 reconciliation으로 누락 0을 검증합니다.
DNS/MX 또는 원격 4xx
특정 수신 domain의 lookup·MTA 응답 문제가 queue age와 retry를 늘립니다.
대응 · domain circuit breaker, cached resolver, jitter와 retry budget을 적용하고 backlog drain을 확인합니다.
SMTP timeout 뒤 결과 불명
원격 MTA 수락 여부를 모른 채 worker가 죽어 중복 또는 누락 위험이 생깁니다.
대응 · attempt 이력·stable message ID·제한 재시도로 새 message 생성을 막고 ambiguous 비율을 관측합니다.
DKIM key·selector 배포 오류
서명 또는 DNS publish 불일치가 인증 실패·spam 판정 증가로 이어질 수 있습니다.
대응 · key version rollout·검증 sample·rollback을 준비하고 domain health error spike를 봅니다.
첨부 scan/object 장애
첨부를 읽지 못하거나 scan 전 파일이 compose 경로에 노출될 수 있습니다.
대응 · immutable object와 ready gate·격리 버킷을 사용하고 scan pending age를 SLO로 둡니다.
complaint·abuse 급증
한 tenant의 악용이 IP·도메인 평판을 떨어뜨려 다른 발신자의 전달을 해칩니다.
대응 · tenant pause, suppression, quota, review queue로 격리하고 complaint baseline 회복을 검증합니다.
면접 모드 · 추가 질문06:00
“하루 600만 요청·960만 수신자에게 거래성 메일과 캠페인을 함께 보내야 합니다. SMTP timeout 뒤 중복을 줄이고, bounce·complaint를 반영하며, TLS·DKIM·DMARC와 대용량 첨부까지 다루려면 어떤 데이터 모델·queue·MTA policy·관측 지표를 설계하시겠습니까?”
message + recipientdomain queueattempt + feedbackDKIM · TLS policysuppression · reputation
답변 구조 보기 5단계
- API accepted, SMTP remote accepted, bounce·complaint, mailbox placement를 다른 상태로 정의한다.
- MIME 원본과 수신자별 job을 만들고 domain queue로 속도·평판 장애를 격리한다.
- 4xx는 backoff, 5xx는 주소 오류·메시지·정책 거절을 구분한다. 확인된 주소 오류와 complaint는 suppression에 반영하고, timeout은 모호한 attempt로 처리한다.
- DKIM·TLS·credential·첨부 scan을 전송 전후의 보안 경계로 운영한다.
- domain별 queue age와 SMTP class, bounce·complaint로 복구를 판정한다. 이번 선택: 비동기 domain queue와 MTA feedback을 사용하고, 확인한 범위까지만 전달 상태로 공개한다. 깨지는 신호: SMTP 250을 inbox delivery로 집계하거나 hard bounce 주소가 계속 재시도된다. 다음 검증: 특정 domain의 4xx·timeout·complaint burst를 재현해 rate 조절과 suppression 반영 시간을 측정한다.
SMTP 상태 범위를 설명하고 domain 평판·suppression을 운영하기
accepted, remote accepted, mailbox placement를 서로 다른 상태로 답합니다.
- MIME·recipient job·domain queue 흐름을 설명합니다.
- 4xx·5xx·timeout의 다른 재시도 정책을 말합니다.
- DKIM·TLS·bounce·complaint suppression을 연결합니다.
한 domain의 4xx와 complaint burst에서 발송량보다 평판을 보호합니다.
- domain별 queue age와 SMTP class를 관측합니다.
- hard bounce 주소가 다시 enqueue되지 않는지 확인합니다.
- rate 축소 뒤 complaint와 retry budget 회복을 검증합니다.
TECHNICAL DOCUMENTS
기술 규격·공식 문서
- IETF RFC 5321 — Simple Mail Transfer Protocol: SMTP transport, relay, mail submission과 응답 모델.
- IETF RFC 5322 — Internet Message Format: 메시지 header field와 body 형식.
- IETF RFC 6376 — DomainKeys Identified Mail: DKIM 서명·검증과 DNS 공개 키 모델.
- IETF RFC 8461 — SMTP MTA Strict Transport Security: 수신 도메인의 SMTP TLS 정책 게시와 발견.
이 문제와 이어지는 문서알림 시스템
개인별 선호와 채널 정책을 연결합니다.
TECHNICAL DOCUMENTS & CONTACT
문의·정정
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.