Episode 12Rebuild the journey
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 articleBlog
12 articlesEpisode 11Survive the spike
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 articleEpisode 10Find the latency
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 articleEpisode 09Wait or queue?
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 articleEpisode 08Protect the last item
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 articleEpisode 07Find one row
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 articleEpisode 06Inside PostgreSQL
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 articleEpisode 05Concurrency, not magic
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 articleEpisode 04Inside Node
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 articleEpisode 03Choose a server
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 articleEpisode 02Secure the connection
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 articleEpisode 01Before the backend
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 articleNo articles match this filter yet.