The journey of a request

You tap the like button on a photo, and a tiny red heart appears next to it. Three things happen in the half-second between those two moments, and the entire rest of this course is downstream of understanding them.

The first is your device does some work. It recognized your tap as a tap (not a swipe, not a drag), figured out which button it landed on, and started a request. That request is, essentially, a politely worded note that says Hi, it is me, I would like to add a like to this specific photo, please.

The second is the note travels. Your phone hands the note off to your cellular tower or your Wi-Fi router, which hands it off to your internet service provider, which hands it off to a series of intermediate computers (each one passing it along), until it reaches a particular computer owned by whatever company runs that photo app. That computer is called a server. Your phone, in this story, is called a client. The whole back-and-forth is called a request on the way over and a response on the way back.

The third is the server does its own work. It opens the note, looks at who you are (Day 13), looks at which photo you wanted to like (Day 11), updates a record in a database that says Girish liked photo #481, and then sends a tiny note back saying Done.

Your phone gets the Done note. The heart turns red. You scroll on.

That is, in caricature, the journey of every interaction you have with an internet-connected app, ever.

Why this matters more than the diagrams suggest

When you can hold this journey in your head, three things become obvious that were murky before.

First, most of the time spent is not on your phone. When an app feels slow, the slow part is almost always the round trip (your note going out, the server thinking, the response coming back), not your phone itself. Day 14 will return to this when we talk about monitoring.

Second, the server is doing more than you think. Liking a photo sounds simple, but the server is also checking that you are allowed to like it, that the photo still exists, that you aren't a bot, and that the like should be counted in some trending algorithm somewhere. Day 9 will open the backend up and show you the rooms inside.

Third, anywhere on this journey can fail. Your phone, your cellular tower, the ISP, any of the intermediate computers, the server, the database. Each one can be slow or broken at any moment, and the app has to do something reasonable when that happens. Day 14 will come back to this too, because "doing something reasonable when a part of the journey breaks" is the whole job of monitoring.

A vocabulary sweep

Let's name the pieces of the journey so we share words for the next four lessons.

• Client. The local thing (Day 3), usually your phone or your browser, that starts the request.
• Server. The remote thing (Day 3), usually a computer in a data center, that processes the request.
• Request. The note going from client to server.
• Response. The note coming back from server to client.
• Endpoint. The specific door at the server that the request is knocking on. ("Like a photo" is one endpoint, "comment on a photo" is a different endpoint. See Day 10.)
• Database. Where the server keeps things that need to be remembered, like the fact that you liked photo #481. See Day 11.

When AI tools ask you to build an endpoint, or make a request, or talk to the API, they are pointing at pieces of this exact journey. Without the picture, those phrases sound like incantations. With the picture, they sound like English.

The smaller round trips happening at the same time

Modern apps run many of these journeys in parallel, and that is the source of about half of the weird "why is this app behaving this way" experiences you have on a daily basis.

When you open Instagram, your phone is starting maybe twenty separate journeys in the first second. One for the feed, one for your notifications, one for stories at the top, one for each image. They come back in different orders at different speeds, and the app has to render them as they arrive without going crazy. When the app appears to "load," what is really happening is a small storm of round trips resolving into a screen.

When you take a photo and share it, the upload is a journey. The "shared!" confirmation is the response. The pixels arriving in your followers' feeds are dozens of further journeys, one per phone.

The mental picture for an app is therefore not "one app talking to one server." It is "lots of small notes flying back and forth all the time." This becomes important on Day 12 when we talk about hosting, because the number of round trips per second is one of the main things that determines how much you will pay.

A two-minute exercise

Pick an app you used today (Twitter, Spotify, Slack, anything). Pick one specific action you did in it (liked, sent, played, scrolled).

Try to narrate the journey out loud: I tapped, my phone sent a note that said X, it went over Wi-Fi to the server at the company, which did Y, and sent back Z, which my phone showed by W.

You do not need to be accurate about the company's internal architecture. You need to feel the shape of the journey. If you can feel it for three different actions across three different apps, you have Day 4 in your bones.

Forward references

Day 5 takes a small detour to ask why there are 100+ programming languages and gives you a confident answer to "which one should I use?" that isn't "it depends." Day 8 zooms in on the client end of the journey. Day 9 zooms in on the server. By Day 11 you will know exactly where the liked photo #481 fact lives.

Day 4 wrap

The thing you can now say plainly. When you interact with an internet-connected app, your phone sends a small note to a server, the server does some work, and a response comes back. That round trip is called a request, and it happens dozens of times per second on a healthy app.

The thing you can now do. Narrate the journey of one specific interaction (a like, a message sent, a song played) from tap to result, naming the pieces along the way.

The guardrail to remember. The slow part is almost never your phone. When something feels off, suspect the journey first.

See you on Day 5, where we finally answer the question every AI tool asks first.