Master System Design 🚀 | HTTP Isn’t as Scary as It Sounds

Aishu Reddy

5 min read

·

Aug 7, 2026

--

Listen

Share

Press enter or click to view image in full size

Welcome back! ☕
I hope your coffee is finished and your brain has successfully replicated the knowledge from the last blog. Time to allocate a little more memory — we’ve got another system design concept to unpack!

Understanding HTTP Without Losing Your Mind 🌐

Now that we’ve established a connection with the server, the next question is…

How do the browser and the server actually talk to each other?

The answer is HTTP.

Sounds complicated?

Don’t worry.

It’s one of those terms that sounds scary until you understand it.

What is HTTP?

HTTP stands for HyperText Transfer Protocol.

Let’s ignore the fancy name for a second.

The important word here is Protocol.

A protocol is simply a set of rules.

Think of it like the rules of a cricket match.

Everyone follows the same rules, so the game works smoothly.

Similarly, HTTP defines how a browser and a server should communicate.

That’s it.

Nothing magical. 😄

The browser sends a request.

The server processes it.

The server sends back a response.

All while following HTTP’s rules.

Easy, right?

HTTP Methods

Now imagine you’re talking to a waiter in a restaurant.

Depending on what you want, you ask differently.

HTTP works the same way.

Different requests use different HTTP Methods.

Let’s look at the most common ones.

GET

As the name suggests…

It gets information from the server.

Example:

“Show me my YouTube homepage.”

No data is modified.

You’re simply asking the server to send something back.

POST

POST is used to create a new resource.

Think of it as saying:

“Here’s some new information. Please save it.”

Examples:

• Creating a new account
• Posting a comment
• Uploading a photo
• Placing an order

Behind the scenes, this often creates a new database row, but that’s just one possible implementation.

PUT

PUT is generally used to replace an existing resource.

Imagine editing your profile.

Instead of changing just one field, you send the complete updated profile.

The server replaces the old version with the new one.

PATCH

PATCH is used to update only part of a resource.

Suppose your profile looks like this:

Name: John
Age: 24
City: Bangalore

You only want to update your city.

With PATCH, you send only:

City: Hyderabad

Everything else remains unchanged.

Think of PATCH as saying:

“Only change this part.”

DELETE

Just like the name says…

DELETE removes a resource.

For example:

• Delete a comment
• Delete a user account
• Delete a product

Simple enough. 😄

Where Does the Data Go?

For methods like POST, PUT, and PATCH, the information you’re sending is usually placed in the Request Body.

For example:

{
  "name": "Aishu",
  "city": "Bangalore"
}

The server reads this data and performs the requested action.

HTTP Status Codes

After processing your request, the server replies with a Status Code.

Think of it as the server’s way of saying:

“Here’s what happened.”

Let’s look at the major categories.

2XX — Success 🎉

These mean everything worked perfectly.

Some common ones are:

200 OK

Everything went successfully.

201 Created

A new resource was successfully created.

Usually returned after a successful POST request.

202 Accepted

The server accepted the request but will process it later.

For example, processing a large video upload.

204 No Content

The request was successful, but there’s nothing to return.

3XX — Redirection ↪️

These status codes tell the browser:

“The page you’re looking for isn’t here anymore. Please go to this other URL instead.”

Instead of giving the requested page, the server provides a different location. The browser receives the new URL and automatically opens it.

Example:

301 Moved Permanently

The resource has permanently moved to another URL.

302 Found

The resource has temporarily moved.

You won’t see these very often while developing APIs, but browsers encounter them frequently.

4XX — Client Errors 🙈

These errors usually mean the request sent by the client has a problem.

Some common ones:

400 Bad Request

The request is invalid.

Maybe required data is missing.

401 Unauthorized

Authentication is required or the credentials are invalid.

403 Forbidden

The server knows who you are…

But you’re not allowed to access the resource.

It’s like reaching a VIP room with a regular ticket.

404 Not Found

The requested resource doesn’t exist.

Probably the most famous error on the internet. 😂

429 Too Many Requests

You’re sending requests too quickly.

The server asks you to slow down.

5XX — Server Errors 💥

These errors mean the server failed while processing a valid request.

Some common ones:

500 Internal Server Error

Something unexpected went wrong inside the server.

The client isn’t at fault.

503 Service Unavailable

The server is temporarily unavailable.

Maybe it’s under maintenance or overloaded with traffic.

HTTP Headers

Along with every request and response, some extra information is also exchanged.

This information is stored inside Headers.

Think of headers as the label on a courier package.

The label isn’t the actual gift.

It simply provides useful information about it.

Request Headers

The browser sends headers like:

Cookie

Used to identify the user’s session or store other browser-related information.

Authorization

Contains tokens like JWT or OAuth tokens used for authentication.

User-Agent

Tells the server which browser or application is making the request.

For example:

• Chrome
• Firefox
• Safari
• ChatGPT
• Postman

There are many more headers, but these are the most commonly used.

Response Headers

The server also sends headers.

One important header is:

Content-Type

It tells the browser what kind of data is being returned.

Examples:

application/json

text/html

image/png

Without this header, the browser wouldn’t know how to interpret the response.

Is HTTP Stateful?

Here’s a question interviewers love to ask.

Is HTTP Stateful or Stateless?

The answer is:

HTTP is Stateless.

What does that mean?

It means the server doesn’t automatically remember previous requests.

Imagine you walk into a coffee shop every morning.

Each day, the cashier treats you like a new customer unless you show something — like a loyalty card.

HTTP works the same way.

Every request is independent.

The server doesn’t remember:

• Who you are
• What you did five seconds ago
• Which page you visited previously

Each request must contain enough information to be understood on its own.

That’s why browsers send cookies or authentication tokens with every request.

Is Being Stateless a Bad Thing?

Actually…

It’s one of HTTP’s biggest strengths.

Imagine you have 10 servers behind a Load Balancer.

If Server 1 remembered your previous request, then every future request would have to go back to Server 1.

That would make scaling difficult.

Because HTTP is stateless, any server can handle any request, as long as the request includes the necessary information (like cookies or tokens).

This makes systems much easier to scale.

We’ll dive deeper into this when we discuss Load Balancers and Distributed Systems.

That’s HTTP in One Sentence

HTTP is simply a communication protocol that defines how clients and servers exchange requests and responses. It provides standard methods (GET, POST, PUT, PATCH, DELETE), status codes, headers, and a stateless communication model that allows modern web applications to scale efficiently.

See?

Not so scary after all. 😄

In the next article, we’ll continue this journey by breaking down another concept in the simplest way possible.

Until then… stay curious, keep coding, and don’t let the acronyms scare you. They’re usually much simpler than they sound. 😉🚀