API Request Lifecycle: an editable mindmap
Explore API Request Lifecycle as an editable mindmap. Follow color-coded branches for Find the service, Send request, Application, Return response, with supporting ideas and curved connections.
A mindmap of API Request Lifecycle, with the main ideas arranged around a central topic and connections that show how they relate.
API Request Lifecycle: an editable mindmap
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this mindmap
- Begin at “API Request Lifecycle” in the centre, then explore any branch that answers your question. The branch colors keep each group of ideas together.
- Curved lines show relationships; arrowheads appear only where one idea leads to another. Select any idea in the editor to change its text, position, or connections.
Find the service
This branch brings together “The first round trip is DNS — the domain is resolved to an IP address before a single request is sent. See How DNS Works for the full lookup chain.”, “A TCP connection is established”, “The encryption handshake negotiates keys before the HTTP request travels — see How HTTPS Works for what happens inside it.”.
Send request
This branch brings together “The HTTP request is sent”, “With several servers behind one address, the load balancer picks a healthy instance for each request and spreads traffic across them.”.
Application
This branch brings together “Handler validates and processes the request”, “Server queries the database”.
Return response
This branch brings together “Server serialises the response”, “Response travels back through the same path”, “Client parses and renders the response”.
Connections across the map
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.
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
Start at the central topic
Rename “API Request Lifecycle” if you want to adapt this map to a specific project or lesson.
Develop the branches
Edit the supporting ideas, then add examples and notes where a branch needs more detail.
Connect related ideas
Draw curved connections across branches; use an arrow only when the relationship has a direction.
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 mindmap in QueryChart
Open this mindmap as your own editable free canvas. Move ideas, add branches, and draw new connections.