Middle · Network services
One request, one time budget
Which timeouts should a production Go HTTP service configure?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Distinguish incoming server read/header/write/idle controls from outgoing client and transport timeouts. A client timeout and a request context constrain different scopes; use a shared Transport/Client instead of rebuilding pools for each call.
Propagate a request context to storage and outbound calls. Budget time across attempts, backoff and response work rather than allowing every downstream operation a full independent timeout. Request bodies and response reads need size limits.
Drain/close response bodies according to the API contract so reusable connections can be reclaimed. Treat cancellation and timeout as outcomes, and never assume a timed-out write did not reach its server.
Common trap
A server WriteTimeout is not a universal cancellation mechanism for every goroutine doing application work.
Try it
Your endpoint has a500 ms budget and calls two dependencies serially. How should retries fit?
Worked solution
Allocate less than the full500 ms to each stage and reserve response time. Retry only classified transient, safe operations while the remaining deadline permits. Measure the actual end-to-end latency, including pool checkout and backoff.
Change the constraint
How can a slow response body exhaust connections even if dialing is fast?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.