Mental model#
A request ID identifies one ingress attempt for search and support. A trace ID correlates a distributed operation. Neither authorizes access, proves identity, or replaces an idempotency key that protects a business effect.
Mechanism and state flow#
- Accept an external correlation value only after length and character validation, or replace it at the edge.
- Generate an internal request or trace identifier and propagate it through logs and downstream calls.
- Create a separate stable idempotency key for retry-safe mutations.
- Return a safe support identifier to the caller without exposing topology or credentials.
- Index the identifier where operators can follow the request under least-privilege access.
Concrete example#
A client retries an order creation
Both HTTP attempts have different request IDs, may share one trace or linked traces, and carry the same idempotency key. The idempotency record returns the first committed order; request IDs let operators inspect both attempts.
Architecture consequence: Model diagnostic correlation and business deduplication as separate identities with separate retention.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Client-supplied correlation ID | Cross-organization support needs a shared reference. | It is untrusted input and can collide or carry unsafe data. |
| Edge-generated ID | The platform needs a controlled unique namespace. | External systems need an explicit mapping. |
| Single ID for every purpose | Never; the semantics differ. | Conflates observability, authentication, and business correctness. |
Failure diagnosis#
- Failure
- A service treats a caller-provided request ID as an authorization or dedupe key.
- Impact
- An attacker can collide with another request or suppress a legitimate operation.
- Detection
- Security tests show outcomes change when only the diagnostic header is reused.
- Mitigation
- Separate trusted identity, authorization, idempotency, and diagnostic identifiers; validate each at its boundary.
- Trade-off
- More identifiers require clearer schemas and support tooling.
Checklist exercise#
Work the scenario before revealing your answer
- Label request ID, trace ID, session ID, user ID, and idempotency key in one write flow.
- For each, state who creates it, who trusts it, how long it lives, and what decision it may influence.
- Reject any design where a diagnostic identifier grants access.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Can a client choose this ID?
- What happens across retries and asynchronous work?
- Which identifier appears in a support response?
- How do you prevent correlation fields from leaking tenant data?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Context propagationOpenTelemetry
- OpenTelemetry logging specificationOpenTelemetry
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.