47장. Correlation과 Audit을 외부 Receipt까지 잇는다

한 요청에 application correlation id, provider request id, idempotency key, webhook event id와 업무 order id가 생긴다. 어느 하나를 전역 식별자로 오해하지 않고 관계 table 또는 trace에 연결한다. provider raw body와 token을 저장하지 않아도 status, operation, result class, latency, retry, receipt를 남길 수 있다. user id·URL query를 metric label에 넣지 않는다.

{
  "correlationId": "req-7f31",
  "operation": "payment.capture",
  "businessKey": "ORD-1842",
  "providerRequestId": "prv-fixture-91",
  "result": "UNKNOWN",
  "attempt": 1,
  "deployment": "bridgeops-2.3.0"
}

자유 입력, email, 전화, access/refresh token, authorization code와 signature secret은 log·trace·error tracker에서 제외한다. support export는 필요한 사건과 기간만 암호화하고 수신자·만료를 기록한다. audit는 누가 provider credential과 redirect, webhook replay를 변경했는지 별로 남긴다.

incident 중 provider dashboard만 보고 내부 주문을 수정하지 않는다. correlation 관계로 local command→adapter attempt→provider receipt→webhook inbox→ledger를 대사한다. 사용자에게 보여 주는 사건 번호는 내부 구조를 노출하지 않으면서 support가 같은 trace를 찾게 한다.