Trace the journey from request to result

A report-export API can return a job identifier while the report spends most of its life waiting in a queue. If your service map ends at the API response, it leaves out nearly everything the user is waiting for.

A useful dependency map follows the work from the user’s request to the result they need. It shows what each component depends on, who operates it and where you could find out whether a handoff succeeded. That gives a responder somewhere specific to look when the service accepts work but fails to finish it.

In lesson 1, the fictional Dispatch service introduced a five-minute goal: an eligible accepted export should produce the correct report and make it available to the intended user. This lesson develops that example into a service map. All architecture, team assignments and failure cases below are illustrative; you only need a page to draw on.

The request ends before the work does

Start with one export. Dispatch’s API records the job and places work on a queue. A worker takes it, reads the source records, builds the report and writes the output to object storage. The user can then make a separate request to download it.

The queue separates submission from processing. During submission, the API waits for a queue-acceptance result, then returns a job identifier. It does not hold that original connection open while the worker creates the report. The job identifier lets a later request ask what happened to the work.

That is why a successful submission and a delayed report can coexist. The API has done its part, but the service’s promise extends beyond it. The measurement boundary must be able to see the failures of the user operation it claims to protect. If the only observation is “the worker wrote a file,” label that as processing evidence rather than proof of successful download.

Availability to download and an actual download are different, too. A user may choose to collect a report tomorrow. The service still needs evidence that the correct report was available to that user within its promised time; measuring when someone eventually clicks the link would add their own delay to the service’s work. Keep that choice explicit on the map.

An arrow should explain a handoff

Draw the API, queue, worker, source-data store and output store, then add the submission and download requests around them. Label what moves along each arrow. A queued job message, a read of source records and a download of report bytes are different operations, even if a drawing represents each with the same line.

Next, ask what confirms each handoff. The following notes turn the picture into something an investigator can use:

Handoff	What you need to establish	Evidence to look for
API to queue	The accepted job reached the queue.	A job identifier and an enqueue outcome.
Queue to worker	The job started after its wait.	Enqueue and worker-start times for that job.
Source store to worker	The worker obtained the records needed for this report.	A read result tied to the job or processing attempt.
Worker to output storage	The worker wrote the expected output.	A write result and the output associated with the job.
Download path to user	The intended user could retrieve the correct output.	An authorized retrieval check or suitable user-side evidence.

Some of those records may be missing in a real service. Mark the gap where it occurs, such as “we can see ready state but cannot verify download access.” That is more useful than drawing an observation point and assuming the corresponding telemetry exists.

Ownership tells you who can help

For this exercise, the Dispatch application team owns the API, worker and download behavior. A messaging team operates the queue, a data team operates the source store and a storage platform team operates output storage. Put those names beside the components they operate.

Now follow a dependency across a team boundary. The storage team may restore a broken storage service, but the application team still needs to explain what that failure does to exports. Do workers retry? Can a retry produce two outputs? Does a user see a failed job or an indefinitely pending one? Those questions describe Dispatch’s behavior, even when the underlying component belongs to someone else.

Record an unknown answer as a question for the relevant team. For example, “Ask the application owner whether a failed write leaves the job retryable” is a useful follow-up. Writing “retries handled” without knowing how would conceal the very behavior the map is meant to explain.

This keeps the map focused. Expand it when a dependency changes the outcome, ownership or recovery decision. You do not need every internal library, but you do need an authorization check that can prevent the intended user from collecting the finished report. Google’s SLO guidance provides the next step: choosing observations that represent the user-facing result you have now defined.

Two missing reports, two different investigations

Consider a hypothetical storage slowdown. Workers spend longer waiting for writes to finish. While occupied, they cannot take the next jobs, so work can accumulate in the queue even while the API continues accepting submissions. A user sees a delayed report without seeing which of those stages consumed the time.

Compare that with a broken download authorization check. Jobs start promptly, workers finish normally and files are present, but the intended users receive an access error. The symptom is still “I cannot get my report,” yet adding workers would not address this failure.

The map tells you how to separate the explanations. Long enqueue-to-start intervals together with slow writes support investigating the processing and storage path. Normal processing followed by failed authorized retrieval sends the investigation toward the download path. Slow storage could also have other effects, so treat this as a way to choose observations, not as proof of a cause.

More workers are not an automatic answer to the first case either. If storage is already the constraint, more simultaneous writers may add load without increasing completed exports. Find the delayed handoff before choosing which component to scale.

Walk someone else through one export

Draw Dispatch’s main journey with the source-data read and download authorization included. For each handoff, note what moves, whether the caller waits, which team can help and what confirms success. Mark the start of the five-minute goal and the evidence that would establish an authorized report was available before it expired.

Compare with a worked map

The submission request reaches the API, which records a job and waits for queue acceptance before returning its identifier. The job waits until a worker starts it. The worker reads source records and writes the report to output storage. A later download request checks access and retrieves that output for the intended user. The application team owns the API, worker and download behavior; the messaging, data and storage teams operate their respective dependencies. Enqueue/start records distinguish waiting from processing, while write and retrieval results distinguish a produced file from a usable report. If retrieval evidence is absent, leave the final milestone unverified.

The finished map should let another reader follow one export and explain why a healthy API cannot settle a complaint about a missing report. It should also give them a concrete next check: locate the wait, inspect a failed read or write, or test the authorized download. That is the service understanding you will use when choosing reliability indicators in lesson 3.