API Request Lifecycle — every hop a request makes

API Request Lifecycle — every hop a request makes

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Read the "Before the request" column first: DNS, TCP, TLS — the three round trips that happen before any HTTP is sent.
• Then follow the request into "Server processing": load balancer, handler, database, serialisation.
• Read the "Response" column as the mirror image — the response retraces the same path back to the client.

Before the request

"Browser resolves the domain via DNS" is the first round trip — the domain becomes an IP address (the subject of the DNS visual). "A TCP connection is established" opens the reliable byte pipe, and "TLS handshake secures the connection" encrypts it (the subject of the HTTPS visual). Only then does "The HTTP request is sent". These three opening boxes are why a cold API call is visibly slower than a warm one.

Server processing

"Load balancer routes to an application server" distributes the request across healthy instances. "Handler validates and processes the request" is where the application's code runs, "Server queries the database" is the data hop — usually the slowest — and "Server serialises the response" is the return formatting. The lane split keeps the network edge, the application and the data store visibly separate, because they have different failure modes and different latency budgets.

The response path

"Response travels back through the same path" and "Client parses and renders the response" close the loop. The response does not magically return — it crosses the same load balancer, network and connection that carried the request. Understanding that the path is shared is what explains why request timeouts and response timeouts are the same problem, and why the two columns mirror each other.

Key relationships and takeaways

• DNS, TCP and TLS precede the HTTP request — three round trips before any application code runs.
• The load balancer makes many servers look like one address; the client never sees the real server.
• The database query is the slowest hop in most API calls, which is why caching and indexing matter.
• The response retraces the request's path — both directions cross the same network and load balancer.
• The lifecycle composes the other visuals: DNS, HTTPS and REST are all stages of this one journey.

When to use this visual

• Teaching a new engineer why API latency is more than server code — the network and setup stages are real.
• Debugging slowness: the canvas names the hops to measure — DNS time, TTFB, server time, transfer time.
• Grounding a conversation about load balancing and caching in where each sits in the journey.

How it works

1. Map your real infrastructure

   Replace the generic load balancer, application server and database with your actual components — your CDN, your instances, your data store — keeping one box per hop.

2. Annotate the latency budget

   Add a comment to each hop recording its typical time in your system — DNS lookup, connection, TLS, server time, database — so the canvas becomes a latency profile.

3. Add the caching layer

   Insert a cache box between the load balancer and the handler, with a branch for cache hit versus miss, since that is the lever most teams pull first.

4. Draw the failure branches

   Add the real failure endpoints — a DNS timeout, a TLS error, a 502 from the load balancer, a database outage — each ending in an explicit outcome.

Frequently asked questions

What are the stages of an API request?

Before any HTTP is sent, the client resolves the domain via DNS, opens a TCP connection, and performs a TLS handshake. Then the request travels to a load balancer, which routes it to an application server; the server validates and processes it, queries the database, and serialises a response; and the response returns through the same path. The visual's three columns are exactly those three groups of stages.

Why is an API call slow before the server does anything?

Because DNS resolution, the TCP connection and the TLS handshake are all real round trips that happen before a single byte of HTTP is sent. On a cold connection they can take longer than the actual request processing. That is why the visual opens with the "Before the request" column — most of a first-request's latency is setup, not server code.

What is the role of the load balancer in the request lifecycle?

The load balancer is the stable front door behind which the actual servers live. It accepts the request, picks a healthy instance, and forwards the traffic, and it is also where health checks and TLS often terminate. Clients never know which server handled them, which is what lets servers be added and removed without changing the client.

Why does the response take the same path back?

Because the connection is the path: the response travels over the same TCP/TLS connection, through the same network and load balancer, that carried the request. The symmetry matters operationally — a slow or broken hop affects both directions, which is why the visual draws the response column as the mirror of the request column rather than assuming the return trip is free.

Edit this visual in QueryChart (FlowJam)

Open this exact lifecycle canvas as your own chart, rename the hops to your infrastructure, and trace your real requests.

Edit this visual in QueryChart (FlowJam)