How would you design OpenTelemetry tracing for 200 microservices?
743 views
23 of 106
1
The problem
Question presented to candidate:
"We run about 200 microservices in several languages on Kubernetes, and when a request is slow nobody can tell which service is at fault. Design distributed tracing for us with OpenTelemetry: how the data is produced, how it travels, how much of it we keep and how we roll it out."
What a strong answer should cover:
Context propagation: the W3C traceparent header (version, 16-byte trace ID, 8-byte parent span ID, flags), carried over HTTP, gRPC and message headers; what happens when a hop drops it
Instrumentation: OpenTelemetry SDKs plus auto-instrumentation for common libraries, a thin shared wrapper for conventions (service.name, service.version, semantic conventions), manual spans only where they add value
Pipeline: SDK exports OTLP to a local agent Collector, which forwards to a gateway Collector tier; the loadbalancing exporter routes by trace ID so tail sampling sees whole traces
A worked capacity estimate (spans per second, bytes, storage per sampling rate, number of collectors)
Sampling policy (head for volume, tail for errors and slow requests) and its failure modes
Rollout and operations: start at the edge and the most critical paths, measure propagation coverage, protect apps with bounded queues so tracing never takes production down
Clarifying questions expected:
What traffic volume, and how many services does a typical request touch?
Which languages and frameworks, and are there async paths (Kafka, queues, cron)?
Build or buy the backend, and what retention and budget?
Code / implementation expected: Optional โ the example builds and parses traceparent, shows a header-dropping proxy splitting a trace, and runs the capacity and routing arithmetic.
opentelemetry
tracing
observability
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers who know what a trace is (see the pillars doc) and want to design tracing for a real, polyglot microservice fleet, and candidates preparing for an observability design round.
Difficulty: Medium
Verified with: Node 22.22 and Python 3.12 (both print identical output). Header format from the W3C Trace Context Recommendation; Collector component behaviour from the loadbalancing exporter README on pkg.go.dev and Grafana Alloy documentation of the tail sampling processor; OTLP ports and the Operator injection mechanism from OpenTelemetry-focused guides (Honeycomb docs, OneUptime articles), which you should check against the version you deploy.
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the words an interviewer expects. Every number comes from running the example; th
The solution is hidden so you can try first
17 min read ยท 14 sections
4
Read the code
W3C traceparent propagation over HTTP and a queue, a header-dropping proxy, capacity for 200 services, and trace-ID routing to collectors