Series 01
One Request, End to End
You click Submit or Place Order, and a second later the screen tells you it worked. A lot happened in that second. The request left your device, passed through your router and ISP, crossed the wider internet, reached the application, talked to the database and any other services it needed, then made the whole trip back with a response. This series follows that journey, one part at a time.
- 01
You clicked Place Order. What happens before my backend sees it?
Before your backend can process an order, the browser has to find the service, open a connection, secure it, and get through the edge.
Read episode - 02
Why HTTPS needs work before your request even starts
Before the browser sends a secure request, it has to verify the server, agree on keys, and work out which connection it can reuse.
Read episode - 03
Your request reached us. Which server gets it?
The public endpoint is the front door. Load balancers, proxies, health checks, and routing rules still have to choose an application server.
Read episode - 04
What actually happens when Node receives the request?
Your controller is near the end of the path. The operating system, Node's HTTP parser, middleware, and router all see the request first.
Read episode - 05
Node is single-threaded. So how is it handling thousands of requests?
Node handles many requests by keeping the JavaScript thread free while the operating system and supporting workers handle most of the waiting.
Read episode - 06
The API needs your order. What happens inside PostgreSQL?
One line of SQL hides a connection pool, a query plan, memory pages, MVCC rules, storage work, and a result that still has to come back.
Read episode - 07
How did PostgreSQL find one row among millions without scanning everything?
A B-tree index helps PostgreSQL narrow millions of rows to a few candidates, as long as the index actually matches the query.
Read episode - 08
Two people try to buy the last item
Two buyers see one item in stock. We need one safe place to decide who gets it and stop the other order.
Read episode - 09
The payment provider takes four seconds. Should our request wait?
A four-second payment call forces us to choose: keep the request open, or return a pending order and finish the work in the background.
Read episode - 10
The request took 1.8 seconds. Where did the time go?
The request took 1.8 seconds. Traces, metrics, and logs help us see how much time each part of the system used.
Read episode - 11
What changes when 10,000 users place orders at once?
A traffic spike fills queues, exhausts connection pools, hits hot rows, and turns careless retries into even more traffic.
Read episode - 12
Rebuilding the whole request end to end
We put the full request back together, from the browser and network to Node, PostgreSQL, payments, queues, and the final response.
Read episode