Practice: Describe a Request Path

By the end of this lesson, you will be able to...

• Build a short request trace with from, through, to, into, and out of.

• Add dependency, waiting, response, and recovery relations without losing the path.

• Revise a vague trace so another engineer can follow the request and its failure branch.

Idea in one sentence: A good request trace lets each preposition answer one small question about where the request moves, what it meets, and what happens next.

Core Insight

A request path is a sentence-sized map. It has a starting point, intermediate boundaries, destinations, and sometimes a side path for a retry or failure. The prepositions are the labels on that map:

The request moves from the browser through the edge proxy to the checkout API.
The API writes the command into the queue.
The worker reads the command out of the queue and sends it to the database.

The first sentence describes movement through named boundaries. The second and third add an inside/outside transition and a new destination. The vocabulary from the previous lesson then lets us add behavior:

The API depends on the identity service and responds to the browser.
The worker waits for a database connection.
The service recovers from a timeout before retrying.

The goal is not to write the longest possible architecture paragraph. The goal is to make the path inspectable one relation at a time.

The Small Situation: Trace a Checkout Request

An engineer is investigating a checkout request. The system has these visible components:

browser -> edge proxy -> checkout API -> command queue -> payment worker -> database

The request succeeds in the normal case. During one incident, the database connection pool is exhausted and the worker waits until a timeout. A first note says:

The checkout is in the browser and goes in the edge.
The API works with the queue and the worker is in the database.
After this, the payment is made.

The reader can guess the story, but cannot trace the path. Which component receives the request? Does the API publish a command or merely work near the queue? Is the worker inside the database, or does it send a query to it? The revision should make each relation visible.

Step 1: Draw the Path Before Writing

Start with arrows and nouns, not polished English:

browser -> edge proxy -> checkout API -> command queue
command queue -> payment worker -> database

Mark the role of each arrow:

Now write the normal path:

The request moves from the browser through the edge proxy to the checkout API.
The API writes the payment command into the command queue.
The worker reads the command out of the queue and sends a query to the database.

The arrows prevent a common error: using in for every relationship. Into shows entry into a container or stream. Out of shows removal from one. To identifies a destination. Through shows an intermediate boundary that the request crosses.

Step 2: Add the Service Relations

The path alone does not explain why a component can pause or fail. Add one sentence for each important relation:

The checkout API depends on the identity service.
The payment worker waits for a database connection.
The database responds to the worker's query.

These sentences reuse the pairings from lesson 014. They do not replace the movement sentences; they answer different questions. The path says where the command goes. The pairings say what a component needs, expects, or handles.

Keep the subject stable when you are describing one step. This is easier to follow:

The payment worker reads the command out of the queue.
The payment worker waits for a database connection.
The payment worker sends a query to the database.

Pronouns can make the trace shorter, but they can also hide the actor:

It reads it out of it and waits for it.

Repeat the technical noun when the reader might otherwise lose the path.

Step 3: Add the Response Path

A request trace is incomplete if it stops at the database. Describe the return direction with the same discipline:

The database sends the payment result to the worker.
The worker writes the result into the response topic.
The checkout API reads the result out of the topic and responds to the browser.

The result travels through a different logical object, but the sentence pattern stays familiar. To points at a destination, into marks entry into a stream, out of marks reading from it, and responds to names the request that triggered the response.

Compare two versions:

The API sends the result to the browser.       # direct return
The API responds to the checkout request.     # behavior toward a stimulus

Both can be true. Choose the first when the route matters and the second when the service behavior matters. If both facts matter, use two short sentences instead of forcing one sentence to carry every relation.

Step 4: Add the Failure Branch

Now change one condition: the database connection pool is exhausted. Do not rewrite the successful path from memory. Keep it as the baseline, then append the branch:

The payment worker waits for a database connection.
The worker reaches the timeout before a connection becomes available.
The service recovers from the timeout and retries the command.
The retry results in a second payment attempt.

The branch has an order: wait, timeout, recover, retry, consequence. Before and after can make the order explicit when the trace is read out of context:

The worker retries the command after the timeout.
The duplicate-payment check runs before the worker writes the result.

Do not call the retry safe unless the trace contains evidence for that claim. A precise path reports what the system did; it does not silently upgrade behavior into a guarantee.

A Complete Worked Trace

Here is the normal path and failure branch together:

The request moves from the browser through the edge proxy to the checkout API.
The checkout API depends on the identity service.
The API writes the payment command into the command queue.
The payment worker reads the command out of the queue and sends a query to the database.
The worker waits for a database connection when the pool is exhausted.
The database sends the payment result to the worker.
The worker writes the result into the response topic.
The checkout API reads the result out of the topic and responds to the browser.
If the worker reaches the timeout, the service recovers from the timeout and retries the command.
The retry results in a second payment attempt, so the duplicate-payment check runs before the next write.

The trace is deliberately repetitive. Repetition keeps the nouns visible and lets the prepositions carry one job each. A reader can now ask focused questions: where did the request enter, where did the command wait, what caused the retry, and what relation led to the second attempt?

A Five-Pass Practice Routine

Use the same routine with a system you know:

1. Inventory: write the components as nouns in path order.
2. Move: connect them with from, through, to, into, or out of.
3. Relate: add depends on, waits for, responds to, or recovers from only where the system needs that relation.
4. Branch: change one condition, such as a timeout or rejected request, and describe the next two actions with before or after.
5. Trim: remove any adjective that does not clarify a path, condition, or result.

For example, begin with browser -> edge -> API -> cache and produce:

The request moves from the browser through the edge to the API.
The API reads the session out of the cache and responds to the browser.
If the cache misses, the API waits for the database response before returning the session.

The nouns and path can change. The five passes remain stable.

Compare Two Descriptions of the Same Path

Good practice includes revision, not only first drafts. Compare a compressed description with an inspectable one:

Compressed: The checkout goes through the platform and returns a result.
Inspect-able: The request moves from the browser through the edge proxy to the checkout API. The API writes the command into the queue, and the worker reads it out of the queue before sending a query to the database.

The compressed version may be acceptable in a conversation where everyone already knows the architecture. It is weak in an incident ticket because the platform hides several components and returns a result hides the route. The longer version gives the reader nouns that can be matched against logs and metrics.

Now compare two precise versions that serve different purposes:

Path view: The request moves from the browser through the edge to the API, then into the queue.
Behavior view: The API depends on the identity service, waits for a token, and responds to the browser.

The path view is useful for locating a hop or boundary. The behavior view is useful for explaining why the API paused or answered. Neither is the universal “best” sentence. Choose the view that matches the question in the ticket or review.

You can combine the views when a handoff is risky:

The request moves through the edge to the API. The API waits for an identity token before writing the command into the queue.

The first sentence establishes location. The second explains a dependency and its order. Two short sentences are often easier to verify than one sentence with four clauses and several pronouns.

When you practice, underline the nouns and circle the prepositions. If a noun has no clear role, ask whether it is a source, boundary, destination, container, expected object, or consequence. If a preposition has no clear question, replace it with the pairing that names the relation. This turns editing into a small diagnostic routine rather than a feeling that the sentence “sounds technical.”

Keep the first draft deliberately plain. You can add latency, retries, or ownership after the path is correct. A vivid adjective cannot repair a missing destination, and a polished sentence cannot compensate for an unnamed queue or worker.

That order keeps practice focused and makes later edits easier to compare again.

Common Confusions While Tracing

through versus into

The request moves through the edge proxy. # crosses an intermediate boundary
The API writes the command into the queue. # enters a container or stream

to versus in

The worker sends the query to the database. # destination
The worker runs in the payment service.     # location

out of versus from

The worker reads the command out of the queue. # exits a container
The command comes from the checkout API.       # source

wait for versus depend on

The worker waits for a connection.       # temporary expectation
The worker depends on the database.      # structural prerequisite

Movement versus outcome

The result moves to the browser.         # route
The retry results in a second attempt.   # consequence

The path and the consequence can appear next to each other, but they answer different questions.

Trade-offs and Limits

The trade-off is readability versus compression. A long trace that repeats the worker and the queue is slower to type, but it is easier to debug than a compact paragraph full of it, this, and there. Compression becomes useful only after the path is established and the referents are obvious.

There is also a trade-off between route detail and operational detail. The request moves through the edge to the API is enough for a high-level map. A latency investigation may need The request waits for 200 ms at the edge before reaching the API. Add the timing, retry count, or boundary when it changes the decision; leave it out when it only makes the sentence heavier.

Prepositions cannot prove that the architecture is correct. They can make an incorrect path easier to inspect, which is already valuable. Pair every important claim with the log, metric, or design fact that supports it.

Active Check: Build the Missing Step

Check: Complete the path:

The request moves ___ the browser ___ the edge proxy ___ the checkout API.

Think first, then reveal.

Answer: from ... through ... to. The first noun is the source, the second is an intermediate boundary, and the third is the destination.

Check: The API publishes a command into a queue, and the worker reads it from the queue. Which pair is natural?

A. The API writes the command in the queue; the worker reads it from the queue.

B. The API writes the command into the queue; the worker reads it out of the queue.

C. The API writes the command to the queue; the worker reads it at the queue.

Think first, then reveal.

Answer: B. Into marks entry and out of marks removal from the queue.

Check: A database timeout causes a retry. Which sentence reports the consequence?

Answer: The timeout results in a retry. Result in introduces the outcome; result from would introduce the cause.

Transfer Challenge: Repair a Request Trace

An engineer writes:

The checkout is in the browser and goes in the edge.
The API works with the queue.
The worker is in the database and after this the payment is made.

Rewrite the trace in four or five short sentences. Show the source, intermediate boundary, destination, queue transition, and one dependency or waiting relation. Add one failure branch with a clear consequence.

Model answer:

The request moves from the browser through the edge proxy to the checkout API.
The API writes the payment command into the queue.
The worker reads the command out of the queue and sends a query to the database.
The worker waits for a database connection when the pool is exhausted.
The timeout results in a retry, so the duplicate-payment check runs before the next write.

Your components may differ. Check that every preposition answers a visible question and that the failure branch has an order and a consequence.

Daily Practice Lines

Repeat the normal path in three lines:

The request moves from the browser through the edge to the API.
The API writes the command into the queue.
The worker reads the command out of the queue.

For spaced review, add the operational branch:

The worker waits for a database connection, then recovers from the timeout and retries the command.

On another day, replace browser, queue, and database with components from your own system. Keep the preposition roles unchanged.

Resources

• [ARTICLE] Cambridge Dictionary Grammar - Reference for preposition complements and verb patterns.
• [ARTICLE] MDN HTTP Overview - Technical context for request and response paths.
• [ARTICLE] Microsoft Writing Style Guide - Guidance for concise, inspectable technical writing.

Key Takeaways

• Draw the component path before writing the sentence.
• Use from, through, to, into, and out of to label movement and boundaries.
• Add depend on, wait for, respond to, and recover from for service behavior.
• Use before, after, and result in to make failure order and consequence visible.
• Prefer a longer, repetitive trace when compression would hide the actor or relation.