One Click, A Full Stack Journey: Tracing an HTTP Request from Browser to Database

Introduction: One Click, A Full Lap in the Backend

I'm Little H, a newly born HTTP request. My task is simple: retrieve order 9527. The browser pats my shoulder: "Go, come back with the result." I thought the database was next door. Instead, I face a queue of gateway, business services, RPC, cache, and a fleet of drivers called Socket .

This story uses HTTPS + HTTP/1.1 , gRPC , Redis , and MySQL to illustrate a common architecture; HTTP/3 over QUIC is a different route.

PART 01: Departure – DNS and Communication Endpoints

The task slip reads GET /orders/9527. The browser checks DNS cache; if no record, it runs the resolution process to obtain an entry IP. This address may point to a load balancer or reverse proxy, not necessarily the business server .

"Know the address, go straight there?" I ask. The OS hands me a ticket: "First find Socket ." A Socket is the program's interface to communication capabilities. The application creates it, gets a file descriptor — the process-internal number for operating this communication endpoint. ( Linux Socket documentation )

If no reusable connection exists, the client initiates a TCP connection, completing the three-way handshake ; then a TLS handshake verifies the server certificate and negotiates encryption parameters. HTTP messages are sent over this encrypted connection. With an available connection, re-handshaking is avoided. ( TLS standard )

I realize: HTTP defines how to express business, TCP transports bytes, Socket is the program's entry point to the communication endpoint.

PART 02: Transport – Byte Stream and Messages

HTTP messages are TLS-encrypted and handed to the Socket's send path . The kernel's TCP/IP stack segments and encapsulates; the NIC pushes data into the network; routers forward hop by hop. At the home router, NAT address translation may occur.

"Driver, guarantee I arrive whole!"

TCP shakes its head: "I provide an ordered byte stream , not preserving your write boundaries." One write may be read in several chunks; multiple writes may arrive in one read. Sequence numbers, acknowledgments, and retransmissions handle loss and reordering. ( TCP documentation )

Therefore, the receiver cannot treat a single recv() as a complete request . HTTP/1.1 must use message structure, Content-Length, or chunked encoding to determine where a message ends. ( HTTP/1.1 standard )

A secret: send() success only means the local send operation accepted the bytes; it does not prove the peer's business logic has processed them. "Handed to the courier" vs "recipient signed and completed" — there's still a journey between. ( send documentation )

PART 03: Arrival – Reception and Forwarding

The server typically creates a Socket, bind() s to an address and port, then listen(). When a new connection arrives, accept() returns a connected Socket ; the original listening Socket continues accepting others. ( accept documentation )

"One port , how to serve so many?"

The doorman explains: within the same TCP scope, connections are distinguished by the four-tuple — source IP, source port, destination IP, destination port. Same server port does not mean same connection.

Linux can use epoll to monitor readiness events on many Sockets , combined with non-blocking I/O to handle connections without a thread per connection. Readiness means you can continue operating; a complete business message still requires your own judgment. ( epoll documentation )

When actually receiving, data passes through the NIC and kernel stack into the connection's receive buffer ; the application reads bytes, then performs TLS decryption and HTTP parsing. Between data arriving at the machine and business code reading a complete request, there are these handovers.

Here, Nginx terminates external TLS , parses the request, and forwards via a new or reused upstream connection to the Web/API service. Whether the upstream is encrypted depends on configuration. ( Nginx proxy documentation )

First travel lesson: Reverse proxy has different connections on both sides — the browser's Socket does not tunnel all the way to the database.

PART 04: RPC – Service Handoff

The Web service completes identity verification , decides to call the order service's GetOrder(9527).

"How did I suddenly become RPC ?"

The dispatcher explains: "Your business need triggered a new downstream call . The framework encodes method name, parameters, and call context, sends to the order service, which parses and executes the handler." RPC wraps remote calls like local methods, but network round-trips remain. ( gRPC core concepts )

This example uses gRPC : messages are usually Protobuf-encoded, transported over HTTP/2 . Thus HTTP and RPC are not mutually exclusive; RPC describes the call style, implementation can leverage HTTP.

Existing gRPC Channel should be reused. The underlying connection can carry multiple HTTP/2 streams, avoiding a new TCP connection per method call. A Channel is not an alias for a single Socket ; it may manage multiple connections. ( gRPC performance guide )

I finally understand: The business goal runs through the whole journey; each segment transports data organized by different protocols.

PART 05: Cache – Remote Cache Access

The order service checks cache first, preparing to send GET order:9527. The Redis client encodes commands as RESP data and sends via its managed connections. ( Redis protocol documentation )

Note: this is a communication from order service to Redis . Redis does not ride the browser's connection back, nor does it automatically know the prior HTTP request's shape.

Clients can use connection pools to reuse connections, or multiplexing to manage communication. Co-located deployments may use Unix Domain Sockets; remote caches usually require cross-machine transport. ( Redis connection management )

I peek: "All in memory, why still slow?" Redis points outside: " Network round-trip and queuing also take time." One cache access includes encoding, transmission, scheduling, decoding. Sending many commands consecutively? Consider batch operations or Pipeline to reduce round-trips, but watch for command dependencies. ( Redis Pipeline )

Today cache misses. Redis shrugs: "Miss, next stop."

PART 06: Database – Connection Pool and Query

The order service borrows a connection from the database connection pool . If idle connections exist, reuse; if pool limit reached and all busy, the call may wait or time out, per pool policy.

With a connection, the database driver encodes the query per MySQL protocol and sends via Socket . New connections need MySQL protocol handshake and authentication; reused connections skip that repeated overhead. ( MySQL connection phase )

The clerk takes the query: "I parse SQL, generate execution plan, then read data per plan."

I stare at the disk: "Finally hitting the disk?" "Not necessarily." InnoDB has its own Buffer Pool . Needed data pages already in memory? Direct access. Page miss? Then read storage. Redis miss ≠ database physical disk read. ( InnoDB Buffer Pool )

Results return via database protocol; driver decodes to application-usable data. Slow queries may wait for connections, lock contention, execution plan, storage reads, or transmitting large result sets. Socket only handles the communication segment.

PART 07: Return – Layered Response

The order service receives database results, per cache strategy writes back to Redis with appropriate TTL. Next query hitting cache skips database access ; handling updates and cache consistency requires separate design.

Then the order service returns RPC response; Web service assembles HTTP response; Nginx passes to browser. This follows the service call chain layer by layer — not implying network packets traverse the exact same physical route back.

Screen shows: "Order shipped."

I want the driver to clock out, but the connection pool waves: "More orders coming." One request ends; connections may stay for reuse; returning a pool connection usually doesn't mean immediately closing the underlying Socket.

PART 08: Observability – Latency and Timeouts

User watches spinner: "Little H, slacking?" I pull out the itemized bill: DNS, connection + TLS, proxy processing, RPC, cache, database, plus queueing time at each hop — all affect final latency.

Troubleshooting: break latency per hop. Can't connect? Connected but no data? Waiting for DB connection or SQL executing? Is Redis slow, or request hasn't reached it?

Must budget timeouts . Entry willing to wait 1 second; downstream queues for seconds — even if result found, user may already see failure. RPC Deadline limits call wait time, but cancellation doesn't mean all downstream ops stopped. ( gRPC Deadline guide )

For writes, timeout ≠ failure: server may have committed, response just lost. Immediate retry risks duplicate writes; need idempotency design to decide.

Thus, a truly useful travel log correlates all segments of one business via distributed tracing , pinpoints where time went, then optimizes network, connection pools, or business logic.

LAST: Conclusion – One Click, A Full Relay

Browser sends HTTP , entry routes to Web service, Web initiates RPC, order service queries Redis, on miss queries MySQL, results return layer by layer.

HTTP , gRPC , RESP , MySQL protocol — each has its own message rules; Socket connects programs to communication capability; connection pools keep established channels working.