Distributed tracing for serverless apps
end-to-end observability.
propagate a trace context through every hop, instrument with OpenTelemetry or X-Ray, capture spans including the database, and correlate traces with structured logs.
per-service logs, no correlation.
What's really being asked
This evaluates whether you can build the three pillars of observability, traces, metrics, and logs, into a distributed serverless system so a single slow request is diagnosable.
The full answer
Distributed tracing hinges on context propagation. A trace ID is created at the entry point, typically the API gateway, and passed via headers through every function and downstream call so all spans roll up into one trace. Instrument each component with OpenTelemetry or a provider tracer such as X-Ray, creating spans for the gateway, each function invocation, and each external call including database queries, so you see exactly which hop consumes the latency. Emit structured JSON logs that include the trace ID and a request correlation ID so logs join to traces. Capture metrics such as per-function duration, error rate, throttles, and cold-start counts. Send everything to a backend where you can view the waterfall, spot the bottleneck span, and drill into the correlated logs. Sample intelligently to control cost while always capturing errors.
The mistakes people make
Relying on separate, uncorrelated logs per function so you cannot reconstruct a request path. Forgetting to instrument the database call, often the actual bottleneck. Failing to propagate trace context across async boundaries such as queues. Logging unstructured text that is hard to query. Sampling so aggressively that error traces are lost.
What usually comes next
How do you propagate context through an async queue? What sampling strategy balances cost and coverage? How do spans and logs correlate? How much latency does instrumentation add?
A concrete example
A request is slow. The trace waterfall shows the gateway and two functions are fast, but a 400ms span on a single database query dominates the request. The correlated log line for that span reveals a missing index on the queried column; adding the index collapses that span and the end-to-end latency drops sharply.
Interview question
What single technique lets you reconstruct one request's full path across an API gateway, several functions, and a database?
- a.Propagating a shared trace context so all spans join into one traceCorrect
- b.Enabling provisioned concurrency everywhere
- c.Increasing log verbosity on every service
- d.Running all functions inside the same VPC
Why? this is the answer
Propagating a trace ID through every hop links spans into a single trace, exposing the slow segment. More verbose but uncorrelated logs, shared networking, or warm starts do not stitch a request together across services.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #serverless
- #observability
- #tracing
- #opentelemetry
- #monitoring
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on serverless — each one lists the topics its interview covers.
See open roles