⌁시스템 디자인 학습 문서 / 집계 시스템 / Chapter 21 전체 로드맵
CASE · ADVANCED읽기 28분검토일 2026-08-29PROVISIONAL + RECONCILED

광고 클릭 이벤트
집계 설계

클릭 수는 바로 보여 줄 수 있지만 바로 청구하면 안 됩니다. 늦은 이벤트·중복·무효 판정을 숫자의 변경 이력으로 남겨 잠정 집계와 확정 금액을 분리합니다.

21운영자 직접 작성·기술 검토·최종 검토 2026.08.29
개념 이해요구사항면접 질문장애 대응진도 저장
⌁30초 핵심 요약

event-time watermark로 잠정 집계하고 늦은 도착과 무효 판정은 불변 delta로 더하거나 뺍니다. 실시간 dashboard와 청구 마감을 나누고, 대사가 끝난 billing version만 확정합니다.

IDENTITYclick_id + payload hash
TIMEevent time + watermark
TRUTHbase + immutable delta
DESIGN DECISION · 설계 판단

잠정 클릭이 청구 금액으로 닫힐 때까지 어떤 변경 이력을 남길 것인가?

예시 피크 수집 500,000 events/s 계산 결과
예시 원본 3.24TB/day 계산 결과
예시 허용 늦음 20분 설계 가정
최종 선택

event-time 잠정 집계 + immutable delta + billing close version

클릭 원본과 first-seen dedupe를 보존하고 watermark로 잠정 집계를 만듭니다. late·fraud 판정은 delta로 반영하며 T+72 대사 뒤 불변 billing close version으로 확정합니다.

선택 이유

  • 실시간 신선도와 청구 정확성의 마감 시각을 분리합니다.
  • 늦은 클릭과 무효 판정이 어떤 숫자를 바꿨는지 감사할 수 있습니다.
  • close 뒤 정정도 credit memo나 새 version으로 추적할 수 있습니다.
포기한 대안

campaign별 counter를 replay 때마다 직접 덮어쓰기

중복·late·fraud correction의 근거와 과거 청구 명세가 사라져 분쟁과 재현이 불가능합니다.

감수한 단점

  • watermark와 72시간 조정 창만큼 상태·지연 비용이 듭니다.
  • hot campaign와 replay burst를 별도 격리해야 합니다.
  • close 뒤 correction은 즉시 counter 변경보다 운영 절차가 무겁습니다.
01 · REQUIREMENTS

실시간 숫자와 정산의 진실을 분리한다

# 요구사항

클릭 리포트는 빠른 최적화 신호이고, 청구는 계약·무효 활동·분쟁이 반영된 승인 기록입니다. 하나의 카운터가 두 역할을 모두 맡으면 late event와 fraud 재판정이 발생할 때 설명할 수 없는 숫자가 됩니다.

IN수집 계약

서명 token, click_id, 발생·수신 시각을 받아 durable log에 수락합니다.

WIN시간 window

campaign·publisher·minute 기준 event-time 집계와 watermark를 제공합니다.

FRA무효 트래픽

rule/model version과 reason을 남겨 valid·pending·invalid를 분리합니다.

BIL정산 조정

base count를 덮지 않고 late·retraction delta와 close snapshot을 기록합니다.

02 · ARCHITECTURE

원본, 판정, 합계, 조정을 서로 다른 정본으로 둔다

# 고수준 아키텍처
광고 클릭 수집·집계·정산 분리raw log → dedupe → event-time aggregate → delta → close
광고 클릭 이벤트 집계 아키텍처브라우저와 앱의 클릭이 redirect와 ingest gateway를 거쳐 내구 로그에 저장된다. dedupe와 event-time 처리기가 base aggregate를 만들고, fraud 판정과 늦은 이벤트는 immutable delta를 기록한 뒤 reconciliation과 billing close로 이어진다. Browser · Appsigned redirect tokenclick_id Ingest gatewayauth · receipt · rate limitdurable click log Dedupehash conflictfirst seen Report APIbase + deltawatermark Event-time window processorwatermark · late event · base aggregate Fraud + reconciliationvalidity ledger · immutable delta Billingclose 잠정 집계와 청구 확정을 같은 카운터로 취급하지 않는다.
수치 계약 · 대시보드는 watermark, validity_state, aggregate_revision을 표시합니다. billing은 승인된 close_snapshot만 읽고, close 이후 변경은 근거가 있는 delta와 credit memo로 다룹니다.
03 · EVENT FLOW

중복을 억제하고, 시간을 닫고, 조정은 남긴다

# 요청 흐름
1Validate

token·campaign 관계·크기·발생 시각 범위를 검사하고 receipt를 붙입니다.

2Dedupe

click_id와 payload hash로 duplicate·conflict를 구분합니다.

3Window

event time으로 minute window를 만들고 per-partition watermark를 적용합니다.

4Classify

rule/model version이 valid·pending·invalid와 reason을 기록합니다.

5Reconcile

late/retraction delta와 raw-to-billing 대조를 승인 흐름으로 남깁니다.

04 · TIME & IDENTITY

watermark는 확정 약속이 아니라 진행 경계다

# 시간·중복

실시간 숫자를 바로 청구에 쓰면 구조는 단순하지만 늦은 이벤트와 무효 클릭을 설명할 수 없습니다. 공개 집계의 속도와 청구 원장의 확정 시점을 분리합니다.

선택얻는 것대가·검증
processing-time count낮은 지연, 단순한 workeroffline SDK와 리전 지연으로 시간대가 왜곡됨
event-time + watermark발생 시각 기준의 공정한 window열린 state, watermark stall, late delta를 운영
exact click_id dedupe청구 경로의 재시도 중복을 강하게 제어TTL·고카디널리티 state·conflict 격리 필요
probabilistic filter저비용·대규모 중복 힌트false positive가 실제 클릭을 잃을 수 있어 청구 정본에는 부적합
overwrite replay처음 구현은 빠름과거 값·원인·정산 snapshot을 설명할 수 없음
base + immutable deltalate·retraction·rollback의 계보query merge, compaction, 승인 절차가 필요
05 · FAILURE MODES

유실, 중복, 늦음, 오판을 각각 복구한다

# 장애 시나리오 8개
↻gateway timeout과 retry

수신 결과를 모른 client가 재전송하면 같은 클릭이 여러 번 도착합니다.

대응 · stable click_id와 payload hash; raw→dedupe 보존율과 duplicate 억제율을 대조합니다.
⌛watermark 정지

idle partition 또는 source 지연으로 window가 닫히지 않고 state가 증가합니다.

대응 · source health와 watermark age를 경보; 임의로 processing-time close하지 않고 idle 정책을 검증합니다.
!hot campaign skew

초대형 캠페인이 한 partition을 과열시켜 checkpoint와 P99를 악화시킵니다.

대응 · salted key·capacity 분리; merge 합계와 key skew를 함께 확인합니다.
×fraud model 오배포

정상 클릭이 대량 invalid 처리되거나 retraction이 급증합니다.

대응 · canary·kill switch·model rollback; versioned delta reversal과 샘플 감사를 실행합니다.
⇣late event 폭증

publisher clock 또는 배치 장애가 정정·backfill 비용과 리포트 흔들림을 키웁니다.

대응 · late ratio·delay tail을 source별 분석; quarantine과 좁은 window replay를 승인합니다.
⊕aggregate sink 중복

retry가 같은 revision을 두 번 써 count가 중복될 수 있습니다.

대응 · window+dimension+revision idempotency key; base/delta conservation check로 검증합니다.
?reconciliation 불일치

원본, validity, aggregate, billing close가 서로 다른 범위를 참조합니다.

대응 · input range·rule version·snapshot id를 비교하고 credit memo 또는 scoped replay로 처리합니다.
⊘삭제 전파 실패

삭제된 식별 신호가 archive·DLQ·feature store에 남아 규정 위험이 됩니다.

대응 · purpose별 retention task와 forbidden-read audit; 완료 상태를 downstream별로 증명합니다.
06 · OPERATIONS

숫자만이 아니라 수치의 신선도와 근거를 관측한다

# 운영 관점
⌛시간 의미

event-to-receive delay, watermark age, open window 수, late ratio를 publisher·리전·partition별로 봅니다. report에는 watermark와 pending 여부를 함께 표기합니다.

watermark_age_seconds
✓정확성 계보

raw → dedupe → validity → base + delta → close의 conservation을 버전별 대조합니다. click_id trace에는 token과 원본 IP를 넣지 않습니다.

aggregate_reconciliation_gap
₩보안·비용

원본·archive·state·fraud inference·replay·분쟁 조사를 따로 산정합니다. 권한은 ingest, analyst, investigator, billing approver로 분리합니다.

cost / valid_click / close
면접 모드 · 추가 질문05:00
“오전 10시 window의 실시간 클릭은 이미 광고주 화면에 보였는데, 40분 뒤 무효 클릭 모델이 3%를 invalid로 판정했습니다. 수치를 어디에서 어떻게 고치며, 청구와 감사 추적은 무엇으로 분리하겠습니까?”
event time + watermarkclick_id dedupevalidity ledgerimmutable retraction deltabase + delta reportclose snapshotscoped reconciliation
답변 구조 보기 5단계
  1. click_id, payload hash, occurred_at, received_at을 분리해 수집 재시도와 시간 지연을 구분한다.
  2. event-time window와 watermark는 잠정 집계 경계이며 영구 확정 약속이 아니다.
  3. late·invalid·복원 판정은 immutable delta로 기록해 base aggregate를 덮어쓰지 않는다.
  4. 실시간 dashboard와 T+72 billing close를 다른 version·정확성 계약으로 운영한다.
  5. replay는 원본→dedupe→validity→delta→close를 대사한 좁은 범위에서 실행한다. 이번 선택: 불변 클릭 원본과 조정 원장을 사용하고, 청구는 별도 close version으로 확정한다. 깨지는 신호: dashboard와 billing 차이를 설명할 delta가 없거나 replay가 닫힌 기간의 counter를 직접 덮는다. 다음 검증: late spike·fraud rule rollback·sink 중복을 주입해 close 차이와 credit memo 생성 시간을 측정한다.
INTERVIEW ↔ PRACTICE · 면접과 실무의 차이

event-time과 청구 close를 설명하고 delta·reconciliation을 운영하기

INTERVIEW · 면접

잠정 집계, 조정 원장, 청구 확정의 세 시간 경계를 답합니다.

  • click ID와 occurred/received time을 구분합니다.
  • watermark 뒤 late·invalid delta 흐름을 설명합니다.
  • billing close 뒤 correction을 version으로 남긴다고 답합니다.
PRACTICE · 실무

한 클릭이 +1·-1·close 0이 되는 전 과정을 대사합니다.

  • watermark delay와 late delta 비율을 관측합니다.
  • fraud rule rollback이 반대 delta를 남기는지 확인합니다.
  • stream·batch·billing close 차이를 승인된 범위에서 조정합니다.
PRIMARY SOURCES

시간 처리와 클릭 계약은 공식 문서로 다시 확인한다

CONNECTED TOPIC분산 메시지 큐 설계에서 이벤트 전달 경계 보기
→
EDITORIAL NOTES

작성·검토·참고 자료

콘텐츠 원칙
이 문서는 독립적으로 재작성한 한국어 학습 자료입니다. 사실과 학습용 설계 가정을 구분합니다.
작성·기술 검수
프로젝트 운영자가 직접 작성·기술 검토했습니다. 주제별 공식·1차 자료와 명시적인 설계 가정을 확인하며, 독립적인 제3자 검수가 아닙니다. 경력 범위와 검수 원칙 보기
최종 검토
예상 학습 시간
28분

사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.