Trace the Request Before You Tune the Service

Mon, 17 Aug 2026 00:00:00 +0000

A slow endpoint is rarely one indivisible wait. It is a chain: connection setup, queueing, application work, storage, and the trip back to the caller. The useful question is not simply “why is this request slow?” but “where did this request spend its time?”

Start with one trace

Pick one real slow request and write down its stages before changing a timeout or adding a cache.

gateway 18 ms
queue 142 ms
application 31 ms
database 24 ms
response 6 ms

The application function is not the bottleneck in this example. Making it twice as fast saves about 15 milliseconds while the request still waits 142 milliseconds before the function starts.

The Queue Is Part of Your API Contract

Mon, 10 Aug 2026 00:00:00 +0000

Moving work behind a queue changes latency, ownership, and failure semantics. It does not make those concerns disappear.

Acknowledgement is not completion

An HTTP 202 Accepted response says the server accepted responsibility for attempting the job. It should not imply that the job succeeded, or even that a worker has started it.

Clients need a durable job identifier and a status model they can understand:

{
 "job_id": "job_7f31",
 "state": "queued",
 "status_url": "/jobs/job_7f31"
}

Retries create duplicates

A worker can finish the side effect and crash before acknowledging the message. The queue then delivers the same message again. That is ordinary at-least-once delivery, not an exotic edge case.

Systems on Stacknote Demo

Trace the Request Before You Tune the Service

Start with one trace

The Queue Is Part of Your API Contract

Acknowledgement is not completion

Retries create duplicates