If you ever installed and tried out Linux after seeing a cool hacking sequence in a sci-fi movie, you know that opening it feels like stepping into a strange city with many roads named /bin, /home and /tmp. As beginners, we tend to ignore them and go on with our Linux usage by simply remembering the most commonly used commands.

While that approach works initially, it is good to take a step back and understand the Linux Filesystem properly. As "good" developers, who actually get their code out of localhost, we need to understand Linux to its core, because that is what drives the majority of web servers.

In this blog post, I have broken down the philosophy behind the Linux Filesystem, what all those randomly named directories actually do, and some cool insights along the way.

The Core Philosophy: Everything is a File

A fascinating thing about Linux is that everything, literally everything in Linux, is represented as a file in the Filesystem. This includes not just documents, but devices, processes, sockets, and even hardware!

To digest this idea properly, we need to change our perspective on what a "file" actually means. We usually think of a "file" as a document on our system. In Linux though, a "file" is just a stream of bytes with a path. That's it. Anything that can be read from or written to fits that definition.

Let's look at some examples of files as per this new definition:

Since everything is a file, you can do powerful things like pipe data between programs, redirect output, and chain tools together. This is the exact reason why the Linux terminal is so powerful.

This core philosophy is what gives the Linux Filesystem its structure.

Filesystem Hierarchy Standard (FHS)

Before we dive deep into the directory structure, I want to mention that the Linux Filesystem isn't a random arrangement of resources in a tree-like structure. There is a specification called the "Filesystem Hierarchy Standard" that defines the directory structure and contents in Linux and other Unix-like operating systems. It is maintained by the Linux Foundation.

The Problem it Solves

Before FHS, different Unix distributions placed files wherever they wanted. A config file might live in /etc on one system and /usr/config on another. This made it a nightmare to:

• Write portable software

• Move between distributions

• Predict where anything lives

FHS serves as a guideline, which most major distros like Debian, Fedora and Arch follow closely to maintain uniformity and predictability.

The Root Directory

The root directory is the top of the entire filesystem tree in Linux. It is represented by /. The reason it is called the "root" is because there is nothing above it. You can go back as much as you want but never beyond the "root".

If you're from the Windows ecosystem, you can think of this as your C:\. Everything, including files, devices, processes, and external drives, all mount within this same tree.

We can run the ls command at the root of our linux system, and would get the following directories:

/
├── bin     -> Essential command binaries
├── boot    -> Kernel and bootloader files
├── dev     -> Device files to interface with hardware
├── etc     -> Text-based configuration files
├── home    -> Personal directories for each user
├── lib     -> Shared library files used by binaries
├── media   -> Mount point for removable media (USBs, CDs)
├── mnt     -> Temporary mount point for filesystems
├── opt     -> Optional, add-on software packages
├── proc    -> Virtual filesystem tracking running processes
├── root    -> Home directory for the root user
├── run     -> Runtime data for processes since last boot
├── sbin    -> System binaries for administrative use
├── srv     -> Data served by the system (FTP, HTTP, etc.)
├── sys     -> Virtual filesystem exposing kernel internals
├── tmp     -> Temporary files, cleared on reboot
├── usr     -> Secondary hierarchy for user installed software
└── var     -> Variable data like logs, caches and spools

/etc: System Configuration Hub

I personally like to refer to it as the "Configuration Hub" of the entire system. The reason is that every major program, service, and system behavior has its config file here.

Moreover, it's all just plain text. This simple design choice makes configurations readable and easily editable. This is what makes Linux so customizable.

/etc
├── hostname       -> The machine's host name
├── hosts          -> Local DNS overrides
├── nsswitch.conf  -> Controls the order of lookups
├── resolv.conf    -> DNS server configuration
├── network/       -> Network interface configuration (Debian)
├── netplan/       -> Network interface configuration (Ubuntu)
├── passwd         -> User account information
├── shadow         -> Hashed user passwords
├── group          -> Group memberships
├── sudoers        -> Controls who can run commands as root
├── environment    -> System-wide environment variables
├── profile        -> Shell environment on login
└── systemd/
    └── system/    -> Service unit files

Password Storage

Most people assume passwords are stored somewhere as plain text or in one file. Linux is much smarter than that. It splits user information across multiple files with specific jobs.

/etc/passwd

Despite the name, this file does not store passwords anymore. It stores user account information. Every line is one user, and it looks like this:

root:x:0:0:root:/root:/bin/bash
sameer:x:1000:1000:Sameer Bhagtani:/home/sameer:/bin/bash

Each colon-separated field means:

1. Username

2. Password field: just an x, meaning "go look in /etc/shadow"

3. UID: User ID, a unique number for the user

4. GID: Group ID, the user's primary group

5. GECOS: Full name or description

6. Home directory

7. Default shell

/etc/shadow

This is where the actual passwords live. Linux doesn't store them in plain text format. Instead, it hashes the password for security.

This file is only readable by root. A line looks like:

root:\(y\)j9T\(randomsalt\)hashedpasswordstring:20384::::::

Each colon-separated field means:

1. Username

2. Hashed password

3. Last password change: days since Jan 1, 1970

4. Minimum password age: days before password can be changed

5. Maximum password age: days before password must be changed

6. Warning period: days before expiry to warn the user

7. Remaining fields: inactivity period, expiry date, reserved

Groups

A group in Linux is simply a collection of users. Linux uses groups to manage permissions at scale. Instead of setting permissions for each user individually, you assign permissions to a group and add users to it.

For example, you have 5 developers who all need access to /var/www/. Instead of giving each of them individual access, you create a www-data group, give the group access to that folder, and add all 5 users to it.

All this information is stored in /etc/group, where a line looks like:

network:x:27:user1,user2

Each colon-separated field means:

1. Group name

2. Password: almost always x or empty, group passwords are rarely used

3. GID: Group ID

4. Members: comma-separated list of users in the group

Default Groups

Following are the meanings of some of the default groups in Linux:

DNS Configuration

When you type google.com in your browser, your system needs to figure out the IP address behind it. This process is called DNS resolution. I have written a blog post about DNS resolution in depth, in case you're interested:

https://blog.sameerbhagtani.dev/dns-resolution-explained

Linux handles this in a specific order, and /etc controls that entire pipeline.

/etc/hosts

This is checked before any DNS server is even contacted. It's a simple static lookup table that maps hostnames to IP addresses manually. It looks like:

127.0.0.1       localhost
192.168.1.10    myserver.local

So if you add google.com here pointing to some other IP, your system will use that and never bother asking a DNS server. This is why it's called a local DNS override. Developers use this all the time to point a domain to their local machine for testing.

/etc/resolv.conf

This is where your DNS servers are defined. When /etc/hosts has no answer, your system goes here to find out which DNS server to ask. It looks like:

nameserver 8.8.8.8
nameserver 8.8.4.4

The above example shows Google's DNS severs. You can also use 1.1.1.1 which is Cloudflare's.

/etc/nsswitch.conf

This is the traffic controller of the whole resolution process. It defines the order in which your system looks things up. The relevant line looks like:

hosts: files dns

This tells the system: first check files (which means /etc/hosts), then go to dns (which means /etc/resolv.conf). This is why /etc/hosts always wins over DNS servers.

The full DNS resolution flow

1. Check /etc/nsswitch.conf for the lookup order

2. Check /etc/hosts for a static entry

3. No match? Go to /etc/resolv.conf for the DNS server

4. Ask that DNS server for google.com

5. Get the IP back, connect

Network Interface Configuration

A network interface is your system's way of connecting to a network. It can be physical, like your ethernet port or WiFi card, or virtual, like a loopback interface. Each interface gets a name:

• eth0 or enp3s0: your ethernet card

• wlan0 or wlp2s0: your WiFi card

• lo: the loopback interface, always 127.0.0.1, used by your system to talk to itself

You can see all your interfaces with:

ip link show

The location of these network config files varies by distro, which is one of the few places where the FHS does not give you full uniformity.

For Debian and older Ubuntu systems, the file is located at /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

This says: bring up eth0 automatically on boot, and get its IP via DHCP.

Service Configurations

When you run systemctl start nginx or systemctl enable ssh, systemd needs to know:

• What those services actually are?

• How should they start?

• What user should run them?

• What happens if they crash?

All of this is defined in a unit file.

/etc/systemd/system/ is where your local unit files live. These are either custom services you created yourself, or overrides to the default unit files that came with installed packages.

What does a unit file look like?

Let's look at a simple example. Say you want to create a service that runs a Node.js app on boot:

[Unit]
Description=My Node.js App
After=network.target

[Service]
ExecStart=/usr/bin/node /home/sameer/app/index.js
Restart=always
User=sameer

Breaking down the two sections:

• [Unit]: Metadata about the service.

  • After=network.target: Don't start this service until the network is up.

• [Service]: The actual behavior

  • ExecStart: the command to run

  • Restart=always: if the process crashes, restart it automatically

  • User: run the process as this user, not as root

Enabling vs Starting

There is an important distinction here that trips up a lot of beginners:

systemctl start nginx    # starts the service right now
systemctl enable nginx   # makes it start automatically on every boot

start is temporary. enable is permanent. You almost always want both:

systemctl enable --now nginx

The --now flag starts it immediately and enables it for future boots in one command.

Where do default unit files live then?

If /etc/systemd/system/ is for local configs, where do the unit files for packages like nginx or ssh live? Those ship to /usr/lib/systemd/system/.

The rule is simple: /etc/systemd/system/ always takes priority over /usr/lib/systemd/system/. So if you want to override how a package's service behaves without touching the original file, you drop your version in /etc/systemd/system/ and systemd will use that instead.

/proc: The Process Filesystem

/proc is one of those things that genuinely makes you stop and think. It looks like a directory full of files, but none of these files actually exist on your disk. There is nothing written to your SSD or HDD here.

/proc is a virtual filesystem that the kernel generates in memory, live, every time you look at it.

Think of it as a window into your running kernel. Whatever is happening on your system right now, the kernel is exposing it as readable files inside /proc. The moment a process starts, an entry appears. The moment it dies, it disappears.

You can verify this yourself:

ls /proc

You will see a bunch of numbered directories like 1, 423, 1089 and so on. Each number is a PID (Process ID), and each directory contains information about that running process. Open one up:

ls /proc/1

You will find files like status, cmdline, maps, fd and more, all describing exactly what that process is doing right now.

For example:

cat /proc/1/status

This will show you the name of the process, its state, memory usage, which user is running it, and more. All of that, served as a plain text file.

This is the "everything is a file" philosophy at its most elegant. The kernel is not a black box. It is constantly talking to you through /proc, and all you need to read it is cat.

Routing Tables

When your system wants to send a packet to some IP address, it does not just blindly throw it onto the network. It first consults a routing table, which is essentially a set of rules that answer one question: for this destination, which interface should I use and where should I forward the packet?

A simple way to see your routing table is:

ip route show

You will see something like:

default via 192.168.1.1 dev wlan0
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

• The first line says: for everything else, forward to 192.168.1.1 (your router) via wlan0.

• The second line says: for anything in the 192.168.1.0/24 range, you can reach it directly through wlan0 without going through a gateway.

Now, this same information is also exposed as a file inside /proc:

cat /proc/net/route

Iface    Destination  Gateway   Flags  RefCnt  Use  Metric  Mask
wlan0    00000000     0101A8C0  0003   0       0    100     00000000
wlan0    0001A8C0     00000000  0001   0       0    100     00FFFFFF

This is the raw version of the same routing table, but in hex. The values for Destination, Gateway and Mask are in little endian hex format, which is why 0101A8C0 translates to 192.168.1.1. Not the most human readable format, which is exactly why tools like ip route exist on top of it.

The key insight here is that /proc/net/route is not a config file. You cannot edit it to change your routes. It is purely a read only window into what the kernel currently knows about routing, consistent with the whole philosophy of /proc.

System Logs

When something goes wrong on your system, the first place you go is /var/log. This is where Linux keeps logs for pretty much everything: the kernel, system services, applications, authentication events, and more.

ls /var/log

You will see a bunch of files and directories. Here are the important ones:

/var/log
├── syslog     -> General system activity logs (Debian/Ubuntu)
├── auth.log   -> Authentication events (logins, sudo usage)
├── kern.log   -> Kernel messages
├── dmesg      -> Boot time hardware detection logs
└── journal/   -> systemd's binary log store

Reading logs

For most log files, a simple cat or tail works:

tail -f /var/log/auth.log

The -f flag follows the file in real time, so you can watch events as they come in. Useful for monitoring login attempts or debugging a service.

For systemd based systems, the preferred way to read logs is through journalctl:

journalctl -u nginx        # logs for a specific service
journalctl -f              # follow logs in real time
journalctl --since today   # logs from today only

What insights do logs actually give you?

A few practical examples of what you can catch from logs:

• Someone repeatedly trying to SSH into your server with wrong passwords: visible in auth.log

• A service that keeps crashing on boot: visible in journalctl -u servicename

• A kernel panic or hardware error: visible in kern.log or dmesg

• General system misbehavior: visible in syslog

File Descriptors

When a program opens a file, the kernel does not give it direct access to the file. Instead, it gives back a small integer called a file descriptor. This integer is just a reference that the program uses to interact with the file going forward.

Every process gets three file descriptors by default when it starts:

0 -> stdin  (standard input)
1 -> stdout (standard output)
2 -> stderr (standard error)

When the program opens additional files, they get assigned the next available numbers: 3, 4, 5 and so on.

You can see the file descriptors of any running process through /proc:

ls /proc/<PID>/fd

This will show you every file, socket, pipe or device that process currently has open, each represented as a numbered symlink.

Everything is a File Descriptor

This is where the "everything is a file" philosophy gets very practical. In Linux, file descriptors are not just for files on disk. They represent:

• Regular files

• Directories

• Network sockets

• Pipes between processes

• Device files in /dev

When your Node.js server accepts an incoming HTTP connection, the kernel hands it a file descriptor for that socket. The server reads from it and writes to it just like a regular file. Same interface, whether it is a text file or a network connection.

The Default Limit and Why it Matters

The kernel puts a limit on how many file descriptors a single process can have open at once. You can check yours with:

ulimit -n

On most systems this defaults to 1024. This means a single process can have at most 1024 files, sockets, or connections open at the same time.

For a simple script or a CLI tool, 1024 is more than enough. But for a web server or a WebSocket server, this becomes a real problem fast.

The WebSocket Problem

A WebSocket server maintains a persistent open connection with every connected client. Each connection is a file descriptor. So if you have 1024 concurrent users connected to your WebSocket server, you have hit the limit. The 1025th user cannot connect. The kernel will throw a Too many open files error and your server will start rejecting connections.

This is not a bug in your code. It is a system level limit you need to raise.

Raising the Limit

There are two limits to be aware of:

ulimit -n   # soft limit, applies to your current session

To raise it permanently, you edit /etc/security/limits.conf:

*    soft    nofile    65536
*    hard    nofile    65536

The * applies to all users. nofile stands for number of open files. 65536 is a common production value for web servers.

For systemd managed services, you set it directly in the unit file instead:

[Service]
LimitNOFILE=65536

After making these changes, restart the service and verify:

cat /proc/<PID>/limits

This is one of the first things you tune when deploying a WebSocket server or any high concurrency application in production. A server with default limits will quietly start failing under load, and the logs will tell you exactly why.

Conclusion

In the end, the Linux filesystem is far more than a collection of folders. It reflects a philosophy of simplicity, consistency, and treating system resources through one unified interface.

Once you understand what lives where, Linux stops feeling mysterious and starts feeling logical. And as developers, that understanding gives us a real edge when working with servers, debugging production systems, or simply feeling more at home inside the machines that run the modern web.

In large-scale distributed systems, performance is not an option, but a necessity. Imagine if platforms like YouTube or Twitter slowed down or went completely offline for a few hours. In today’s world, we rely heavily on such systems, and they are expected to respond with low latency at all times.

A common approach to reducing latency is caching. A cache is simply a high-speed, temporary, and often in-memory data storage layer that stores a subset of frequently accessed data. It allows us to serve future requests faster, without having to hit the primary storage, such as the database.

This not only reduces latency but also decreases the load on the database, enabling the system to handle massive traffic efficiently.

Typically, every cached item has a TTL (Time-To-Live) associated with it. Once the TTL expires (for example, after 60 seconds), the cache is invalidated, and fresh data is fetched from the database as needed. This approach works well for small systems, but this naive model begins to break down at scale.

In distributed systems, cache expiration can lead to sudden traffic spikes, resulting in issues like the thundering herd problem. (You can read more about this in my blog post on the thundering herd problem.)

Basic TTL Caching is Not Enough

A basic TTL-based caching approach looks like this:

Data is cached -> requests are served from the cache -> TTL expires -> a new request comes in, triggering a fetch from the database -> and the cycle continues.

This works well when traffic is evenly distributed and requests arrive at random intervals. In smaller systems, this approach is often sufficient.

However, in large-scale systems, traffic is rarely uniform. It is often bursty, with many users requesting the same data at the same time. When the cache for such frequently accessed data expires, a large number of requests suddenly start missing the cache and go directly to the database, all at once.

This leads to sudden load spikes, increased latency, and potential system failures.

Cache Expiry can Cause Traffic Spikes

Consider the example of a social media platform, which caches popular posts to increase the overall speed. Assume the cache TTL is 60 seconds.

If everything is going fine, requests will hit our server, the server will fetch the post content from the cache, and return it in the response. There is no database call, and thus shorter request-response cycles.

However, after the 60 seconds have gone by and the cache expires, if a large number of requests come in simultaneously, since the cache is empty, each and every request will go straight to the database at the same time, resulting in the thundering herd problem. This can overload the database, increase latency, and even lead to request failures.

Clearly, we need smarter strategies to handle cache expiration in distributed systems.

Cache Management Strategies for Distributed Systems

TTL Jitter

Up until now, we’ve understood that the core issue is many cached items expiring at the same time. This causes a large number of requests to hit the database simultaneously, leading to chaos. The problem isn’t traffic itself, large-scale systems are expected to handle high traffic. The real issue is synchronized traffic.

TTL Jitter is a simple yet effective strategy that introduces randomness into cache expiration times. Instead of assigning a fixed TTL (for example, 60 seconds), we add a small variation and set the TTL within a range, such as 50–70 seconds.

ttl = baseTTL + random(-delta, +delta)

As a result, cache entries expire at different times, and incoming requests get naturally distributed instead of creating sudden spikes.

• Without jitter: 10k keys expire at exactly 60s -> spike

• With jitter: keys expire at 58s, 61s, 64s -> smoother load distribution

Probability-Based Early Expiration

The limitation of TTL jitter is that cache entries still expire eventually. Requests will still hit the database, we’ve only found a way to distribute them more evenly.

To handle this more effectively, we can take a proactive approach using probabilistic early expiration.

Instead of waiting for the TTL to reach zero, we allow some requests to refresh the cache before it actually expires. However, we don’t want every request to do this, as that would create unnecessary load. So, we introduce probability into the decision.

Each incoming request has a certain chance of recomputing the cached value early. This probability is not fixed, it increases as the cache gets closer to expiration.

• When the TTL has just been set -> very low probability of recomputation

• As the TTL decreases -> probability gradually increases

• Near expiration -> high probability of recomputation

Thus, instead of reacting at the deadline like basic TTL-based caching, this method prepares the system gradually.

Mutex / Cache Locking

Even with strategies like TTL jitter and probabilistic early expiration, there are still situations where multiple requests may try to recompute the same cache entry at the same time. This leads to duplicate work, where several requests hit the database simultaneously for the same data, increasing load and reducing efficiency.

To solve this, we can use mutex (mutual exclusion) or cache locking. When a cache entry expires and multiple requests try to fetch fresh data, only one request is allowed to recompute the value, while the others wait.

The simple flow is:

• A request checks the cache

• If the cache is missing or expired -> it tries to acquire a lock

• If it gets the lock -> it fetches data from the database and updates the cache

• If it doesn’t get the lock -> it waits until the cache is updated

The tradeoff is that this introduces additional latency for waiting requests.

Stale-While-Revalidate (SWR)

Even with techniques like mutex locking, some requests may still have to wait while the cache is being recomputed. This introduces additional latency, which can negatively impact user experience.

The idea behind SWR is: instead of blocking requests when the cache expires, we serve the stale (expired) data and refresh the cache in the background.

In this approach, a cached item can exist in two states:

1. Fresh -> within TTL, safe to serve

2. Stale -> TTL expired, but still usable for a short duration

Because of this, users never have to wait for recomputation. The system continues to serve responses with low latency, while the cache gets updated asynchronously.

However, the tradeoff is that users may receive stale data for a short period of time. Because of this, SWR is not suitable for systems that require strict consistency, such as financial transactions or real-time critical data.

Cache Warming

So far, all the strategies we’ve discussed deal with cache behavior during runtime. But what if we could prepare the cache before requests even start coming in?

This is where cache warming (or pre-warming) comes in.

The idea is simple: instead of waiting for users to request data and then populating the cache (lazy loading), we proactively load frequently accessed data into the cache in advance.

This ensures that when the first request arrives, the data is already available in the cache, avoiding initial cache misses.

This can be done using:

• background jobs

• scheduled tasks (cron jobs)

• analytics-based predictions

Conclusion

Caching is not just about storing data to make systems faster, it’s about making the system stable under load.

Each of these techniques makes a tradeoff between freshness, latency, and consistency. There is no one-size-fits-all solution, the right approach depends on the nature of your system and the type of data you are dealing with.

Imagine you're standing outside an Apple Store, waiting for the new iPhone to launch. Obviously, you're not alone. You're just one among a big crowd waiting for that door to open. As soon as it does, each and every single person in the crowd rushes in, out of the fear of getting left behind. And before you know it, you're caught up in chaos, everyone pushing each other around, overloading the store.

This is exactly what is called the "Thundering Herd Problem" in the context of system design. Many clients make a request at the same time and overwhelm a resource (server, database, etc.).

What is the Thundering Herd Problem?

We all try to make our systems robust and fast, for which we adopt different system design patterns like scaling, caching, etc. However, certain loopholes in our system can lead to the "Thundering Herd Problem." Even large, robust systems suffer from this problem.

The Thundering Herd Problem simply refers to a large number of clients requesting a resource simultaneously, often reacting to the same event at the same time. It is not just high volume; it is simultaneous high volume.

Despite how the name sounds, it is important to understand that the Thundering Herd Problem is not a bug. It's just a pattern that occurs in systems with a large client base, and we need to understand why it occurs and how we can fix it.

Where Does it Commonly Occur?

This problem can occur in multiple parts of a system, such as caching systems, load balancers, etc., due to different reasons:

• Cache Stampede: When a highly accessed cached item expires, multiple concurrent requests bombard the database to refill the cache.

• Synchronized Retries: If a service fails to respond for a short period of time and then comes back online, many clients simultaneously retry failed requests, creating a spike in traffic.

• Cron Jobs: Multiple servers or microservices are configured to run a cron job at the exact same scheduled time.

• Sudden Traffic Spikes: A sudden influx of users all attempting to perform the same action at the same time, such as clicking a "Buy Now" button during a flash sale.

Real World Example

Consider the example of a social media platform, which caches popular posts to increase the overall speed. Assume the cache TTL is 60 seconds.

If everything is going fine, requests will hit our server, the server will fetch the post content from the cache, and return it in the response. There is no database call, and thus shorter request-response cycles.

However, after the 60 seconds have gone by and the cache expires, if a large number of requests come in simultaneously, since the cache is empty, each and every request will go straight to the database at the same time, resulting in the thundering herd problem.

This can overload the database, increase latency, and even lead to request failures.

Difference Between Normal Spike vs Thundering Herd

In normal situations, traffic spikes happen gradually. Imagine Hotstar starts streaming IPL live. Viewers keep joining over time, and our auto-scaling configuration is able to scale the servers to handle the increasing load.

On the other hand, in a thundering herd situation, all the traffic comes in at once. It is not gradual, it is instantaneous and unpredictable. This results in more load on the servers and databases than the system can handle.

In such situations, we often enter into a chain reaction:

More requests -> DB connections get exhausted -> requests start waiting -> latency increases → timeouts happen → clients retry → even more load. 💥

Why it Becomes Dangerous in Distributed Systems

Now that you have understood the thundering herd problem, it is important to understand its impact in the context of distributed systems.

Distributed systems amplify this problem even further:

• There are many services and instances involved. If every request triggers 5 services, then with a spike of 100k requests, we are effectively dealing with 500k internal requests.

• If one service slows down, other services depending on it also slow down, leading to cascading failures across the system.

• Each service might implement its own retry logic, resulting in multiple retries across multiple services, which further multiplies the load.

• Many services rely on shared resources like databases, caches, or message queues. When all services hit these resources simultaneously, they become bottlenecks and can fail under pressure.

Failures in distributed systems propagate and amplify, making the thundering herd problem significantly more dangerous.

System-Level Impact

• CPU: A sudden surge in requests increases the number of active threads and processes, causing CPU usage to spike. This can lead to excessive context switching and reduced overall efficiency.

• Database: A large number of concurrent queries can exhaust the connection pool, slow down query execution, and potentially crash the database under heavy load.

• Cache: During a cache miss storm, the cache becomes temporarily ineffective, forcing repeated requests to hit the database and increasing pressure on backend systems.

• Latency: As requests start queuing up, response times increase significantly. This leads to timeouts, failed requests, and a poor user experience.

The impact is not isolated, it affects every layer of the system.

Techniques to Minimize It

Request Coalescing

Instead of allowing all requests to go to the database to refill the cache, we ensure that only one request performs this operation. When multiple requests arrive for the same data, one request fetches the data from the database and updates the cache, while the others wait and reuse the same result.

This prevents duplicate work and reduces unnecessary load on the database.

Cache Locking / Mutex

Cache locking (or mutex) is a technique used to ensure that only one request can regenerate the cache at a time. When a request detects a cache miss, it acquires a lock and proceeds to fetch data from the database. Other requests are blocked or wait until the lock is released.

Staggered Expiry

Staggered Expiry is another technique that focuses on making sure that all the cached data does not expire at once. To achieve this, we introduce a small random variation (jitter) in their expiry times.

This reduces the chances of a sudden spike in load, by spreading out requests over time.

Exponential Backoff

When a request fails, you don’t just try again right away. With exponential backoff, you wait a bit, and each time you fail again, you wait even longer. The delay grows fast, so clients don’t all hammer the server at once.

It spreads out the load and keeps the system from getting overloaded.

Rate Limiting

Rate limiting sets a cap on how many times a client can hit the system in a given period. If you go over that number, your requests get blocked or slowed down. This keeps the service from getting swamped and makes sure everyone gets a fair shot at the resources.

Conclusion

The thundering herd problem is not caused by high traffic alone, but by many requests happening at the same time due to a shared trigger. While it can lead to serious issues in distributed systems, it can be effectively managed using the right techniques such as request coalescing, staggered expiry, backoff strategies, and rate limiting.

By understanding the root cause and applying these strategies, we can build systems that remain stable even under sudden spikes in load.

Imagine walking into a cafe called the "JavaScript Cafe". Just like any other typical cafe, this one too has several ingredients, chefs who decide what to do with these ingredients as per the customer's wishes, and finally they create some dish based on the requirements.

If you think about it, we basically take some data (ingredients), put them together using some operations (as decided by the chefs), and create a final dish (result).

Programming works in a similar fashion. In every programming language, including JavaScript, we have a foundational concept called operators. In this blog post, we are going to explore what operators are, how they help us build expressions and all the different types of operators, all with a fun analogy of a cafe, particularly the JavaScript Cafe!

Tokens: Building Blocks of any Language

Before we get into operators, let's briefly talk about tokens. Whenever we write any program, the compiler/interpreter behind that language breaks it all down into tokens. Tokens are the smallest meaningful units of code in any language. The JavaScript engine also breaks down the code into these bits and pieces called tokens.

You can think of tokens like words in a sentence. Just like sentences are made of words, programs are made up of tokens.

JavaScript has the following types of tokens:

Keywords

These are reserved or pre-defined words that have a special meaning.

Examples include:

let
const
function
return
if
else
class
await

Identifiers

These are names that we programmers give to variables, functions, classes, or objects.

Examples include:

let username = "Sameer";

function add(a, b) {
    return a + b;
}

• In the above example, username and add are identifiers.

Literals

These represent fixed values written directly in code.

Examples include:

42
"Hello"
true
null

Separators

These are symbols used to structure the code.

Examples include:

;
,
.
()
{}
[]
:

Comments

Comments are simply some annotations in our code, that are straight up ignored by the JavaScript engine. These are useful for documentation.

Examples include:

// this is a single line comment

/*
this is a
multi-line
comment
*/

Operators

And finally, we have our operators. This blog post is specifically about operators in JavaScript. However, this brief section was important to help you understand that operators are simply some of many tokens that have a special meaning to the language.

Now what exactly are operators, why do we need them, etc. will all be covered in the rest of this blog post.

What are Operators?

Before getting into the types of operators, we need to understand what they even are, and why do we need them. The definition goes like:

Operators are symbols or keywords in programming that perform operations on variables and values (operands) to manipulate data.

However, such long and boring technical definitions do not enable us to understand and remember the concept easily. So let's take the example of our JavaScript Cafe. Let's say you walk into this beautiful Cafe, and order for a coffee. Based on your requirements, the chefs will gather all the ingredients and prepare a coffee for you.

Now this simple process involved the following parts:

• Ingredients

• Actions performed by the chefs on the ingredients

• Your coffee

Similarly, in the context of programming, we have some input data (ingredients), and we want to get the output i.e. the final result (the coffee). In order to do that, it is required to perform certain actions on that input data (actions performed by the chefs).

Operators are the symbols that help us perform these actions. They are simply that glue, that help us put together some data, and generate some result. The simplest example would be:

5 + 2

Here, + is an operator, whose job is to sum up the numbers given to it.

Expressions

Now that we have a basic idea about operators, we need to understand one more term, which is pretty common in programming languages. An expression is simply a valid unit of code that evaluates to a single value. This value can be a number, a string, a boolean value, a function, etc.

In our analogy, we can think of an expression like an "order". In order to complete an order, we use several ingredients, instructions given by the customer, etc., and in the end we put it all together, to create a final dish.

Example:

5 + 2

This is a very simple expression. It produces the value 7.

Here,

• 5 & 2 are the operands

• + is the operator (just like we saw in the last section)

• 7 is the output produced

Structure of expressions

Such expressions are built using operators. And we can use any valid combination of operators, to create any type of expression, no matter how simple or complex. A simple structure is given below:

Types of Operators in JavaScript

Now that we understand what operators and expressions are, let's deep dive into the types of operators in JavaScript. Some of these concepts, even extend to other programming languages, since operators is a fundamental concept.

Following are the most commonly used types of operators in JavaScript:

1. Arithmetic Operators

2. Comparison/Relational Operators

3. Logical Operators

4. Assignment Operators

5. Conditional/Ternary Operator

Arithmetic Operators

Arithmetic operators allow us to perform certain mathematical operations on data. Whenever we want to add, subtract, divide, multiply, etc. any values or variables, we make use of such arithmetic operators.

Think of them as how chefs add, remove, combine, etc. several ingredients to make dishes.

Example Code

console.log(12 + 8);    // 20
console.log(15 - 6);    // 9
console.log(4 * 5);     // 20
console.log(20 / 4);    // 5
console.log(14 % 4);    // 2
console.log(3 ** 4);    // 81

let count = 10;
count++;
console.log(count);     // 11

count--;
console.log(count);     // 10

Comparison/Relational Operators

If arithmetic operators are like preparing ingredients, then comparison operators are like checking ingredients before cooking.

Comparison operators, often referred to as Relational operators, allow us to compare data in our program. These always return a boolean value (true or false). These are very useful when writing conditional statements.

Example Code

console.log(10 > 5);    // true
console.log(4 < 2);     // false
console.log(7 >= 7);    // true
console.log(3 <= 6);    // true

console.log(8 == "8");  // true
console.log(8 === "8"); // false

console.log(5 != 3);    // true
console.log(5 !== "5"); // true

Important: == and === are not the same

JavaScript has two operators for checking equality, and understanding their difference is extremely important.

The == operator checks if two values are equal, while ignoring their data types. In other words, it only cares about values, not the data types.

console.log(5 == 5);        // true     ->     this makes sense
console.log(5 == "5");      // true     ->     weird

If you've ever studied any other language, the above example might look weird. But the simple reason is, the == operator does not care about the data types.

On the other hand, the === operator does. It is called strict equality, and it checks both, values, as well as the data types.

console.log(5 === "5")    // false    ->    now it makes sense

Think of == as a casual comparison, and === as a strict comparison.

Recommendation

In most cases, prefer using === instead of ==. It avoids unexpected type conversions, and makes code more predictable in general.

Logical Operators

Logical operators represent decisions the chef makes before cooking.

Just like Comparison operators, Logical operators also return boolean values. They help us combine multiple conditions together.

Example Code

let hasFlour = true;
let hasSugar = false;

console.log(hasFlour && hasSugar);  // false
console.log(hasFlour || hasSugar);  // true
console.log(!hasFlour);             // false

Truth Tables

Truth Tables simply allow us to look at all the possible outputs that a logical operator can produce based on the inputs.

Truth Table for Logical AND

It evaluates to true, only if both inputs are true. In all the other cases, it evaluates to false.

Truth Table for Logical OR

It evaluates to false, only if both inputs are false. In all the other cases, it evaluates to true.

Truth Table for Logical NOT

It simply flips the value. true becomes false, and false becomes true.

Assignment Operators

Assignment operators are simply used to store values in variables and update them later. In assignment operators, we have the simple = assignment operator, that assigns the value on the right-hand side, to the variable on the left-hand side.

However in addition to this, we also have several compound assignment operators. These include +=, -=, *=, etc. These are just shorthands for longer assignment statements. In other words, a += 5 is the same as a = a + 5.

As per our analogy, think of assignment operators like writing ingredients on a recipe board and modifying them as you cook.

Example Code

let quantity = 4;
console.log(quantity);      // 4

quantity += 3;
console.log(quantity);      // 7

quantity -= 2;
console.log(quantity);      // 5

quantity *= 2;
console.log(quantity);      // 10

quantity /= 5;
console.log(quantity);      // 2

quantity %= 2;
console.log(quantity);      // 0

quantity = 3;
quantity **= 2;
console.log(quantity);      // 9

Conditional/Ternary Operator

The conditional (ternary) operator is a shorter way to write simple if...else conditions. It chooses between two values based on whether a condition is true or false.

condition ? valueIfTrue : valueIfFalse

As per our analogy, you can think of it as choosing between two dishes based on available ingredients. If chocolate is available, make a chocolate cake, otherwise make a vanilla cake.

Example Code

let age = 18;

let message = age >= 18 ? "You can enter" : "Entry not allowed";

console.log(message);   // You can enter

Conclusion

JavaScript operators are the building blocks that allow us to perform calculations, compare values and make decisions in our programs. We looked at some of the most popular operators in this article, such as the conditional operator, arithmetic, comparison, logical, and assignment.

You will eventually feel more at ease utilizing operators in real-world code if you continue experimenting with small examples and try combining various operators.

Imagine you're at that classic point in your life, where you try to plan a trip to Goa with your friends. We all know the ultimate output of such plans, don't we? 👀 However, we still try with the dream of finally having a trip like "Zindagi Na Milegi Dobara".

So imagine you're the guy who's reaching out to everyone in your group, trying to finalize a trip to Goa. Let's explore various Promise Utility and Concurrency Methods in JavaScript from this lens 🧐, and trust me, you'll never forget them!

Think of Promises like waiting for your friends to confirm a trip. Each friend’s reply is uncertain. The different Promise methods simply define how strict you want to be about who joins the trip.

Promise States: Your Friends' Replies

Before we deep dive into Promise Utility and Concurrency Methods, let's take a quick look at the different states a promise can be in. These states are like the replies your friends can give you in our analogy. There are primarily 3 states:

✅ Fulfilled

The fulfilled state denotes successful completion of a Promise. It's like your friend saying "yes" to go on the trip with you (sounds dreamy, right? 😵‍💫).

❌ Rejected

The rejected state denotes failure in fulfilling a Promise. Thus, you must have guessed it, it's just like your friend saying "no" to the trip.

⏳ Pending

Now we all know that one friend, who knows that he doesn't wanna come, but is too shy to tell that to you. Such friends won't say either "yes" or "no", and will simply try to delay the talk.

The pending state is just like that! It's the state the promise remains in until it gets finally resolved (meaning fulfilled or rejected).

Utility Methods

Promise.resolve()

So let's say you start calling your friends up one by one asking about the trip. Now in order to boost your confidence, you firstly reach out to your friend "Rahul" who has the following characteristics:

• Chill parents

• A lot of money (Like really a lot)

• Always ready for anything

You absolutely know that this is my guy. He never says "no" to anything. And that is what happens! He replies immediately with:

"Bro I'm in."

No waiting at all.

Me after Rahul's reply:

Example Code:

const askRahul = Promise.resolve("Rahul Confirmed");

askRahul.then((data) => console.log(data));

Output:

Rahul Confirmed

Promise.reject()

After you feel a boost in your confidence, you decide to go straight to the final boss, your friend "Kunal". Kunal has a great track record. Out of all the trips your friends group has taken, Kunal has agreed to come onto one, because it was a short one-day trip 🙄. For all the other occasions, Kunal always has excuses like:

"Bro I have my exams"

"Bro my parents are not allowing"

You hit him up, and just like always, he replies with immediate rejection.

Example Code:

const askKunal = Promise.reject("Kunal busy (like always)");

askKunal
    .then((data) => {
        console.log("This block of code never gets executed");
    })
    .catch((data) => {
        console.log(data);
    });

Output:

Kunal busy (like always)

Concurrency Methods

Promise.all()

This method takes an iterable of promises as input, and returns a single Promise. This returned promise gets fulfilled only if all of the input promises fulfill. It gets rejected even if any one input promise rejects.

In our analogy, this method is like the scenario:

"Trip happens only if EVERYONE agrees"

Let's say you ask three of your friends: Rahul, Kunal and Dev. We go on a trip only if everyone agrees. If even one friend cancels, the trip is cancelled.

Example Code:

const askEveryone = Promise.all([askRahul, askKunal, askDev]);

askEveryone
    .then((data) => {
        console.log("Yo everyone said 'yes'!");
        console.log(data.join("\n"));
    })
    .catch((data) => {
        console.log("We can't go! Someone said 'no'.");
        console.log(data);
    });

Output:

We can't go! Someone said 'no'.
Kunal busy (like always)

Kunal be like:

Promise.allSettled()

This method takes an iterable of promises as input and returns a single Promise. This returned promise gets fulfilled simply when all of the input promises get completed. It doesn't matter whether they get fulfilled, or rejected. As long as all the input promises come out of their pending state, the returned promise of this method gets fulfilled.

In our analogy, this is like:

"Let’s see everyone’s status first"

You basically wanna see how many of your friends are agreeing to come, and how many or not. You don't cancel the trip automatically. You simply gather everyone's replies. You want a full report like this:

• Rahul -> coming

• Kunal -> busy

• Dev -> coming

Example Code:

const askEveryone = Promise.allSettled([askRahul, askKunal, askDev]);

askEveryone
    .then((data) => {
        console.log("Here is what everyone said:\n");
        console.log(data);
    })
    .catch((err) => {
        console.log(err);
    });

Output:

Here is what everyone said:

[
  { status: 'fulfilled', value: 'Rahul Confirmed' },
  { status: 'rejected', reason: 'Kunal busy (like always)' },
  { status: 'fulfilled', value: 'Dev Confirmed' }
]

Promise.race()

This method takes an iterable of promises as input and returns a single Promise. The returned promise gets settled with the eventual state of the first promise that settles.

The definition may sound a bit complex, but it really isn't. In our analogy, this is basically like:

"We go with whoever replies first"

If the first person says "Let's go!", then the trip happens. However, if the first person says "I can't come", the trip is immediately cancelled.

Example Code:

const askEveryone = Promise.race([askRahul, askKunal, askDev]);

askEveryone
    .then((data) => {
        console.log("First Person agreed:");
        console.log(data);
    })
    .catch((data) => {
        console.log("First Person denied:");
        console.log(data);
    });

Output:

First Person agreed:
Rahul Confirmed

In this example, Kunal again tries to disagree:

But Rahul is already on you're side, and thus the trip is on! 😎

Promise.any()

This method also takes an iterable of promises as input and returns a single Promise. The returned promise gets fulfilled when any one input promise gets fulfilled. It gets rejected if all of the input promises get rejected.

In our analogy, this is simple like:

"We go as long as at least ONE friend can come"

So you can imagine this as the final desperate situation in your trip planning. You're so tired of your friends just saying "no" every time, that this time you're simply ready to go even if one single friend "agrees". However, if you have really bad luck, and everyone says "no", the trip gets cancelled, and you realize ZNMD is just a hypothetical movie.

Example Code:

const askEveryone = Promise.any([askRahul, askKunal, askDev]);

askEveryone
    .then((data) => {
        console.log("One Person agreed:");
        console.log(data);
    })
    .catch((data) => {
        console.log("Everyone denied:");
        console.log(data);
    });

Output:

One Person agreed:
Rahul Confirmed

Summary Table

Conclusion

With this fun analogy, I don't think you will ever forget the different Promise methods. Planning a trip to Goa with your friends and working with Promises in JavaScript have something in common - uncertainty. You never know who will say “yes,” who will say “no,” or who will keep you waiting.

Whether you need everyone to agree (Promise.all), just one person to say yes (Promise.any), the first reply (Promise.race), or a complete status report (Promise.allSettled), JavaScript gives you precise control over asynchronous flow.

And just like Goa plans, sometimes everything works out perfectly… and sometimes Kunal ruins it.

What happens after you type a URL and press Enter?

It feels instant, almost magical. One moment you see a blank tab, the next you’re looking at a fully styled webpage with text, images, buttons, and animations.

Behind the scenes, your browser is doing a surprising amount of work. It’s not just “opening a website”; it’s coordinating multiple components that fetch data, understand code, build structures, and finally paint pixels on your screen.

Let’s walk through that journey as a simple story of many small parts working together.

What a Browser Actually Is

A browser is like a mini operating system dedicated to the web. Instead of running apps, it:

• Downloads web files (HTML, CSS, JavaScript, images)

• Understands what those files mean

• Decides how everything should look

• Draws the final result on your screen

• Reacts to your clicks, typing, and scrolling

Think of it as a factory that takes raw materials (code) and turns them into a finished product (a visible, interactive webpage).

Components of a Browser

At a very high level, a browser has a few key workers:

1. User Interface: what you see and interact with

2. Browser Engine: the coordinator that tells others what to do

3. Rendering Engine: turns HTML/CSS into visual pixels

4. Networking: downloads files from the internet

5. JavaScript Engine: runs JavaScript code

These parts act like departments in a company, each with a clear role but constantly talking to each other.

User Interface: Address Bar, Tabs, Buttons

This is the visible shell of the browser:

• Address bar where you type URLs

• Back/forward buttons

• Tabs

• Bookmarks bar

When you press Enter after typing a URL, the UI passes that request inward to the rest of the browser machinery. From this point on, the real behind-the-scenes work begins.

Browser Engine vs Rendering Engine

Browser engine is the manager, whereas Rendering Engine is the painter and the builder.

The browser engine:

• Receives your navigation request

• Asks the networking part to fetch data

• Tells the rendering engine to start building the page

The rendering engine:

• Understands HTML and CSS

• Figures out structure and style

• Draws the page on the screen

Manager decides what should happen. Painter decides what you see.

Networking: Fetching HTML, CSS, JS

After you press Enter:

1. The browser sends a request to the server.

2. The server responds with HTML (and links to CSS, JS, images, etc.).

3. The browser keeps requesting those extra files as it discovers them.

This is like ordering a book online, then separately ordering its illustrations, cover design, and index as you realize they’re needed.

HTML Parsing and DOM Creation

The HTML file is just text. The browser reads it and builds a structure called the DOM (Document Object Model).

For the following HTML:

<body>
  <h1>Hello</h1>
  <p>World</p>
</body>

A tree is created that looks like:

   body
   /  \
 h1    p

This tree (the DOM) represents the structure and content of the page.

CSS Parsing and CSSOM Creation

CSS is also read and converted into another tree-like structure called the CSSOM.

• If the DOM is: “What elements exist?”

• The CSSOM is: “How should each element look?”

For example:

h1 { color: red; }

The CSSOM records that all h1 nodes should be red.

How DOM and CSSOM Come Together

The browser combines:

• The DOM (structure)

• The CSSOM (styles)

to create a new structure often called the render tree. This render tree contains only what is actually visible and how it should appear. It’s like taking a skeleton (DOM) and putting clothes and colors on it (CSSOM).

Layout (Reflow), Painting, and Display

Now the browser figures out geometry:

1. Layout (Reflow)

   • Where is each element?

   • How big is it?

2. Painting

   • Fill in colors, borders, text, shadows

3. Display (Compositing)

   • Put all painted pieces together and show them on the screen

This is the moment pixels finally appear and you see the webpage. If something changes (like resizing the window), layout and painting may run again.

The Entire Flow

1. You type a URL and press Enter.

2. Networking downloads HTML.

3. HTML is parsed → DOM is built.

4. CSS is downloaded and parsed → CSSOM is built.

5. DOM + CSSOM → render tree.

6. Layout calculates positions and sizes.

7. Painting fills in pixels.

8. The final page appears on your screen.

Many of these steps can overlap and repeat as new resources arrive.

Conclusion

A browser is not a single tool but a team of specialized components working in sequence. From fetching files to building trees, from calculating layouts to painting pixels, every webpage you open is the result of a carefully choreographed process.

And as a beginner, that’s all you need to grasp for now: not every tiny detail, but the beautiful flow from URL to pixels.

The internet is basically a huge network of computers constantly sending tiny chunks of data to each other. But without rules, this data would arrive out of order, get lost, or collide with other data. To prevent chaos, the internet relies on well-defined communication rules called protocols.

Two of the most important of these rules are TCP and UDP. They decide how data is sent from one machine to another. On top of them, higher-level rules like HTTP define what that data means (like a web page or API response).

To understand modern networking and backend systems, you need to know when to use TCP, when to use UDP, and how HTTP fits into the picture.

What are TCP and UDP?

Think of sending data like sending messages in the real world.

• TCP (Transmission Control Protocol) is like a phone call. You establish a connection, talk carefully, confirm every message is heard, and hang up only when done.

• UDP (User Datagram Protocol) is like making an announcement on a loudspeaker. You just broadcast your message. No one confirms receipt. It’s fast, but some people might miss parts of it.

Both are transport protocols. Their job is to move raw data between two computers over the internet.

Key Differences Between TCP and UDP

In short,

• TCP = safe and reliable

• UDP = fast but risky

When to Use TCP

Use TCP when correctness matters more than speed. Examples:

• Loading a website

• Sending emails

• Downloading files

• API requests and database queries

TCP is like a courier service that tracks every package and resends it if lost. You might wait a bit longer, but you’ll get everything intact. If even one missing or out-of-order piece breaks your data, choose TCP.

When to Use UDP

Use UDP when speed matters more than perfection. Examples:

• Live video streaming

• Online gaming

• Voice/video calls

• Real-time sensor data

UDP is like a live TV broadcast. If a few frames drop, the show keeps going. Waiting to “fix” the missing frame would cause annoying lag. If a small loss is acceptable but delays are not, choose UDP.

Common Real-World Examples

TCP-based

• Web browsing (HTTP/HTTPS)

• File transfer (FTP, SFTP)

• SSH remote login

• Email (SMTP, IMAP)

UDP-based

• DNS lookups

• Video conferencing

• Online multiplayer games

• Live streaming protocols

Notice the pattern:

• Important, structured data → TCP

• Real-time, continuous data → UDP

What is HTTP and Where It Fits

HTTP (HyperText Transfer Protocol) is the language your browser and servers use to talk about web content. It defines things like:

• “GET this page”

• “POST this form data”

• Status codes like 200, 404, 500

But HTTP does not decide how the data physically travels across the network. It only defines the format and meaning of the messages. HTTP is an application-layer protocol.

Relationship Between TCP and HTTP

HTTP rides on top of TCP.

Layering looks like this:

HTTP -> TCP -> IP -> Network

• HTTP says what to send (requests and responses)

• TCP ensures it is delivered correctly and in order

HTTP does not replace TCP. HTTP uses TCP to get reliability. Without TCP, HTTP messages could arrive broken or shuffled. Without HTTP, TCP would just be sending meaningless bytes.

Conclusion

The internet needs rules to move data safely and efficiently. TCP and UDP are two different strategies for that job:

• TCP is careful, reliable, and ordered.

• UDP is fast, lightweight, and best for real-time use.

HTTP sits above them, describing web requests and responses, while relying on TCP to ensure those messages arrive perfectly.

Imagine two people trying to talk on a phone call without saying “hello” first, without taking turns, and without confirming what they heard. Messages would overlap, get lost, or be misunderstood.

Computer networks face the same problem. If devices just threw data at each other without any rules, communication would quickly become messy and unreliable.

This is where TCP comes in. It adds discipline, structure, and confirmation to network communication so that data arrives safely, in order, and without corruption.

What is TCP and Why It Is Needed

TCP (Transmission Control Protocol) is a set of rules that devices use to send data reliably over a network. When you load a website, send an email, or download a file, TCP is usually working behind the scenes to make sure:

• No data is lost

• Data arrives in the correct order

• Errors are detected and fixed

Without TCP, data would just be a stream of random pieces with no guarantee that the receiver gets the full message correctly.

Problems TCP Is Designed to Solve

Sending data over the internet is not as clean as passing a note across a table. Along the way:

• Packets (chunks of data) can be lost

• Packets can arrive out of order

• Packets can get duplicated

• Packets can be corrupted

If we send data without any rules:

• The receiver won’t know what’s missing

• It won’t know what came first

• It won’t know if something is wrong

TCP solves this by numbering data, asking for confirmations, and resending anything that goes missing.

What is the TCP 3-Way Handshake

Before sending actual data, TCP first sets up a connection between the two devices. Think of it like starting a conversation:

1. “Can we talk?”

2. “Yes, we can talk.”

3. “Great, let’s start.”

This setup process is called the 3-way handshake. It makes sure both sides are ready and agree on some initial numbers used to track data.

Step-by-Step Working of SYN, SYN-ACK, and ACK

1. SYN (Synchronize): The client says: “I want to start a connection. Here’s my starting sequence number.”

2. SYN-ACK (Synchronize + Acknowledge): The server replies: “I got your request. Here’s my starting number, and I confirm yours.”

3. ACK (Acknowledge): The client responds: “I confirm your number too. Let’s begin.”

After this, both sides trust each other and know where to start counting data from.

How Data Transfer Works in TCP

Once connected, data is sent in small chunks. Each chunk has a sequence number.

Example idea:

• Chunk 1 → number 1

• Chunk 2 → number 2

• Chunk 3 → number 3

The receiver sends back an acknowledgement (ACK) saying: “I have received everything up to number X.” If the sender doesn’t receive an ACK for some number, it assumes that chunk was lost and sends it again.

How TCP Ensures Reliability, Order, and Correctness

TCP uses a few simple but powerful ideas:

1. Sequence Numbers: Keep data in the correct order, even if packets arrive mixed up.

2. Acknowledgements: Confirm what has been successfully received.

3. Retransmission: If something isn’t acknowledged in time, resend it.

4. Error Checking: Each packet has a checksum. If data is corrupted, it is rejected and resent.

So even if the network drops or scrambles packets, TCP rebuilds the correct message on the receiver’s side.

How TCP Handles Packet Loss

Suppose packets 1, 2, 3 are sent. The receiver gets 1 and 3, but 2 is lost. The receiver will keep saying. “I’m still waiting for 2.” The sender sees that 2 is not being acknowledged and resends packet 2. Only after packet 2 arrives will the receiver move forward and acknowledge packet 3 and beyond.

This is how TCP avoids gaps in the final data.

How a TCP Connection Is Closed

Ending a TCP connection is also a careful, confirmed process. It’s like saying goodbye properly instead of just hanging up.

1. One side sends FIN: “I’m done sending data.”

2. Other side sends ACK: “Got it.”

3. Then the second side sends its own FIN: “I’m also done.”

4. First side sends final ACK: “Confirmed. Connection closed.”

This ensures both sides finish cleanly without losing the last bits of data.

Conclusion

TCP brings order to the chaos of network communication.

Through a simple handshake, numbered data, acknowledgements, and smart resending of lost pieces, it guarantees that what you send is exactly what the other side receives. Whether you’re loading a webpage or building your own backend server, TCP is the quiet workhorse that makes reliable communication possible.

Before your backend server handles an API request or your frontend loads a web page, data has to travel through a chain of physical network devices. These devices move bits across cities, buildings, and rooms before your code ever runs.

Whether you’re in a home setup or a production data center, the journey from “the internet” to your machine always involves a few key players: modems, routers, switches, firewalls, and sometimes load balancers.

Understanding what each of these actually does gives you a clearer picture of how real-world systems are built and deployed.

Let’s start from the moment the internet line enters a building.

High-level journey: How the internet reaches your home or office

1. Your ISP sends internet signals through a cable (fiber, coax, DSL, etc.).

2. A modem converts those signals into usable digital data.

3. A router decides where that data should go.

4. A switch connects multiple local devices efficiently.

5. A firewall filters and protects traffic.

6. In bigger systems, a load balancer spreads traffic across many servers.

Think of it like a logistics pipeline: incoming packages, sorting centers, traffic control, security checks, and distribution.

Modem

A modem is the translator between your ISP and your local network.

Your internet provider sends data in a format suitable for long-distance transmission over cables. Your devices, however, understand standard digital Ethernet signals. The modem converts between these two worlds.

Router

A router is the traffic director of your network. It connects two networks:

• The outside internet (via the modem)

• Your internal local network (phones, laptops, servers)

When data comes in, the router decides which internal device should receive it. When your device sends data out, the router decides where on the internet to send it.

Router ≠ Modem:

• Modem: brings internet in

• Router: distributes it correctly

Switch vs Hub

Both connect many devices in a local network, but they behave very differently.

Hub (old, dumb)

A hub sends incoming data to every port.

Problems:

• Wastes bandwidth

• Causes collisions

• No intelligence

Switch (modern, smart)

A switch learns which device is on which port and sends data only where needed.

Benefits:

• Faster communication

• Better security

• Efficient bandwidth usage

Real networks use switches, not hubs.

Firewall

• A firewall is the security gatekeeper. It inspects incoming and outgoing traffic and decides what is allowed or blocked based on rules.

Typical rules:

• Allow web traffic (ports 80/443)

• Block unknown inbound connections

• Restrict access to internal services

In small setups, the router often has a built-in firewall. In production systems, dedicated firewall appliances add stronger, more granular control.

Load Balancer

A load balancer sits in front of multiple servers and spreads incoming requests among them.

Instead of:

User -> One Server

You get:

User -> Load Balancer -> Many Servers

Benefits:

• Prevents overload on a single server

• Improves availability

• Enables horizontal scaling

This is critical for backend systems serving thousands or millions of users.

Conclusion

Network devices are the physical backbone that make the internet usable and scalable. The modem connects you to the world, the router directs traffic, the switch organizes local communication, the firewall protects your boundary, and the load balancer enables growth.

When you write CSS, you’re not styling the whole page at once. You’re telling the browser exactly which elements should look a certain way. CSS selectors are the tools that let you point at specific elements and say, “You, change your color”, or “You, add some spacing.”

Think of selectors like addressing people in real life. You could say “Hey, everyone!” (very broad), or “Hey, people wearing red shirts!” (more specific), or “Hey, Rahul!” (very precise).

Why CSS Selectors are Needed?

HTML gives structure to your page:

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

But you use CSS to style your webpage. And without selectors, CSS wouldn’t know which elements to style.

If you write:

p {
    color: blue;
}

You’re telling the browser to select all the <p> elements and make their text blue. Selectors are simply ways to choose elements from your HTML so you can style them.

Types of CSS Selectors

Element Selector

This is the simplest selector. It targets elements by their tag name.

• HTML:

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

• CSS:

p {
    color: green;
}

Both paragraphs become green. Use this when you want to style every element of a certain type.

Class Selector

Classes let you target specific groups of elements.

• HTML:

<p class="highlight">Important text</p>
<p>Normal text</p>
<p class="highlight">Another important text</p>

• CSS:

.highlight {
    background-color: yellow;
}

Only the paragraphs with class="highlight" get a yellow background. Classes are reusable. Multiple elements can share the same class.

ID Selector

An ID is meant for a single, unique element.

• HTML:

<h1 id="main-title">My Website</h1>
<h1>Another heading</h1>

• CSS:

#main-title {
    color: red;
}

Only the first heading turns red. Use IDs when you want to style one unique element.

Group Selectors

Sometimes you want to apply the same style to multiple different elements.

• CSS:

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

This selects all <h1> and all <p> elements. Grouping saves repetition and keeps your CSS clean.

Descendant Selectors

These target elements inside other elements.

• HTML:

<div class="card">
  <p>This is inside the card.</p>
</div>

<p>This is outside the card.</p>

• CSS:

.card p {
    color: blue;
}

Only the paragraph inside .card becomes blue. The outside paragraph stays unchanged. You’re not selecting all paragraphs, only those that are descendants of .card.

Basic Selector Priority

If multiple selectors target the same element, some have more power than others. A very high level rule is:

ID > Class > Element

Example:

p {
  color: green;
}

.highlight {
  color: blue;
}

#main-text {
  color: red;
}

For:

<p id="main-text" class="highlight">Hello</p>

Final color will be red, since the ID selector has more priority than element and class selectors. This priority system helps CSS decide which style to apply when there’s a conflict.

Conclusion

CSS selectors are how you “address” elements in your webpage. From broad choices like all paragraphs, to precise targets like one unique ID, selectors give you full control over styling. Mastering selectors means mastering the foundation of CSS. Once you can precisely target elements, you can style anything with confidence.

Every website you visit, from a simple blog to a complex web app, is built on one fundamental language: HTML. If CSS is the paint and JavaScript is the behavior, then HTML is the skeleton that gives the page its basic shape.

In this blog post, we’ll break down what HTML really is, what tags and elements mean, and how they work together to create the structure of a webpage.

What HTML Is and Why We Use It

HTML stands for HyperText Markup Language. It is not a programming language, it’s a markup language used to structure content on the web.

Think of a webpage like a human body:

• HTML = skeleton (structure)

• CSS = skin and clothes (appearance)

• JavaScript = muscles and brain (behavior)

Without HTML, a browser wouldn’t know what is a heading, what is a paragraph, what is an image, or what is a button. HTML gives meaning and structure to raw text and media.

Tags in HTML

An HTML tag is a special keyword wrapped in angle brackets. Some examples are as below:

<p>
<h1>
<div>

You can think of a tag like a label on a box. The label tells the browser what kind of content is inside that box. For example:

• <p> says “this is a paragraph”

• <h1> says “this is the main heading”

Paired Tags(Container Tags)

Most tags in HTML, require a corresponding closing tag too:

<p>Hello World</p>

Here:

• <p> is the opening tag.

• </p> is the closing tag.

• Hello World is the content.

The closing tag has a / before the tag name. It tells the browser: “this part is over now”.

Self-Closing (Void) Tags

Some tags don’t have content and therefore don’t need a closing tag. Some examples are below:

<img src="image.jpg" alt="Image" />
<br />
<hr />

It’s a good practice to have a / at the end for such tags.

Elements in HTML

An HTML Element refers to the combination of an opening tag, closing tag, and the content in between. Example:

<h1>Welcome</h1>

Here, <h1> alone is a tag, however the entire line, <h1>Welcome</h1>, is an element.

Block-Level vs Inline Elements

Block-level Elements

Elements that always start on a new line and take full width by default are called Block-level elements. They behave like big boxes stacked vertically.

Examples:

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

Inline Elements

Elements that always stay on the same line and only take up as much width as needed are called Inline elements. They behave like small pieces of text inside a line.

Examples:

<span>Text</span>
<a href="#">Link</a>
<strong>Bold</strong>

Some Commonly Used HTML Tags

Conclusion

HTML is the foundation of every webpage. By using tags, we tell the browser what each piece of content represents, and by combining opening and closing tags, we create elements that form the structure of the page.

Once your HTML skeleton is solid, you can style it with CSS and bring it to life with JavaScript.

When you send a request to a server using cURL, the server doesn’t just send back data blindly. It returns a structured response that tells you what happened, what kind of data you got, and the actual content itself. Understanding this response format is essential for debugging APIs and backend systems. Once you can read a response properly, you can quickly figure out why something works or fails.

What is cURL?

cURL, which stands for “Client URL”, is a command line tool that lets you send and receive data over the internet. If your browser is a friendly graphical app that loads websites when you click links, cURL is the raw, text-based version of that idea. Instead of clicking buttons, you type commands in your terminal to make requests to servers and see their responses directly.

It’s a way to open a direct conversation between your computer and a web server. No UI, no buttons, just pure request and response.

Why programmers need cURL?

When you’re doing backend development or working with APIs, you often need to:

• Test an API endpoint

• Send data to a server

• See exactly what the server returns

• Debug why a request is failing

Using a browser hides a lot of details. Using cURL shows you everything.

For example, when you build an API in your own server (like with Node/Express), you can instantly test it with cURL without writing any frontend code. It’s fast, lightweight, and perfect for Debugging, Automation scripts, etc.

Making your first request using cURL

The simplest usage of cURL is:

curl https://example.com

When you run the above command, the following happens:

1. Your computer sends an HTTP GET request to https://example.com

2. The server responds with some data (usually HTML)

3. cURL prints that raw response directly in your terminal

You won’t see a rendered webpage like in a browser. You’ll see the actual HTML source.

Understanding Request

Every web communication has two parts: Request and Response. Let’s explore Request first. It contains things like:

• Method (GET, POST, PUT, DELETE, etc.)

• URL

• Headers

• Optional body (data you send to the server)

Example request in cURL:

curl -X POST https://api.example.com/users

The -X flag allows you to define the HTTP method (GET, POST, etc.) for the request.

Understanding Response

The server sends a response to your request which contains:

• Status code (like 200, 404, 500)

• Headers

• Body (JSON, HTML, text, etc.)

To see full details including headers, use:

curl -i https://example.com

The output will look something like this:

HTTP/2 200
date: Fri, 30 Jan 2026 13:04:11 GMT
content-type: text/html
...

<!doctype html><html lang="en">...</html>

Let’s break down the different components of a response:

Status Code

We can find a status code in the very first line, which in this example is 200. Status codes tell you whether your request succeeded or failed and why. Classes of Status codes are as follows:

Response Headers

Everything between the status line and the blank line is made up of headers:

date: Fri, 30 Jan 2026 13:13:51 GMT
content-type: text/html
cf-ray: 9c613aa01ac03b49-BOM
last-modified: Fri, 30 Jan 2026 05:47:18 GMT
...

Headers are metadata about the response. They tell you what type of data is in the body, when did the server generate the response, whatt server software handled the request, etc.

Response Body

After a blank line, the actual data begins:

<!doctype html><html lang="en">...</html>

This part is the real content you asked for. For websites, it’s HTML. For APIs, it’s JSON.

Conclusion

A server response is more than just what you see. The status code, headers, and body each give you important information. By learning to read all three parts, you gain full visibility into how your requests are handled. This makes cURL an incredibly powerful tool for testing and troubleshooting any web API.

DNS is a magical system powering the web invisibly. When you enter youtube.com in your browser, your browser does not know where to get the data to load up the YouTube website and render it to show you. This is where DNS comes in. It’s a system of multiple different servers around the world that help you find out the IP address associated with a particular domain name.

However, DNS isn’t just about getting the IP address to load up a website. DNS is much more than that. DNS has this thing called “records”. An IP address is simply one of those records. In this blog post, we are going to take a deep dive into what these DNS records are, why we even need them, and what the different types of records and their use cases are.

Pre-Requisites

I assume if you’re reading this blog post, you already know what domains are, why we need them, what DNS is, and how the DNS hierarchy works. If you do not, you can read my previous blog post that covers these exact concepts:

DNS Resolution Explained: How Websites Reach Your Browser

What are DNS Records?

DNS records, also referred to as entries in DNS zone files, are instructions that live in authoritative DNS servers. These provide different types of information about the domain name, such as:

• What IP address is associated with this domain?

• Which DNS servers are authoritative for this domain?

• Which mail server(s) receive emails for this domain?

Why Do We Need DNS Records?

DNS is just a system. It is nothing without DNS records. DNS records hold the actual information about a domain. Imagine listing a product on Amazon, but providing no details about it. This is exactly what DNS would be like without DNS records. Without DNS records, the DNS system would know that a particular domain exists, but wouldn’t know what to do with it.

DNS records are needed because

• they tell browsers where to go

• they tell email systems where to deliver mail

• they allow aliases and flexibility

• they prove ownership and improve security

DNS Records

A Record

This is the most fundamental DNS record. The A stands for “Address”, specifically an IPv4 address. An A record maps a domain name to an IPv4 address (e.g.: 142.250.70.78). This IPv4 address is the address of the server that is hosting the website associated with this domain name. This helps browsers know where to connect and fetch the website data from. Here’s an example:

AAAA Record

This record is very similar to the A record. It answers the exact same question. The difference is that an A record maps to an IPv4 address, whereas an AAAA record maps to an IPv6 address that looks something like 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Here’s an example:

NS Record

Remember the authoritative server in the DNS hierarchy? The NS record points to that. It tells the internet which name servers are authoritative for this domain. In other words, which name servers hold all the DNS records for this domain. Here’s an example:

CNAME Record

A CNAME record, which stands for Canonical Name, is quite simple. It helps us create an alias, like a nickname, to another domain. For example, you may create an alias where www.example.com points to example.com. So whenever someone tries to visit www.example.com, it will resolve to example.com.

Another use case is when we host a website on a managed hosting service like Vercel, Render, Netlify, etc. and get back a randomized domain name. We can take that domain and create a CNAME record in our DNS settings like this:

MX Record

I am sure you have seen those fancy emails that look like contact@example.com. We can create our own email addresses to receive emails based on our domain. And in order to do that, we use the MX record. It tells email systems where to deliver emails sent to contact@example.com. Here’s an example:

TXT Record

The TXT record is used for things like:

• Domain ownership and verification

• Email security (SPF, DKIM, DMARC)

• Service configuration

For example, when you deploy your website on a managed hosting service like Vercel, you usually connect your own domain to it using a CNAME record. But here’s the important part: anyone can create a CNAME record that points to a Vercel hostname, because that only requires knowing the target domain name.

So if that were the only step, someone could try to take your domain name and point it to their own Vercel project. To prevent this, Vercel needs proof that you actually control the domain you are trying to connect.

This is where TXT records come in. Vercel gives you a unique secret verification value and asks you to add it as a TXT record in your domain’s DNS settings, like this:

Only the person who has access to the DNS settings of example.com can add this TXT record. Vercel then performs a DNS lookup for this TXT record. If it finds the exact secret value it generated, it knows that the person connecting the domain really controls it.

Putting it All Together

A single website usually uses multiple DNS records at the same time, each solving a different problem. When you visit a website, this is what typically happens:

1. DNS asks the authoritative servers (defined by NS records) for information about the domain.

2. It follows any CNAME aliases if they exist.

3. It finally gets an A or AAAA record containing the server’s IP address.

4. The browser connects to that IP and loads the website.

5. Meanwhile, MX and TXT records quietly handle email and verification/security tasks in the background.

Conclusion

DNS records are the building blocks that tell the internet what to do with your domain. Some point your browser to the right server, some handle email, and others prove ownership and add security. Together, they turn a simple domain name into a fully working website and communication system.

Writing raw HTML can feel painfully slow. You type <div>, close it, add classes, nest elements, and repeat the same patterns again and again. It works, but it’s repetitive and time-consuming.

What if you could write one short line, and instantly get five properly nested list items?

ul>li*5

That’s exactly what Emmet does. It turns tiny shortcuts into full HTML structures, saving you tons of typing and effort.

What Emmet Is

Emmet is a shortcut language for HTML. You write a short abbreviation, press a key (usually Tab), and your code editor expands it into complete HTML. Think of it like autocomplete but with superpowers:

• You type less

• You get more code

• And it’s perfectly formatted

How Emmet Works Inside Code Editors

Most modern code editors like VS Code have Emmet built in. The flow is simple:

1. Type an Emmet abbreviation.

2. Press Tab (or Enter, depending on settings).

3. The editor replaces the abbreviation with full HTML.

You never leave your keyboard, and you don’t manually write opening/closing tags again and again.

Creating Elements

Single Element

Here is the simplest example:

• Emmet Abbreviation:

div

• Expanded HTML:

<div></div>

You just write the tag name. Emmet writes the full element.

Multiple Elements

Another example of creating multiple elements quickly is below:

• Emmet Abbreviation:

h1+p

• Expanded HTML:

<h1></h1>
<p></p>

The + means “next sibling element”.

Adding Classes, IDs, and Attributes

• You can add Classes, IDs, and attributes by using a CSS selector-like syntax.

Classes

• Emmet Abbreviation:

div.container

• Expanded HTML:

<div class="container"></div>

IDs

• Emmet Abbreviation:

section#hero

• Expanded HTML:

<section id="hero"></section>

Attributes

• Emmet Abbreviation:

input[type="text"]

• Expanded HTML:

<input type="text">

Combined Example

• Emmet Abbreviation:

button.btn.primary[type="submit"]

• Expanded HTML:

<button class="btn primary" type="submit"></button>

Creating Nested Elements

You can use > to put one element inside another.

• Emmet Abbreviation:

ul>li

• Expanded HTML:

<ul>
    <li></li>
</ul>

Deeper Nesting

• Emmet Abbreviation:

div>ul>li

• Expanded HTML:

<div>
    <ul>
        <li></li>
    </ul>
</div>

Each > means “go one level deeper”.

Repeating Elements Using Multiplication

You can use * to repeat elements.

• Emmet Abbreviation:

ul>li*3

• Expanded HTML:

<ul>
    <li></li>
    <li></li>
    <li></li>
</ul>

Generating Full HTML Boilerplate

You can create a complete HTML boilerplate with one word.

• Emmet Abbreviation:

!

• Expanded HTML:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Document</title>
    </head>
    <body></body>
</html>

Conclusion

Emmet turns slow, repetitive HTML writing into a fast, almost conversational process. By learning a few simple symbols like >, +, ., #, * and !, you can generate complex structures in seconds.

Start small, use it daily, and soon typing full HTML by hand will feel outdated.

Imagine you’re sitting down for dinner and you open youtube.com on your phone, laptop, or TV to watch something while enjoying your meal. Now, unless you’ve been living under a rock, you know you need an active internet connection to open a website like YouTube. That’s because the website is hosted on a remote server (just a fancy name for a computer that serves data over the internet).

But have you ever wondered how your computer, which only understands 0s and 1s, is able to find the exact remote server that hosts youtube.com, among billions of other servers on the internet?

What are Domains?

We don’t remember phone numbers of our friends and family members anymore. We simply look up their saved contact in our phones. If you think about it, your contacts app simply maintains a mapping of your friend’s name to their phone number. This saves you the hassle of remembering the phone numbers of all your friends, family members, etc.

Now coming to the point, you might have already heard the term “IP addresses” in cool hacker movies 😎. They look something like this: 142.250.70.78. An IP address is like a phone number, a unique identifier for every device on the internet. So your smartphone has a unique IP address, your computer has a unique IP address, and even your smart refrigerator has one! Likewise, the YouTube server also has an IP address. Since these IPs are unique, if we somehow get our hands on the IP address of YouTube’s server, we will be able to contact the server and ask it for all the data we need to load up the YouTube website in our browser.

And this is where the problem arrives. We, as humans, who can’t even remember 10 phone numbers normally, can surely never remember the IP addresses of billions of websites out there! The solution is domains. A domain like youtube.com is simply a user-friendly name that we can remember instead of something like 142.250.70.78. This is just like how we save our friend’s phone numbers with their name, so that we don’t have to remember such long numbers.

Anatomy of a Domain

Here’s how a domain name is structured (subdomain, SLD, and TLD):

What is Name Resolution?

Now that we know what domains are, we need to understand this fancy term called “Domain Name Resolution.” Just like I explained in the previous section, domains are surely easy to remember, however we need a process that converts these domains to their IP addresses, so that when we enter a website’s domain, the browser can find its IP address and load the website up for us. This process is called Name Resolution, since we are “resolving” the domain name to its IP address.

DNS: The Contacts App of the Internet

DNS stands for Domain Name System. For now, you can think of it as a server that maintains a mapping of a website’s domain name, for example, youtube.com, to its IP address. This means whenever you type youtube.com in your browser, it simply reaches out to a DNS server, asks for its IP, and then goes and gets all the website data from the server having that IP.

However, this is just a high-level overview. In reality, this process is much larger, involving multiple different steps and many different types of DNS servers.

The DNS Hierarchy

Now that you have a high-level understanding of what domains are, why we need them, and how DNS resolves a domain to an IP address, let’s deep dive into the series of steps that happen behind the scenes whenever you enter a website’s domain name in your browser.

Component 1: Browser

When you enter a domain name in your browser (for example, youtube.com), the browser first checks its own DNS cache before making a request anywhere. This is because you may have visited that website before, and the browser might have cached its IP address to save time in the future.

If the IP is found in the cache, there’s no need to reach out to any DNS server. The browser can directly connect to the website’s server and fetch the required data.

Component 2: Stub Resolver

A stub resolver is a small DNS client built into your operating system. Its job is very simple. It receives the DNS query from your browser and forwards it to a recursive DNS resolver.

Component 3: Recursive DNS Resolver

This is the most important component in the DNS hierarchy. A recursive DNS resolver is a type of DNS server whose job is to find the IP address of a domain by contacting other DNS servers step-by-step until it gets the final answer.

As you can see in the diagram, it acts like a middleman between your browser and the rest of the DNS system. However, before making any further requests, the recursive resolver also checks its own cache. If it already has the IP address stored (and the TTL hasn’t expired), it saves time and simply returns the cached answer.

Component 4: Root Server

Root servers are the topmost DNS servers in the hierarchy. They do not know the IP addresses of websites like youtube.com. However, they do know where to find the next step.

When the recursive resolver asks a root server about youtube.com, the root server looks at the Top-Level Domain (TLD) part (.com) and responds with a referral to the TLD name servers responsible for .com.

In simple words, the root server responds with something like:

“I don’t know the IP for youtube.com, but here are the DNS servers that manage .com.”

Component 5: TLD Server

After getting referred to the .com TLD servers, the recursive DNS resolver contacts one of them. The TLD server checks the Second-Level Domain (SLD) in the query (like youtube in youtube.com) and responds with the authoritative name servers for that domain.

So the TLD server basically says:

“I don’t know the final IP either, but here are the authoritative servers for youtube.com.“

Component 6: Authoritative Server

Authoritative DNS servers are the final source of truth for a domain. These servers are usually managed by your DNS provider/host like Cloudflare, GoDaddy, Hostinger, etc.

They store different DNS records for your domain, such as:

• A/AAAA (IP address)

• CNAME

• MX, etc.

The recursive resolver reaches out to the authoritative server and asks for the A (or AAAA) record of the domain. This record contains the IP address of the server hosting the website.

Finally, this IP address is returned to your browser, and your browser can then connect to the website’s server and fetch the actual website data.

Summary

The entire process can be summarized as the quest for finding the A record of the domain name you entered. That A record can either be in your browser cache, or in the DNS resolver’s cache, or the resolver may have to do the entire process step-by-step, querying each server and finding the next location every time, in order to find it.

Also, do note that this entire process only finds us the IP address of YouTube’s server. This does not fetch the data of YouTube’s website itself. That is done after the browser receives the IP address from this process.

dig: A DNS Diagnostic Tool

Before finishing, let’s take a quick look at dig. dig is a very useful command-line utility, that you can use to query DNS servers. By using dig, you can find out things like:

• What IP address is associated with this domain?

• Which DNS servers are authoritative for this domain?

• Which mail server(s) receive emails for this domain?

Querying for an IP Address

In order to fetch the IP address of a domain, you can simply run the following command:

dig youtube.com

In the output, you will see a section like this:

;; ANSWER SECTION:
youtube.com.		153	IN	A	142.250.70.78

This is YouTube’s IP address.

Querying a Specific DNS Record

We can also query for a particular record by doing:

dig youtube.com NS

The output would look something like this:

;; ANSWER SECTION:
youtube.com.		238608	IN	NS	ns4.google.com.
youtube.com.		238608	IN	NS	ns2.google.com.
youtube.com.		238608	IN	NS	ns3.google.com.
youtube.com.		238608	IN	NS	ns1.google.com.

Querying a Specific DNS Server

We can also query a particular DNS server. For example, now that we know the nameservers of youtube.com, let’s query a specific one to get the A record:

dig @ns4.google.com youtube.com A

The output would look like this:

;; ANSWER SECTION:
youtube.com.		300	IN	A	142.250.207.206

Fetching the Root Servers

We can fetch all 13 root DNS servers by doing this:

dig . NS

The output would look like this:

;; ANSWER SECTION:
.			205024	IN	NS	a.root-servers.net.
.			205024	IN	NS	b.root-servers.net.
.			205024	IN	NS	c.root-servers.net.
.			205024	IN	NS	d.root-servers.net.
.			205024	IN	NS	e.root-servers.net.
.			205024	IN	NS	f.root-servers.net.
.			205024	IN	NS	g.root-servers.net.
.			205024	IN	NS	h.root-servers.net.
.			205024	IN	NS	i.root-servers.net.
.			205024	IN	NS	j.root-servers.net.
.			205024	IN	NS	k.root-servers.net.
.			205024	IN	NS	l.root-servers.net.
.			205024	IN	NS	m.root-servers.net.

Conclusion

DNS is indeed a magical system powering the web invisibly. It is not a single server, but an entire system of servers that help your browser get the associated IP address for a domain. These IP addresses are sharded around the world, distributed across multiple servers based on the TLD, authoritative servers, etc. And the DNS resolver does the job of recursively finding out the next location in the DNS hierarchy until we find the A record.

Git was created by Linus Torvalds (the creator of the Linux kernel) in April 2005, as a system for managing the Linux codebase over time. He created the initial version of Git in a very short time span of 10 days! Fast forward to 2025, over 90% of developers use this amazing software in every project, multiple businesses have been built around it, such as GitHub, GitLab, etc., and it has truly revolutionized writing software forever. Imagine creating the foundation of an entire system that will change coding forever, only in a span of 10 days!

However, many of us developers still do not understand how Git actually works internally. The understanding about the internals of Git is surely not going to help you in your day-to-day git activities, but it will make you a better engineer overall, helping you to understand the thought process behind such a robust system.

Pre-Requisites

I assume if you’re reading this blog post, you already know about what Git is, what problem does it solve, the basic git workflow and some basic commands too. If you do not, you can read my previous blog posts that cover these exact concepts:

1. Why Version Control Exists: A Video Game Perspective

2. Learning Git Commands Through Video Game Mechanics

Once you know these concepts, you will be ready to deep-dive into the mysteries of Git!

Porcelain vs Plumbing Commands

All the Git commands are divided into 2 categories:

1. Porcelain Commands: These are high-level, friendly commands that we actually use in our day-to-day Git usage. You might already be familiar with some of these commands like init, add, commit, status, etc.

2. Plumbing Commands: These are low-level internal commands that are not meant for daily use. They can be used to inspect/manipulate Git internals. Some of these commands are hash-object, cat-file, write-tree, etc.

It is also important to understand that the Porcelain commands that we use in our day-to-day Git usage, are simply a high-level abstraction on top of one or more Plumbing Commands. In other words, they are built on top of one or more Plumbing commands only.

The .git Directory: Git’s Brain

The first command you run in order to start using Git in any project is:

git init

This simple porcelain command essentially converts your normal folder holding together a bunch of random code files, into a proper git source code repository. But how does git do it?

When you run this command, Git adds a hidden directory called .git at the root of your project directory. You can confirm this using the following command on unix terminals:

ls -a

This command will basically list out all the files and folders in that directory, including hidden ones (because of the -a flag). The output would look something like this:

.  ..  main.c  .git

And that is literally it! A single directory is all that’s needed to manage all the files of your projects, every commit you make, every branch you make, every merge you do, literally everything! Let’s see how.

Anatomy of the .git Directory

The .git directory consists of several files and sub-directories that have specific purposes in Git’s overall design. A high-level overview of the directory would look something like this:

.git/
├── objects/
├── refs/
│   └── heads/
│       ├── main
│       ├── feature1_branch
│       └── feature2_branch
├── HEAD
├── index
└── config

There are a bunch of other files and directories too, but we will focus upon these for now.

How Git Stores Data?

Git is a content-addressable file system. This means that Git stores data by using the content itself as the “address” (ID). That address/ID is more properly referred to as a “hash” in Git terminology.

So for example, if you have the following content in any of your files:

Hello World

Then Git will generate a hash for this content that would look something like this:

0a4d55a8d778e5022fab701977c5d840bbc486d0

Technically, Git hashes the content along with a small header (object type + size).

Objects: Git’s Driving Force

Now that we understand that Git stores data using hashes, we need to understand: What exactly is Git storing behind those hashes? The answer is: Git stores everything as objects. Every commit you make, every file, and every folder structure is represented using Git objects, which are stored in the .git/objects directory.

Git primarily works with three main types of objects:

Blob (Binary Large Object)

Blob objects store the actual contents of your file. They do not store any metadata, no filename, no path, no permissions, nothing other than the contents of your file.

Do note that the contents of your files are not simply copied over to the .git/objects directory as blob objects. Instead, Git creates a blob object for the content and stores it in a compressed format (using zlib) to save space.

The following plumbing commands can be used on blob objects:

git cat-file -p blob_hash   # shows original content
git cat-file -s blob_hash   # shows uncompressed size

Tree

Tree objects store the actual directory structure. They store a mapping that looks like this:

100644 blob a1b2c3  main.cpp
040000 tree d4e5f6  src

The above output uses the format :

mode object_type hash filename

Basically, trees map blobs to their filenames. Trees also map sub-trees (i.e. sub-directories) to their corresponding tree objects.

The following plumbing command can be used to view a tree object tied to a particular commit:

git ls-tree commit_hash

In simpler words, a tree represents a directory and can point to:

• blobs (raw file content)

• other trees (sub-directories)

Commit

A commit object stores the snapshot, the history, and all the metadata. The following plumbing command can be used to view a commit object:

git cat-file -p commit_hash

The output would look something like this:

tree root_tree_hash
parent parent_commit_hash (0 or more)
author name email timestamp
committer name email timestamp

commit message

Relation Between all the Objects

• Commits define history.

• Trees define structure.

• Blobs define content.

A commit points to exactly one tree. That tree represents the entire directory structure of the repository and also further points to blobs which hold the actual data.

Other Parts of the .git Directory

Let’s quickly go over the other files and directories of the .git directory:

refs

refs is a directory with the following structure:

refs/
└── heads/
    ├── main
    ├── feature1_branch
    └── feature2_branch

These files represent different branches and store the hash that points to the latest commit in the respective branches.

HEAD

This is a file that simply stores the name of the current branch. If your current branch is main, the HEAD file’s content would be this:

ref: refs/heads/main

index

This is a file that represents the Git staging area. It stores information about the files you’ve added using git add, so Git knows what exactly to include in the next commit.

config

This is a file that stores repository-specific settings, like the remote URL (origin), default branch, and other local configurations.

Internal Flow of git add and git commit

Staging

1. Let’s say you edit a file called file.txt in your working directory and run the git add file.txt command.

2. Git reads the content of the file, compresses it, and stores it as a blob object inside the .git/objects directory. Do note that if the same content already exists, Git just reuses the existing blob hash, without creating a new one.

3. Git updates the index i.e., the staging area. It simply adds a record in the .git/index file, which basically states “For file.txt, the staged version is this blob hash”.

Committing

1. After the staging phase is over, and you run the git commit command, Git first reads the staging area (index) with the aim of turning it into a permanent snapshot in Git history.

2. Git converts the staging area into a directory structure and creates a tree object.

3. Git creates a commit object that stores:

   • the tree hash (snapshot)

   • the parent commit hash (previous commit)

   • author info + timestamp

   • commit message

4. Git moves the branch pointer by updating the .git/refs/heads/branch_name file, to make sure that particular branch now points to the new commit hash.

Summary

• Commit → points to a tree → points to blobs and sub-trees

• Refs/branches → point to commits

• HEAD → tells which branch you’re on

Conclusion

Git might look like magic from the outside, but internally it’s built on a very simple idea: store everything as objects, and reference them using hashes. Once you understand blobs, trees, commits, and how files like HEAD, refs, and index work together, Git starts to feel a lot less mysterious.

Have you ever died in a video game and worried about losing all your progress? If you didn’t have a saved state, chances are you’ve smashed your keyboard in frustration 😶.

But if you did have a save point, you know how easy it is to jump right back in from the last checkpoint and keep playing like nothing happened 😎. That’s exactly what Git is for your code, a “save game” system that lets you rewind mistakes, experiment freely, and never fear losing hours of work again.

I’ve explained Version Control Systems from the ground up in my previous blog post, why they exist, the problems they solve, and how Git and GitHub fit into the picture, all using video game analogies to make things easier to understand. If you haven’t read it yet, you can check it out here:

Why Version Control Exists: A Video Game Perspective

What is Git?

I’ve already covered this in detail in a previous blog post, so let’s quickly brush over the key points.

• Git is a local software you use to keep track of changes in your code.

• It also keeps tracks of who made what changes (so you know who to blame 😉).

• It also keeps track of every version of your project, meaning no more folders named final, final_v2, or final_final 😮‍💨.

• Git is a distributed system, which means every developer has their own complete copy of the project and its history.

• You interact with Git mainly through the command line (or GUI tools… but where’s the fun in that?).

What Git is not?

• Git is not an online platform.

• Git is not GitHub. They are completely different things.

• Platforms like GitHub are simply associated with Git and extend its functionality by providing:

  • shared remote hosting

  • an easy way to collaborate with others

• Git itself works perfectly fine on its own, without the internet.

Demystifying Git Jargon

Repository

In layman’s terms, a repository refers to the source code folder that Git is tracking. We have to initialize Git within a folder, which essentially tells Git to start tracking all the files inside that folder and makes that folder a “repository”. Git adds a hidden .git folder inside it, where it stores everything, such as the complete history, metadata, and references to remotes, etc.

Commit

In our video game analogy, you can think of a “commit” as a “saved state”. It is simply a snapshot of your code at a given point in time. You can create many commits in a series, which basically build out a timeline of commits, allowing you to jump back to a specific commit whenever you want.

Commit Hash

Whenever you create a commit, a unique number is generated and associated with that commit like an ID. That unique ID is called a “Commit Hash”. It is a 40-character hexadecimal string.

HEAD

HEAD is a pointer that refers to the current commit you are working on. It simply represents your current position in the entire timeline of commits.

Staging Area

Before you take a snapshot of your new changes, or in Git terminology, before you “commit” your new changes, you first have to add them to a staging area. It is simply a convenience feature that allows you to review and prepare all the files before making a commit.

Branch

You know how many games provide multiple different save slots, so that you and your brother can both grind the story at the same time without conflicting with each other’s progress? Git has a feature like that too.

Git allows you to create several “branches”, which are like separate timelines of their own. Want to try out a new feature? Simply create a feature branch. If it works, merge it into the main branch. If not, delete it. Your original code remains intact in the main branch.

Main/Master

This is simply the default name of the base branch. Previously, it used to be called master. Now, it is called main.

Remote

A remote is a reference to another copy of the repository that is hosted at a remote location (usually GitHub).

Origin

origin is the default name Git gives to the main remote repository.

Git Workflow

1. Initialization: You initialize Git within your source code folder and convert your ordinary folder into a Git repository.

2. Staging Files: After adding, modifying, or creating new files, you stage them in the Git staging area.

3. Commit: After making sure you have staged everything properly, you commit the staged files, which essentially makes a proper snapshot of your code that you can return to if needed.

Installation

You can install Git by going to the following website and following the instructions as per your operating system:

https://git-scm.com/install/

After the installation, open up your terminal and run the following command to verify the installation:

git --version

If you do get a version number in the output, you’re in the clear!

Essential Commands

Initialize a Git Repository

This is the first command you need to type to turn a regular source code folder into a “git repository.” Once you type this command, you can then use the other Git commands to manage your codebase.

git init

Add Files to the Staging Area

Use the following command to add new or modified files to the Git staging area:

git add fileName1 fileName2

If you want to add all the new and modified files, you can simply run:

git add .

Commit Files: Save the Game

Once you have modified and added the files you want to save to the staging area, use the following command to make a proper “commit”, i.e., take a screenshot of the current state of your codebase:

git commit -m "some message here that describes the commit"

You can both add and commit in a single command using the -a flag. However, do note that this combined way only works for the tracked files, i.e., the files Git already knows about and is tracking. It won’t work for files you have added newly and are untracked yet.

git commit -am "some message here that describes the commit"

It’s just like saving your game and letting out a sigh of relief 😮‍💨, knowing you can come back to this point if you need to.

Retrieving Logs

You can see all the commits you have ever made in a Git repository by simply running the following command. It displays the commit hash, the author who made the commit, the date and time of the commit, along with the message.

git log

If you want to see a concise output with just the commit hash and the message, you can use the --oneline flag:

git log --oneline

If you want to see the logs in a graph timeline manner, you can use the --graph flag:

git log --graph

Status

The status command shows you the current status of your Git repository, such as the branch you’re on, untracked (new) files, files added to the staging area, modified files, deleted files, renamed files, etc.

git status

The -s flag can be used to display a more concise, short-format output:

git status -s

The output that you’ll receive with the -s flag uses the following status codes:

A  : Added
M  : Modified
D  : Deleted
R  : Renamed
?? : Untracked
!! : Ignored

Compare Commits

You can run the following command to compare two commits and check out the differences between them:

git diff commitHash1 commitHash2

You can also run this command without the hashes to simply compare your working directory with the last staged version (index). However, do note that this only shows the tracked files, i.e., the files Git already knows about and is tracking. It won’t show files you have added newly and are untracked yet.

git diff

Reset Your Changes: Load an Old Game State

Let’s say you messed some code up and want to restart from an old state, just like you would in a video game after dying. Don’t worry, all those commits you made are like checkpoints that you can time travel to with the following commands.

• Reset a staged file:

git reset fileName

• Reset all staged files (clear the entire staging area):

git reset

• Reset a defined number of commits:

git reset HEAD~1

• Reset up until a particular commit:

git reset commitHash

• You can also use the --hard flag to reset and also discard all the changes in the working directory:

git reset --hard commitHash

Reset Changes by Creating a New Commit

There is another command called revert that resets the commits for you but also preserves the history. The following command will apply the inverse of the commit mentioned.

git revert commitHash

Conclusion

Git might look intimidating at first, but at its core, it’s simply a powerful save game system for your code. It gives you the confidence to experiment, break things, and explore new ideas, knowing that you can always jump back to a previous checkpoint if something goes wrong.

My recommendation would be to start using Git for every project you create henceforth. Once you start using commands like add and commit to save your game 😎, and revert to restart once you mess your codebase up 😶, eventually they will become muscle memory to you!

Imagine you just started playing your favorite video game, GTA, and were greeted with this legendary scene:

You played the game for hours, completing mission after mission. But then, you failed a mission badly and wanted to reload from the last mission to try again with a fresh start. And then it hits you, what if you hadn't saved your game? 😵 This is exactly the kind of problem Version Control Systems like Git solve for developers.

Problems Faced Before Version Control Systems

Lack of a “Load Game” Feature

Imagine you're developing a feature for your new, shiny todo app 😎. After several days of work, it didn't meet your expectations. You want to revert to your previous codebase and start over. Without version control systems, you'd have to manually delete various lines and files, which is tedious and error-prone. A VCS like Git gives you a simple command that will help you revert to your previous codebase instantly. This is just like being able to load your old game state and play again!

Lack of a Collaboration System: The Pendrive Problem

You realize you cannot implement this new feature alone and decide to bring in your friend, who just completed his calculator app 😎. You zip the entire codebase and share it via pendrive or email. Your friend makes changes and returns it the same way. The problem? There's a high risk of code conflicts since you both might modify the same files. Additionally, there's no system to track changes from all developers, making it difficult to merge everything back into a single codebase.

Lack of Accountability

Let’s say your friend, who is trying to add a new feature to your todo app, accidentally breaks some existing features. He sends the code back to you via a pendrive or email. Meanwhile, you've made your own changes, and now you merge everything together. After merging, your app doesn’t work anymore! 😵 And there's no way to tell if it was you or your friend who broke the code! It’s like playing Call of Duty with your friends and not knowing who stole your kill 😶.

Poor Versioning

Have you ever named your app versions final, final_v2, and even final_final? Without version control systems, it was very hard to keep track of all the versions and the changes those versions had. This forced developers to do the one thing they are notoriously bad at: naming things 🫣.

Solution: Version Control Systems

As the name suggests, a version control system is software whose primary job is to track, manage and control changes to your files, typically your source code, over time. It solves all the problems mentioned above by:

• allowing you to revert your codebase to a previous state, like a “load game” feature

• making collaboration easy through online platforms like GitHub

• maintaining accountability by recording who made which changes (so you know who to blame 😉)

• keeping track of all versions for you, so you don’t have to give your project random names anymore 😮‍💨

Git: Time Machine for Developers

Git was created by Linus Torvalds (the creator of the Linux kernel) in April 2005, as a system for managing the Linux codebase overtime. In simpler words, we can think of it as a “Code Tracker”. Git is usually used through commands in the terminal (or via GUI tools), but we’ll focus on what it does, not how yet. Git is an example of a VCS (Version Control System). There are many other VCSs out there as well, like Mercurial, Apache Subversion (SVN), and Fossil, just to name a few. However, Git is the most popular one.

It is important to understand that Git is purely a local software. This means that it is software you run locally on your computer, and it simply keeps tracks of all the changes in your code, who made what changes and when, etc. It is designed to be used by a single developer on their local machine. This makes Git only a piece of the solution. It does solve many problems, but it is not complete since you would still have to share your Git-managed codebase via a pendrive, email, etc.

GitHub: The Central Source of Truth

GitHub is an online platform built on top of Git. It is like a central place where your entire Git-managed codebase is stored. This makes it easier for other developers to simply “pull” (download) the entire codebase from the internet, make changes, and “push” (upload) the modified codebase back. GitHub is what we call a VCS Remote. And again, it is not the only one, there are other such online platforms out there like GitLab, BitBucket, GitTea, etc.

Important Note: Git ≠ GitHub

Many beginners confuse Git and GitHub thinking they are the same. However, based on the above explanations, you might have understood that they are vastly different.

Analogy: If Git is the save and load game feature for your codebase, GitHub is the central server that enables you and your friends to play the game together!

Resources to Learn About Git and GitHub

• The official Git documentation: https://git-scm.com/docs

• GitHub Skills: https://skills.github.com

Conclusion

Version Control Systems are systems built by developers for developers. Developers realized how difficult it was to manage their codebase, track changes, and work on it collaboratively, so they came up with an efficient solution. One piece is Git, which is the local system keeping track of the entire codebase. The second piece is GitHub, an online platform to host Git repositories, making it easier to work collaboratively.

Learning how to efficiently use Git and GitHub is essential for every developer today. It is not a fancy tool that developers can use to brag about, instead, it is an essential tool born out of necessity.