Imagine sending a stack of letters to a friend without any order or envelopes. Some letters might get lost, arrive out of order, or be duplicated. You’d struggle to understand the message, right?

This is what happens in computer networks without TCP. Data packets might:

• Arrive late or out of order

• Be duplicated or missing

• Be corrupted during transmission

Clearly, we need a system to organize, check, and confirm delivery. That’s where TCP comes in.

What Is TCP and Why Is It Needed?

TCP (Transmission Control Protocol) is a communication protocol used by computers to send data reliably over networks.

It ensures:

• Data arrives complete

• Data arrives in order

• Lost packets are detected and retransmitted

Think of TCP as a postal service for the internet—it guarantees that every “letter” (data packet) reaches its destination correctly.

Problems TCP Is Designed to Solve

TCP solves several problems that can occur in network communication:

• Packet loss: Lost packets are retransmitted.

• Out-of-order delivery: TCP reorders packets correctly.

• Data corruption: TCP checks for errors using checksums.

• Duplication: Duplicate packets are ignored.

Without TCP, applications like web browsing, email, and file transfers would be unreliable.

The TCP 3-Way Handshake: Making a Connection

Before sending data, TCP establishes a connection using a 3-way handshake.

Think of it as a conversation between two people who haven’t met before:

• Alice says: “Hi, I want to talk!”

• Bob replies: “Hi Alice, I’m ready. Are you sure?”

• Alice confirms: “Yes, I’m ready too. Let’s start talking.”

In TCP terms, these steps are: SYN → SYN-ACK → ACK.

Step 1: SYN (Synchronize)

• The client wants to start a connection.

• It sends a SYN packet to the server.

• SYN includes a sequence number, which is like a starting point for numbering the data.

Analogy: Alice saying, “Hi, let’s start a conversation. I’m starting at point #100.”

Step 2: SYN-ACK (Synchronize & Acknowledge)

• The server receives the SYN and responds with SYN-ACK.

• This packet:

  • Acknowledges the client’s SYN

  • Sends its own sequence number for the server

Analogy: Bob replies, “Hi Alice! I got your message. I’m starting at point #500. Are you ready?”

Step 3: ACK (Acknowledgement)

• The client receives the SYN-ACK and sends ACK.

• The connection is now established, and both sides are synchronized.

How Data Transfer Works in TCP

Once the connection is established:

• Data is broken into packets.

• Each packet gets a sequence number.

• The receiver sends an acknowledgement (ACK) for received packets.

• Lost packets are retransmitted.

For example:

TCP ensures that the data arrives completely and in the correct order, even if the network drops or delays some packets.

How TCP Ensures Reliability, Order, and Correctness 🛠️

• Reliability: ACKs confirm every packet is received. Lost packets are resent.

• Order: Sequence numbers allow the receiver to reassemble packets in the correct order.

• Error checking: Checksums detect corrupted packets; corrupted packets are discarded and retransmitted.

Analogy: It’s like a delivery company that tracks every package, re-sends missing ones, and ensures nothing arrives broken.

Closing a TCP Connection: FIN & ACK

When the conversation is over, TCP closes the connection gracefully. It closes the connection carefully to make sure:

• All data is delivered

• Nothing is cut off midway

This process uses FIN and ACK. Think of it like politely ending a phone call.

Step 1: FIN (Finish)

One side says:

“I’m done sending data.”

It sends a FIN packet.

Analogy:
Alice says, “I’ve finished talking.”

Step 2: ACK

The other side replies:

“Okay, I heard you.”

It sends an ACK.

Analogy:
Bob says, “Got it.”

Step 3: FIN (From the Other Side)

Now the second side also sends:

“I’m done too.”

Another FIN is sent.

Step 4: Final ACK

The first side replies with a final ACK.

Connection is now fully closed.

TCP Connection Lifecycle

Flow: Establish → Transfer Data → Close

TCP always opens and closes connections properly.

How Data Transfer Works in TCP

After the 3-way handshake:

• Data is broken into small pieces (segments)

• Each segment gets a sequence number

• The receiver sends back ACK numbers

• Missing segments are retransmitted

Let’s understand this slowly.

Sequence Numbers

Every byte of data is numbered.

Example:

If you send:

HELLO

It might be numbered like:

H = 1
E = 2
L = 3
L = 4
O = 5

If packets arrive out of order:

3, 4, 1, 2, 5

The receiver reorders them correctly using sequence numbers.

Acknowledgements (ACK)

After receiving data, the receiver says:

“I have received up to number X.”

Example:

If bytes 1–100 arrived safely, the receiver sends:

ACK = 101

Meaning:

“I’m expecting byte 101 next.”

This makes communication organized.

What Happens If a Packet Is Lost?

Let’s say:

Packet 2 is lost.

Receiver gets:

1 → OK
3 → Wait… where is 2?

It does not acknowledge beyond the missing packet.

The sender realizes:

“No ACK for packet 2? I must resend it.”

That’s retransmission.

Packet Loss & Retransmission Flow

TCP constantly checks:

• Was it received?

• Was it acknowledged?

• Was it corrupted?

If is fails, resend.

How TCP Ensures Reliability, Order, and Correctness

Let’s summarize it clearly.

Reliability

Every packet must be acknowledged.
If no ACK → resend.

Order

Sequence numbers allow proper reassembly.

Even if packets arrive as:
3, 1, 2

They are rearranged into:
1, 2, 3

Error Detection

Each segment has a checksum.

If data is corrupted:

• It is discarded

• Sender retransmits

The TCP 3-Way Handshake

Step-by-step summary:

1. Client → SYN

2. Server → SYN-ACK

3. Client → ACK

Now both sides:

• Agree to communicate

• Agree on starting sequence numbers

• Are synchronized

Why TCP Is Needed

Without TCP:

• Web pages could load incorrectly

• Files could be corrupted

• Emails might arrive incomplete

• Data could be jumbled

TCP ensures:

• Complete delivery

• Correct order

• Error detection

• Controlled communication

Imagine you are at a big party, and you want to talk to someone.

• Do you shout randomly?

• Do you point to one person?

• Or do you gather a specific group to speak to them?

CSS selectors work the same way. They help you “target” exactly which HTML elements you want to style.

Without selectors, styling every element would be chaotic. You’d be applying styles blindly, which is inefficient and messy. Selectors are the foundation of CSS ,they allow your styles to be precise, organized, and reusable.

Element Selector: The Basic Target

The simplest selector is the element selector. It targets all instances of a specific HTML element.

Example:

<p>This is a paragraph.</p>
<p>This is another paragraph.</p>

CSS:

p {
  color: blue;
}

Result: All <p> elements turn blue.

Analogy: You’re calling everyone named “paragraph” at the party.

Class Selector: Target a Group

Sometimes, you want to style only a specific group, not every element of a type. That’s where classes come in.

HTML:

<p class="highlight">Important paragraph</p>
<p>Regular paragraph</p>

CSS:

.highlight {
  background-color: yellow;
}

Result: Only the paragraph with class="highlight" gets a yellow background.

Analogy: Imagine wearing a badge only people with the badge get your attention. Classes allow you to group elements for targeted styling.

ID Selector: Target One Unique Element

When you need to target a single, unique element, use an ID selector.

HTML:

<p id="main-heading">Welcome!</p>
<p>Subheading</p>

CSS:

#main-heading {
  font-size: 2rem;
  color: red;
}

Result: Only the element with id="main-heading" is styled.

Analogy: This is like calling a specific person by name—you know exactly who should respond.

Group Selectors: Target Multiple Types Together

What if you want to style multiple different elements the same way? You can group them using commas.

HTML:

h1>Heading</h1>
h2>Subheading</h2>
p>Paragraph</p>

CSS:

h1, h2, p {
  font-family: Arial, sans-serif;
}

Result: All headings and paragraphs use the same font.

Analogy: You’re sending a message to multiple people at once.

Descendant Selectors: Target Elements Inside Others

Sometimes you don’t want to style an element everywhere, only inside another element. That’s where descendant selectors come in.

HTML:

<div class="card">
  <p>Card content</p>
</div>

<p>Outside content</p>

CSS:

.card p {
  color: green;
}

Result: Only the paragraph inside the .card div turns green.

Analogy: You’re talking only to people sitting at a specific table, ignoring the rest.

Basic Selector Priority

Sometimes, more than one selector targets the same element.

Example:

<p id="intro" class="highlight">Hello World</p>

p {
  color: blue;
}

.highlight {
  color: green;
}

#intro {
  color: red;
}

Which color will it be? Red, Why? Because ID selectors have higher priority than class selectors, and class selectors have higher priority than element selectors.

Very simple rule (for beginners):

ID  >  Class  >  Element

Think of it like importance levels:

• Calling someone by full name (ID)

• Calling a group with badges (Class)

• Calling everyone by general category (Element)

You don’t need to memorize deep specificity rules yet, just remember this basic order.

Before & After Example

HTML

<div class="card">
  <h2 id="title">Welcome</h2>
  <p class="highlight">Important message</p>
  <p>Regular message</p>
</div>

CSS

p {
  color: black;
}

.highlight {
  color: orange;
}

#title {
  color: blue;
}

.card p {
  font-style: italic;
}

What Happens?

• All paragraphs are black by default

• .highlight paragraph becomes orange

• #title becomes blue

• Paragraphs inside .card become italic

This shows how selectors can:

• Target broadly

• Target groups

• Target specific elements

• Target elements inside other elements

Selectors give you control.

Selector Targeting Flow

You can imagine it like this:

1. CSS looks at your selector

2. It scans the HTML

3. It finds matching elements

4. It applies styles

Class vs ID

Some basic rules to follow are

Use Class When:

• You want to style multiple elements

• You want reusable styles

• You’re designing components

Use ID When:

• The element is unique

• It appears only once on the page

• You need a specific target

In modern development, classes are used far more often than IDs for styling.

IDs are typically used for:

• Unique sections

• JavaScript hooks

• Page anchors

Reinforcing the Core Idea

CSS selectors are not just a feature of CSS. They are the foundation of CSS.

Without selectors:

• You can’t choose elements

• You can’t control styling scope

• You can’t structure your design system

Selectors allow:

• Precision

• Reusability

• Clean organization

Clean Summary for Your Blog Ending

CSS selectors are ways to choose elements.

They allow you to:

• Target all elements of a type (Element selector)

• Target a group (Class selector)

• Target a unique element (ID selector)

• Target multiple elements together (Group selector)

• Target elements inside others (Descendant selector)

And when conflicts happen:

ID > Class > Element

You open your browser, type a website address, and press Enter. Within a fraction of a second, text appears, images load, and the page feels alive. Most of us stop thinking at that point the browser did its job. But behind the scenes, something much more interesting happen actually.
Your browser didn’t simply open a website. It performed a carefully coordinated series of steps involving networking, parsing, building structures, applying styles, calculating layouts, and finally painting pixels on your screen.

Let’s walk through this journey together slowly, visually, and without drowning in technical terminology.

What Is a Browser in real?

At a basic level, a browser is a software application that understands web languages and turns them into interactive pages.

Those languages are mainly:

• HTML for structure

• CSS for styling

• JavaScript for behavior

You can think of the browser as a translator and builder combined. It takes text-based instructions written by developers and converts them into something humans can see and use.

Instead of seeing the browser as a single tool, it’s better to imagine it as a team of specialized components working together.

The Big Picture: Main Parts of a Browser

Before diving deeper, let’s zoom out.

A browser is made up of several major parts:

• User Interface

• Browser Engine

• Rendering Engine

• Networking

• JavaScript Engine

• Data Storage

You don’t need to memorize this list. The goal is simply to understand that each part has a specific job, and no single component does everything.

The User Interface: Where You Interact

This is the most familiar part of the browser.

It includes:

• The address bar

• Tabs

• Navigation buttons

• Menus and settings

The User Interface is how you communicate with the browser. When you type a URL and press Enter, the interface hands that request to the browser’s internal systems and steps aside.

From this point on, the heavy lifting happens behind the scenes.

Browser Engine vs Rendering Engine

These two terms often confuse beginners, so let’s keep it simple.

• The Browser Engine acts as a coordinator. It connects the user interface with the rendering process and manages the overall flow.

• The Rendering Engine is responsible for turning code into visuals. It reads HTML and CSS and decides what should appear on the screen.

Different browsers use different rendering engines:

• Chrome and Edge use Chromium

• Firefox uses Gecko

Networking: Fetching the Website from the Internet

Once you press Enter, the browser doesn’t magically have the page. It has to request it from somewhere else.

The networking layer handles this process:

• It figures out where the website is located

• Sends a request over the internet

• Receives the response

That response usually contains:

• An HTML file

• Links to CSS files

• References to JavaScript files

• Images and fonts

You can imagine this like ordering furniture online. The browser doesn’t build anything until the materials arrive.

Parsing: How Browsers Understand Code

Before anything can be displayed, the browser needs to understand the files it receives.

This process is called parsing.

Parsing means breaking information into smaller pieces and analyzing how those pieces fit together.

A Simple Parsing Example

Consider this expression:

3 + 5 × 2

To understand it correctly, you don’t just read it left to right. You recognize structure and rules. Multiplication happens before addition.

Browsers do something similar when reading HTML and CSS.

HTML Parsing and DOM Creation

When the browser receives HTML, it starts reading it from top to bottom.

As it parses the HTML, it builds a structure called the DOM (Document Object Model).

The DOM is best imagined as a tree:

• The <html> element is the root

• Inside it are <head> and <body>

• Inside the body are headings, paragraphs, images, buttons, and more

Each element becomes a node in this tree.

This structure allows the browser to:

• Understand the relationships between elements

• Modify content dynamically

• Respond to JavaScript interactions

The DOM is not the page itself—it’s the browser’s internal representation of the page.

CSS Parsing and CSSOM Creation

HTML defines what exists. CSS defines how it looks.

When the browser encounters CSS, it parses it and builds another structure called the CSSOM (CSS Object Model).

If the DOM is a tree of elements, the CSSOM is a tree of styling rules.

For example:

p {
  color: blue;
  font-size: 18px;
}

The browser reads this and understands:

• Target: all <p> elements

• Style rules: blue text, 18px font size

Just like HTML becomes a DOM tree, CSS becomes a structured tree of styling instructions.

DOM + CSSOM → The Render Tree

Now comes the magic moment.

The browser takes:

• The DOM (structure)

• The CSSOM (styles)

And combines them into something called the:

Render Tree

Think of it like this:

• DOM = The skeleton of a house

• CSSOM = The paint, colors, decoration rules

• Render Tree = The final decorated blueprint ready to build

Important detail:

The Render Tree only includes visible elements.

If something has:

display: none;

It exists in the DOM, but it does not appear in the Render Tree.

Visual Flow So Far

Flow: HTML → DOM , CSS → CSSOM , DOM + CSSOM → Render Tree

Layout: Calculating Positions

Now the browser knows: What to display and how it should look. But it still doesn’t know: Where things should go and how big they should be. This step is called Layout (also known as Reflow).

During layout, the browser calculates:

• Element width

• Element height

• Margins

• Padding

• Position on screen

For example:

• This div is 300px wide

• This image is centered

• This button sits below the paragraph

It’s like arranging furniture inside a room.

If something changes later (like resizing the window), layout may happen again that’s why it’s sometimes called reflow.

Paint: Filling in the Colors

After layout, the browser knows the size, position and structure. Now it needs to actually draw. This step is called painting.

Painting

Here the browser perform all this task

• Draws text

• Fills colors

• Applies shadows

• Renders borders

• Displays images

Think of layout as outlining shapes in pencil.
Paint is filling them with color.

Display: Showing Pixels on Screen

Finally, the painted layers are:

• Combined

• Sent to the screen

• Converted into pixels

And you see the webpage and all of this happens in milliseconds.

The Full Journey: From URL to Pixels

Here’s the complete story:

• You type a URL

• Browser sends network request

• Server responds with HTML

• Browser parses HTML → builds DOM

• Browser parses CSS → builds CSSOM

• DOM + CSSOM → Render Tree

• Layout (calculate positions)

• Paint (draw elements)

• Display pixels on screen

Where Does JavaScript Fit?

We kept JavaScript light on purpose.

JavaScript can:

• Modify the DOM

• Change CSS styles

• Add or remove elements

If JavaScript changes something:

• The DOM updates

• The Render Tree may update

• Layout and Paint may run again

That’s how pages become interactive.

Very Simple Parsing Analogy

Parsing means breaking something into parts and understanding structure.

Sentence example: The cat sat.
You understand: Subject → The cat , Verb → sat

Math example:

3 + 5 × 2

You build a structure internally:

   +
  / \
 3   ×
    / \
   5   2

Browsers do this with HTML and CSS.

They don’t just read text.
They build structured trees.

High-Level Browser Architecture

Let’s recap once more,

A browser is a collection of cooperating systems:

• User Interface → where you type and click

• Browser Engine → the coordinator

• Rendering Engine → builds and paints pages

• Networking → fetches files

• JavaScript Engine → executes scripts

• Storage → saves cookies, cache, local data

Examples of rendering engines:

• Chromium (used by Chrome & Edge)

• Gecko (used by Firefox)

In general term HTML is a language for website creation , and generally referred a the foundation of the web. It is generally used for the creation and structure of sections, paragraphs, and links using HTML elements (the building blocks of a web page) such as tags and attributes.

Before the visuals wow us and the interactions amaze us, every great website starts with a script HTML.
HTML doesn’t make pages pretty, it makes them readable, just like a book’s structure. You are able to read this because of html.

Lets deep dive into and learn what HTML is and how its work.

HTML Document Structure

The above code shows the basic boilerplate code for the HTML.

<!DOCTYPE html> - This declaration notify the browser about the document type and version of HTML used, ensuring proper rendering and preventing potential issues.

<html></html> - This element act as a wrapper holding the entire page and is sometimes known as the base element. It includes the lang attribute, setting the primary language of the document.

<head></head> - This element holds the document’s metadata and configuration data rather than user-facing content. It contains SEO-related information, stylesheet references, character set definitions, and other resources required for proper page rendering.

<meta charset="utf-8"> -This element specifies UTF-8 as the document’s character encoding, enabling broad multilingual character support and reducing the risk of text-rendering problems.

<meta name="viewport" content="width=device-width"> - This viewport element tells the browser to match the page width to the device’s screen width, preventing mobile browsers from displaying the page at a larger width and scaling it down

<title></title> - This sets the title of your page, which is the title that appears in the browser tab the page is loaded in. It is also used to describe the page when you bookmark/favorite it.

<body></body> - This contains all the content that you want to show to web users when they visit your page, whether that's text, images, videos, games, playable audio tracks, or whatever else.

HTML — The Skeleton of a Webpage

Think of a website like a human body:

• HTML → Skeleton (structure)

• CSS → Skin (style)

• JavaScript → Muscles (behavior)

HTML does not make a page beautiful — it gives it structure and meaning.

What is an HTML Tag?

An HTML tag is a keyword enclosed in angle brackets < >.

Example:

<p> This is a paragraph tag </p>

You can think of a tag like a label on a box.
It tells the browser what kind of content is inside.

For example:

• <p> → This is a paragraph

• <h1> → This is a main heading

• <div> → This is a container

• <span> → This is a small inline container

Opening Tag, Closing Tag, and Content

Most HTML tags which we use come in pairs:

<p>This is a paragraph</p>

<p>        → Opening tag  
This is a paragraph → Content  
</p>       → Closing tag

The closing tag has a forward slash /.

Box Analogy

Think of it like a box:

Opening Tag  →  box with open lids
Content      →  content inside the box
Closing Tag  →  closed box

What is an HTML Element?

An HTML element is everything together:

Opening Tag + Content + Closing Tag

Example:

<h1>Welcome</h1>

Here:

• <h1> → Tag

• Welcome → Content

• </h1> → Closing tag

• Entire thing → Element

🔎 Difference Between Tag and Element

Self-Closing (Void) Elements

Some HTML elements do not need a closing tag.

Example:

<img src="image.jpg">
<br>
<hr>

These are called void elements. Why? Because they do not wrap content.

Examples:

• <img> → Displays an image

• <br> → Line break

• <hr> → Horizontal line

Block-Level vs Inline Elements

Block-Level Elements

A block-level element always starts on a new line, and the browsers automatically add some space (a margin) before and after the element.

Example:

<h1>Heading</h1>
<p>Paragraph text</p>
<div>Container</div>

Visual Idea:

[Heading          ]
[Paragraph        ]
[Another Section  ]

Each appears on a new line.

Inline Elements

Inline elements in HTML are elements that do not start on a new line and only take up as much width as necessary to display their content.

Example:

<span>Hello</span>
<span>World</span>

Visual Idea:

Hello World

Commonly Used HTML Tags (Beginner Level)

Headings

<h1>Main Heading</h1>
<h2>Subheading</h2>

Paragraph

<p>This is a paragraph.</p>

Division (Container)

<div>This is a section</div>

Span (Inline container)

<span>Inline text</span>

Link

<a href="https://example.com">Visit Website</a>

Image

<img src="photo.jpg" alt="My Photo">

Simple Mini Example

<!DOCTYPE html>
<html>
<head>
  <title>My Title</title>         //title of the Webpage
</head>
<body>
  <h1>Welcome</h1>
  <p>This is my first website.</p>
</body>
</html>

DNS (Domain Name System) translates human-friendly names into addresses computers can use to deliver web pages, emails, and other services. Let’s break it down in simple terms.

What Is DNS?

DNS (Domain Name System) translates human-friendly domain names into machine-friendly IP addresses.

Humans remember:

google.com
chaicode.com
github.com

Computers communicate using numbers:

142.250.190.14

DNS bridges that gap.

Without DNS, you would need to memorize IP addresses for every website you visit. Worse, if a website changes its hosting provider and its IP changes, everyone would need the new number manually. DNS makes infrastructure flexible and scalable.

Why DNS Exists (Beyond the Phonebook Analogy)

The ‘phonebook’ analogy is useful, but DNS is much more powerful than a simple lookup table.

DNS enables:

• Infrastructure changes without changing domain names

• Load balancing across multiple servers

• Failover and high availability

• Email routing

• Security verification

• CDN integration

• Global traffic management

DNS is not just a directory, it is a distributed control system for the internet.

How DNS Resolution Actually Happens

When you type:

www.chaicode.com

Here’s what happens behind the scenes:

• Your browser checks its cache.

• Your operating system checks its DNS cache.

• Your system queries a recursive DNS resolver (usually from your ISP).

• The resolver:

  • Contacts root name servers

  • Then TLD servers (.com, .org, etc.)

  • Then authoritative name servers

• The authoritative server returns the correct IP address.

• Your browser connects to that IP.

This entire process usually takes milliseconds.

Why DNS Records Are Needed

DNS works because of DNS records.

Think of DNS records as instructions stored in a global distributed database. They tell the internet, if someone asks for this name, here’s what to do.

Without DNS records:

• Websites wouldn’t load

• Emails wouldn’t arrive

• Domain ownership couldn’t be verified

• Services couldn’t connect properly

Let’s break down the most important record types.

NS Record — Who Is Responsible for the Domain

NS stands for ‘nameserver,’ and the nameserver record indicates which DNS server is authoritative for that domain (i.e. which server contains the actual DNS records)

What it does:

Specifies which name servers are authoritative for your domain.

Why it matters:

It defines delegation and control.

If your domain uses:

ns1.cloudflare.com
ns2.cloudflare.com

That means those servers are responsible for answering DNS questions about your domain.

Analogy:

Think of it as a registry office that says, if you want information about this street, go talk to this office.

Without NS records, the DNS hierarchy would not work.

A Record — Domain → IPv4 Address

What it does:

Maps a domain name to an IPv4 address.

Example:

example.com → 93.184.216.34

Why it matters:

This is what browsers ultimately need.

Without an A record, a website cannot be reached via IPv4.

Real-World Impact:

• You can point multiple domains to one server.

• You can point one domain to multiple IPs for load balancing.

AAAA Record — Domain → IPv6 Address

What it does:

Maps a domain name to an IPv6 address.

Example:

example.com → 2606:2800:220:1:248:1893:25c8:1946

Why it exists:

IPv4 addresses are limited (~4.3 billion total).
IPv6 supports a vastly larger address space.

Modern systems often use both A and AAAA records to support both protocols.

CNAME Record — Alias to Another Domain

What it does:

Points one domain name to another domain name.

Example:

www.example.com → example.com

Important distinction:

• A record → points to IP

• CNAME → points to another name

Why it’s powerful:

Useful when integrating third-party services like:

• CDNs

• SaaS tools

• Hosting providers

Instead of pointing to an IP directly, you point to a hostname they manage.

If their IP changes, you don’t need to update anything.

MX Record — Email Routing

What it does:

Specifies which server handles email for your domain.

Example:

example.com → mail.example.com

Why it matters:

If someone sends an email to:

info@example.com

The sending mail server checks the MX record to determine where to deliver it.

Key detail:

MX records include priority numbers.

Lower number = higher priority.

If the primary mail server is down, email is delivered to the backup.

TXT Record — Metadata and Verification

What it does:

Stores arbitrary text information.

Common Uses:

• SPF records (prevent email spoofing)

• DKIM verification

• Domain ownership verification

• Service configuration

• Security policies

Example:

v=spf1 include:_spf.google.com ~all

TXT records are critical for modern email security and service authentication.

How All DNS Records Work Together

A typical domain might have:

• NS records → define who manages DNS

• A / AAAA records → define web server IPs

• CNAME records → create aliases

• MX records → route email

• TXT records → enable security & verification

When a user visits:

www.example.com

The browser:

1. Finds the authoritative name servers (via NS records).

2. Gets the A/AAAA record.

3. Connects to the IP address.

4. Loads the website.

When someone sends email to:

admin@example.com

Mail servers:

1. Query MX records.

2. Find mail server.

3. Deliver the message.

DNS quietly orchestrates all of this.

Common Confusions Cleared

A vs CNAME

• A → Points to IP address

• CNAME → Points to another domain name

NS vs MX

• NS → Who controls the DNS

• MX → Where emails go

DNS vs Hosting

DNS does not host your website.
It only tells users where the website is hosted.

DNS in System Design

For developers and backend engineers, DNS is critical because it enables:

1. Horizontal Scaling

Multiple IPs for one domain.

2. Failover

Traffic shifts if one server goes down.

3. Global Load Distribution

Users routed to closest data center.

4. Service Decoupling

Frontend and backend services can live on different infrastructure.

DNS is part of the internet’s control plane.

It determines where traffic should go before any data is transferred.

Final Takeaway

DNS is one of the most foundational systems on the internet.

It:

• Translates names to IPs

• Routes web traffic

• Directs email

• Enables security verification

• Allows infrastructure flexibility

Understanding DNS records gives you the power to:

• Debug website issues

• Troubleshoot email delivery

• Configure domains properly

• Design scalable systems

It may look simple on the surface — but DNS is one of the most important distributed systems ever built.

Network Devices are physical devices or appliances which are required for communication and interaction computers or computer network systems. This article explains modems, routers, switches, hubs, firewalls and load balancers, how they work individually, and how they fit together in a real-world setup.

High-Level View: How the Internet Reaches a Home or Office

When a user opens a website or calls an API, traffic flows roughly like this:

Internet → Modem → Router → Firewall → Switch → Servers/PC

In cloud environments, some of these devices are physical, while others are virtualized, but the working remain the same.

What Is a Modem?

Primary responsibility:
It connects your home network with the Internet Service Provider (ISP).The modem can perform both the task of modulation and demodulation simultaneously.

What it does:

• It converts digital signals (fiber, cable, DSL) into analog signals or vice-versa.

• Acts as the entry point to the internet

• Modems can modulate as well as demodulate the signals simultaneously.

• Modem allows to connect only a specific number of devices to the internet.

Analogy:
The modem is the post office that connects your house to the outside world.

Key point:
A modem does not manage traffic or security. It only brings the internet into your network.

What Is a Router?

A router is a device which connects two or more networks or sub-networks. It serves two primary functions, managing traffic between these networks by forwarding data packets to their intended IP addresses, and allowing multiple devices to use the same Internet connection

There are several types of routers, but most routers pass data between LANs (local area networks) and WANs (wide area networks).

What it does:

• Routes traffic between networks (LAN ↔ Internet)

• Assigns IP addresses (via DHCP)

• Performs Network Address Translation (NAT)

Router vs Modem (Clear Difference):

Analogy:
The router is like a traffic police officer.

Backend relevance:
Routers affect latency, packet loss, and connectivity — all critical for API reliability.

Switch vs Hub: How Local Networks Actually Work

Hub (Mostly Obsolete)

A hub is a physical layer networking device which is used to connect multiple devices in a network. They are generally used to connect computers in a LAN.

Analogy:
Someone shouting a message in a crowded room.

Problems:

• Massive collisions

• Security risks

• Inefficient

Switch (Modern Standard)

The Switch is a network device that is used to segment the networks into different subnetworks called subnets or LAN segments. It is responsible for filtering and forwarding the packets between LAN segments based on MAC address.

What it does:

• It operates in the Data Link Layer in the OSI Model.

• It performs error checking before forwarding data.

• It transfers the data only to the device that has been addressed.

• It operates in full duplex mode.

Analogy:
A post office delivering mail to exact addresses.

Switch vs Hub (Clear Difference):

Backend relevance:
Switches enable low-latency communication between servers in data centers.

What Is a Firewall?

A firewall is a network security system, available as hardware or software, that monitors and controls incoming and outgoing traffic based on predefined rules. It acts like a security guard, filtering data packets to either accept, reject or drop.

What it does:

• Filters packets based on rules

• Blocks malicious traffic

• Enforces security policies

Analogy:
A security gate checking IDs before entry.

Why security lives here:

• Prevent Unauthorized Access: Like a locked door with a guard, only trusted users and traffic are allowed through.

• Block Malicious Traffic: Harmful data such as viruses, phishing attempts, or denial-of-service (DoS) attacks are stopped before reaching the system.

• Protect Sensitive Information: Safeguards personal and business data from theft or accidental leaks.

• Control Network Usage: Enforces policies such as parental controls, workplace restrictions, or government filtering.

• Mitigate Insider Risks: Detects suspicious applications or data exfiltration attempts from within the network.

Backend relevance:
Firewalls protect APIs, databases, and internal services from direct exposure.

What Is a Load Balancer?

A load balancer is a solution that acts as a traffic proxy and distributes network or application traffic across endpoints on a number of servers. Load balancers are used to distribute capacity during peak traffic times, and to increase reliability of applications.

What it does:

• Traffic Distribution: To keep any one server from becoming overburdened, load balancers divide incoming requests evenly among several servers.

• Scalability: By making it simple to add servers or resources to meet growing traffic demands, load balancers enable horizontal scaling.

• Optimization: Load balancers optimize resource utilization, ensuring efficient use of server capacity and preventing bottlenecks.

• Health Monitoring: Load balancers often monitor the health of servers, directing traffic away from servers experiencing issues or downtime.

• SSL Termination: Some load balancers can handle SSL/TLS encryption and decryption, offloading this resource-intensive task from servers.

Analogy:
A toll booth system spreading cars across multiple lanes.

Why scalable systems need it:
Load balancers enable:

• High availability

• Fault tolerance

• Zero-downtime deployments

Backend relevance:
Every modern backend (microservices, cloud apps, APIs) relies on load balancers.

How These Devices Work Together (Real-World Setup)

A Production Backend System

Internet
   ↓
ISP Modem
   ↓
Router (NAT, Routing)
   ↓
Firewall (Security Rules)
   ↓
Load Balancer (Traffic Distribution)
   ↓
Switch
   ↓
Backend Servers (APIs, DBs, Services)

Each device has one clear responsibility, reducing complexity and improving reliability.

Connecting This to Backend Systems & Production Deployments

For software engineers:

• Latency issues often come from routing or switching problems

• Downtime can occur without load balancers

• Security breaches often trace back to firewall misconfigurations

• Scalability depends on network architecture, not just code

In cloud platforms (AWS, Azure, GCP), these devices are often software-defined, but their behavior mirrors physical hardware.

Final Takeaway

Networking devices are not just infrastructure they are core components of system design.

Understanding how modems, routers, switches, firewalls, and load balancers work together allows backend engineers to:

• Design scalable systems

• Debug production issues faster

• Build more secure applications

Good software architecture starts with solid network foundations.

The .git Folder

When you run the git init in the terminal , it results in creation of a .git folder which is generally hidden. This folder various key components responsible for the tracking and storing of changes made.

• refs: Short for "references." This stores pointers to commit objects (like where your branches and tags are).

• config: Contains project-specific settings (like your remote URLs)

• HEAD: A file that points to the branch you are currently on.

• index: Also known as the Staging Area. It’s a binary file that lists what will go into your next commit.

• objects: The heart of the database. This is where all your file content and commit history are stored.

• hooks: They are event-driven scripts that Git executes when you run specific commands like commit, push, or merge.

• info: This is used to store repository-specific information and configuration, primarily for excluding certain patterns and housing supplementary objects.

Git Internal/git object

Git primary operates by using three primary objects.

Blob

It generally stores the raw content of the file. If it contain identical files , the content produce the same hash blob, disabling duplication.

Tree

It represents a directory structure. It contains references (hashes) to blobs and others trees
along with filenames and permissions.

Commit

Captures a complete snapshot of the project at a point in time. It points to a root tree, includes metadata (author, timestamp, message), and references parent commits to form a history chain.

What Happens During git add and git commit?

Let’s deep dive into the internal flow of .git folder

Step 1: git add

When you stage a file, Git:

Takes the current content of the file and then Hashes it to Creates a Blob in the objects/ folder.
Updates the index (staging area) to map the filename to that new Blob hash.

Step 2: git commit

When you commit, Git:

Creates a Tree object that represents the current state of the index and a Commit object that points to that Tree and the previous commit (the parent). Moves the pointer of your current branch (in refs/heads/) to this new Commit hash.

Why it’s important

Understanding Git is easier once you realize it is mostly about pointers and snapshots.
A branch is just a file that points to a commit. Switching branches simply moves that pointer.
When you run git add, Git already stores your data as objects, even before you commit.
And Git doesn’t rebuild your project by replaying every change—it just checks out the snapshot stored in the commit’s tree.

Conclusion

Git is a content-addressed key-value store where objects are indexed by SHA-1 hashes.
The version control features are built on top of this storage model.
Understanding .git reveals how Git actually works.

Git is a tool that helps you manage changes to your code over time. It notes every changes or updates you make. It also has the liability to undo mistakes or look back to previous version if needed. So in simple term, ‘Git can be referred to as a camera that takes snapshot of your work. Everything you do like edit, updates or tiny changes is captured and stored safely inside hidden .git folder’.

What is the purpose of using Git?

Generally git is used for its powerful, flexible and user friendly features, allows for team collaboration, manages changes to your code in a safe and easy way. Not only this but also features like code merge, detect conflict, parallel programming and many more.

Some Basics and Core Terminologies

Repository(Repo)

A storage space which contain all project files and their revision history. Here the storage space can be local or remote according to requirement.

To initialize a git repo:

git init

Working Directory

Local folder where you can update or edit files.
When you are working on your project folder like modifying, you are working in the working directory.

git init
git revert

Staging Area

It is a temporary place where the changes are stored before committing to the .git folder

git add .               //Add the main file and correspondence/sub files within it
git add filename.txt    //add only the named file

Commit

It captures the changes that have been staged at that moment, which is generally referred as snapshot of the staged content and has a hash id for each commit.

git commit -m "referrence for what action been performed"
git commit -am "ref."    //here is perform the action for git add and git commit altogether.

Branch

This helps in managing the workflow by allowing parallel workflow, where the main branch holds the main-project whereas the sub branches carryout the experimental features, bug, etc.

git branch <branch-name>   //to create a new branch
git chechout -b <branch-name>  //to switch to particular branch

Merge

Generally combine changes from one branch to another.

git merge <branch-name>  //merge the content from the sub branch to the main branch

Push

Uploading of the content of the .git folder which is local to online server(remote).

git push <remote> <branch>

Pull

To fetch and merge remote changes to the local system.

git pull <remote> <branch>

Remote

It is a reference to the repository which is remotely present / online.

Common Git Commands

git add -move to staging area
git commit -save changes(move the snapshot to .git folder)
git log -view commit history
git status - provides a real-time summary of your git repo.
git branch -display and manage branch

Here the question arise, How did things work back then before version control existed?

Before modern version control systems, developers relied on laid down resources like local system files, folders, zip files, pendrive, emails. Lets deep dive into the evolution from local-based code sharing(pendrive) to sophisticated version control systems.

The “Human-Powered File Transfer” Era

Imagine you and I are working together on a simple website project. You’re building the homepage on your laptop, adding content and styling. I’m working on the contact page on mine, fixing layout issues and improving the form.

We don’t have Git, GitHub, or any shared repository. The only way we exchange updates is through a pendrive.

How our work happens:

Imagine you’re working on a small project on your laptop — maybe a simple website or a college assignment. At the same time, I’m helping you by editing another part of the project on mine. There’s no Git, no GitHub, no shared repository. The only way we exchange updates is through a pendrive.

You finish tweaking the Contact file, save it, and copy it . You hand it over to me so I can merge it with my changes. I plug it into my laptop, replace my old copy, make a few updates to the homepage, and then copy the modified files back to the same pendrive. Now I hand it back to you so you can continue.

At first, this feels simple, almost harmless. But the moment we both start making changes at the same time, things starts to fall apart.

Issues we face during this practice

Version Conflicts

There’s no automatic way for either of us to know which file contains which changes. Who has the latest version. Which changes are newer. If you edit a file on your laptop while I edit the same file on mine…One of our versions will be overwritten and lost forever. Neither of us will knows.

File Naming Chaos

To avoid losing work, we start renaming files:

final.html

please_work_final.html

latest_final.html

save_my_soul.html

Soon, even we can’t tell which file actually contains the real, working version.

Manual Syncing Takes Time

Every update forces a full manual cycle: make the change, copy it to the pendrive, physically carry and deliver it, and overwrite the existing files. This constant back-and-forth disrupts the work-flow, slows progress, and turns collaboration into a repetitive, time-consuming task.

No History / No Backup

If a file is overwritten accidentally, there is no undo, no version history, and no way to recover earlier changes. Once lost, the work is gone — unless separate manual backups were created in advance

High Risk of Data Loss

Pendrives are inherently unreliable—they can become corrupted, be lost, or fail without warning. When the latest version of a project exists only on such a device, a single failure can instantly erase days or even weeks of work. This forces developers to constantly create manual backups, double-check every copy, to tackle the constant fear of accidental data loss.

This back-and-forth process might work for a small file or a single person, but the moment two people collaborate, it becomes chaotic. This is exactly why modern version control systems were created.

Adopting a Modern Version Control Workflow

All these issues highlight a bigger truth: the problem was never the pendrive, it was the lack of a system that understood collaboration. When developers rely on manual file transfers, everything becomes fragile.

At some point, it became clear that software development needed more than just a storage device.
It needed a system one that could track changes, record history, manage conflicts, and ensure that no one’s work is lost just because the wrong file got copied.

This exact need led to the creation of Version Control Systems (VCS).

VCS introduced ideas that were impossible in the ‘pendrive era':

• A single, reliable source of truth

• Automatic change tracking

• Branching to allow parallel work

• Conflict detection instead of silent overwrites

• The ability to revert, compare, and merge safely

Systems like Git took this further by making collaboration fast, safe, and scalable, enabling teams of any size to work on the same project without fear of losing progress.

This is why VCS exists; to replace a fragile, manual, error-prone workflow with a reliable, automated, and collaborative one.