DEV Community: Faizan Firdousi

Build a Container from Scratch in Go (Modern Namespaces + cgroup v2)

Faizan Firdousi — Wed, 18 Feb 2026 15:38:24 +0000

So I made a container from scratch in Go with the minimum number of lines of code possible and learned various things that usually happen inside a container and that is what Docker abstracts away.

Although you may get other articles about the same, I wrote this because of some changes in the Linux kernel, the blogs got somewhat deprecated in terms of understanding and implementation of code.

What are containers?

Let's understand what containers are. As you already might know, fundamentally, containers are "about bundling up dependencies so we can ship code around in a repeatable, secure way."

But let's understand the underlying concepts - Namespaces, Cgroups, and Filesystem isolation that make containers what they are.

Namespaces

Linux namespaces are a fundamental kernel feature that provides resource isolation so different sets of processes see different sets of resources.

Namespaces are very important, as we will see further how much we are going to use them because they're the core technologies containers are built on. So whenever you create containers with Docker or Podman, it automatically creates namespaces on your behalf.

Namespaces primarily are of 6 types (note that we will cover them more while coding the container, as that is how I like learning by making things so I'm not bombarding you with a lot of information firsthand):

PID - Assigns independent process IDs. The first process in a new namespace gets PID 1.
Network - Provides an independent network stack via virtual ethernet pairs.
MNT - Maintains an independent list of mount points, allowing filesystem mounts/unmounts without affecting the host.
USER - Has its own user IDs and group IDs, allowing a process to have root privilege within its namespace without having it elsewhere.
IPC - Isolates interprocess communication resources like POSIX message queues.
UTS - Allows different host and domain names for different processes on the same system.

Cgroups

While understanding cgroups and knowing on the surface level what cgroups do is very easy it basically means control groups, it's a Linux kernel feature that limits, accounts for, and isolates the resource usage including CPU, memory, disk I/O, and network of collections of processes.

We can talk a lot about cgroups, but I'll stick to the basics required for implementation, and don't worry, I'll talk about it more again down further.

Let's name the phases of code as it will be beneficial to go one by one, understanding deeply.

here's the github link for full code(please give a star)-
https://github.com/faizanfirdousi/container-from-scratch

Phase 0

First, let me clarify what we're doing here exactly our main goal is to create a container that is isolated from the host machine. In other words, we're building a sandboxed environment that runs a shell with its own filesystem, process namespace, and resource limits, giving it strong isolation from the host.

The container can be of anything. Here, for simplicity, we are going to have an Alpine Linux container as it's smaller in size and also has full components that give the feel of a whole system. At the end, we will create a container or basically a process that thinks the Alpine directory is the entire computer.

For that, we need to have the root filesystem of Alpine, so set this up before starting to code:

# Download and extract Alpine Linux rootfs
docker export $(docker create alpine) -o alpine.tar
mkdir -p /home/faizan/alpine-rootfs
tar -xf alpine.tar -C /home/faizan/alpine-rootfs

If you don't have Docker, then install it via curl. I just used it for simplicity.

Phase 1

First, we're going to create a simple program that runs commands*but it won't have any isolation yet*. This might seem counterintuitive, but there's a good reason: by seeing what happens without isolation, you'll truly understand what each isolation primitive does when we add it later.

package main

import (
    "fmt"
    "os"
    "os/exec"
)

func main() {
    if len(os.Args) < 2 {
        fmt.Fprintf(os.Stderr, "Usage: %s run <cmd> [args...]\n", os.Args[0])
        os.Exit(1)
    }

    switch os.Args[1] {
    case "run":
        run()
    default:
        panic("Unknown command")
    }
}

func run() {
    fmt.Printf("Running %v\n", os.Args[2:])

    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    must(cmd.Run())
}

func must(err error) {
    if err != nil {
        panic(err)
    }
}

What this code does

The program starts by checking the arguments passed to it. The first argument must be run, which tells our program that we want to execute a command. Everything after run becomes the actual command and its arguments that we want to execute for example, /bin/bash or /bin/sh.

When the run function is called, it uses Go's exec.Command to create a new process. The way this works is straightforward: os.Args[2] contains the command itself (like /bin/bash), and os.Args[3:] contains any additional arguments you want to pass to that command. The ... syntax spreads those arguments out so they're passed individually to the command.

We then connect the standard input, output, and error streams. This is important because it allows the command to interact with your terminal naturally. You can type input and see output just like you would with any normal command. Finally, cmd.Run() actually executes the command and waits for it to complete.

Test

go run main.go run /bin/bash

You should see something like this:

Running [/bin/bash]
[root@archlinux cfs]#

Test if it's isolated by running commands like ps and hostname.

Now let me show you what happens when I test this. Run ps inside the shell and look closely at the output.

Notice something interesting? The PIDs are not starting from 1 like they would in a real container. Instead, you're seeing PIDs like 46628, 46629, 46669 ,these are the exact same process IDs that the host system sees. If you open another terminal window on your host and run ps aux there, you'll see the exact same PID values. This proves we're sharing the same process namespace as the host.

Now let's check the hostname.

Run hostname and you'll see your machine's actual hostname. Try changing it with sudo hostname test-container, then run hostname again to confirm it changed. Exit the shell and check your host's hostname, it's been changed there too! We just modified the host system's hostname directly. There's no isolation barrier protecting the host from changes made inside our "container."

The same goes for the filesystem. When you run ls /, you're looking at your actual host's root directory. Any file you create in /tmp will appear on the host. We're operating directly on the host system with zero separation.

Why This Matters

What we've built right now is basically just a wrapper that executes commands, there's no containerization happening at all. But this baseline is important. In the next steps, when we add Linux namespaces, you'll see how dramatically things change. The PIDs will start from 1, hostname changes won't affect the host, and we'll have our own isolated filesystem.

Phase 2

Now update the run() function to look exactly like this:

func run() {
    fmt.Printf("Running %v\n", os.Args[2:])

    // Re-exec ourselves as "child" inside new namespaces
    cmd := exec.Command("/proc/self/exe", append([]string{"child"}, os.Args[2:]...)...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    cmd.SysProcAttr = &syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS,
        Unshareflags: syscall.CLONE_NEWNS,
    }

    must(cmd.Run())
}

And add this new child() function:

func child() {
    fmt.Printf("Running %v as child\n", os.Args[2:])

    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    must(syscall.Sethostname([]byte("container")))

    if err := cmd.Run(); err != nil {
        fmt.Println("Process exited:", err)
    }
}

Let's understand what we're doing here. First, we need to create namespaces. Before that, we write this in run():

cmd := exec.Command("/proc/self/exe", append([]string{"child"}, os.Args[2:]...)...)

This is the critical insight: We're not running /bin/bash directly. Instead, we're re-executing our own Go program (/proc/self/exe is the path to our currently running binary) but with a new argument list: ["child", "/bin/bash"].

Why this weird self-re-execution? Because Linux namespaces can only be created when spawning a NEW process, you cannot create namespaces for a process that's already running. So we need our code to run again, but this time inside fresh, isolated namespaces.

Then we actually create the namespaces using this code:

cmd.SysProcAttr = &syscall.SysProcAttr{
    Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS,
    Unshareflags: syscall.CLONE_NEWNS,
}

As I told you at the start of the blog, different namespaces isolate different things. What we're doing here is creating namespaces using Linux system calls. Specifically, we're using the clone() system call with special flags.

The system calls we're using are the CLONE_* family. Each CLONE_NEW* flag tells the Linux kernel: "When you create this child process, put it in a completely separate namespace for this resource." Let me break down what each one does:

CLONE_NEWUTS creates a new UTS (Unix Time-Sharing) namespace. This isolates the hostname and domain name. With this flag, when the child process changes its hostname to "container", the host machine's hostname stays completely unchanged. Without this, changing the hostname inside would affect your actual host system exactly what we saw in Phase 1.

CLONE_NEWPID creates a new PID (Process ID) namespace. This is huge. It means the child process gets its own, completely separate process ID numbering system. Inside the container, the shell will see itself as PID 1—the first process, just like the init system in a real Linux boot. But from the host's perspective, that same process might be PID 15234. This is why when you run ps aux in a real container, you only see the container's processes, not all the host processes.

CLONE_NEWNS creates a new Mount namespace. This isolates filesystem mount points. Any mounts we do inside the container (like mounting /proc or /tmp) won't appear on the host system, and vice versa. This is crucial for filesystem isolation.

The | (pipe) symbol between these flags is a bitwise OR operation—it's how we enable multiple namespaces at once. We're essentially saying "create ALL THREE of these namespaces for the child process."

Unshareflags with CLONE_NEWNS is an additional safety measure. It makes the mount namespace "unshareable" to prevent mount propagation, basically ensuring that any filesystem changes inside the container absolutely cannot leak to the host.

Test

Now let's test if our namespace isolation is actually working. Run your updated code:

You should see:

Running [/bin/bash]
Running [/bin/bash] as child
[root@container cfs]#

You will notice that the hostname in your prompt already shows container—that's the Sethostname call working.

Now check if hostname changes stay isolated by changing the hostname of the container and checking if the host's hostname also changed.

Now check the PID namespace isolation - this is interesting and important.

Inside the container, run:

echo $$

On your host (different terminal):

ps aux | grep bash

Same process, two different PIDs! Inside the namespace it's PID 7 (can be different but a low number for you), from the host it's PID 44999. This proves PID isolation is working.

Test The /proc Problem

Run ps inside the container:

ps aux

You'll see all the host's processes—systemd, kthreadd, Chrome, everything. Why? Because even though we have PID namespace isolation, we're still reading the host's /proc filesystem. The ps command gets its information from /proc, which we haven't isolated yet.

Phase 3

Update your child() function to add filesystem isolation. First, add environment variables right after the cmd setup:

func child() {
    fmt.Printf("Running %v \n", os.Args[2:])

    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    // Add these environment variables
    cmd.Env = []string{
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        "HOME=/root",
        "TERM=xterm",
    }

    must(syscall.Sethostname([]byte("container")))

    // Add filesystem isolation
    must(syscall.Chroot("/home/faizan/alpine-rootfs"))
    must(os.Chdir("/"))

    // Mount /proc filesystem
    must(syscall.Mount("proc", "proc", "proc", 0, ""))

    // Mount tmpfs at /tmp
    must(os.MkdirAll("tmp", 0755))
    must(syscall.Mount("tmpfs", "tmp", "tmpfs", 0, ""))

    if err := cmd.Run(); err != nil {
        fmt.Println("Process exited:", err)
    }

    // Cleanup mounts on exit
    syscall.Unmount("proc", 0)
    syscall.Unmount("tmp", 0)
}

Environment Variables

cmd.Env = []string{
    "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
    "HOME=/root",
    "TERM=xterm",
}

This is a small but important detail. When a child process is spawned, by default it inherits the parent's environment variables, which means it would inherit your host's PATH, your host's HOME, all of it. That's a problem because after we do the filesystem isolation in the next step, those host paths won't even exist inside our container.

So we're explicitly setting a clean, minimal environment. PATH tells the shell where to look for binaries. HOME sets the home directory. TERM=xterm makes sure terminal behavior works correctly, things like clearing the screen, arrow keys, color output. Without TERM, a lot of terminal programs behave weirdly or refuse to run.

Chrooting (the important step)

must(syscall.Chroot("/home/faizan/alpine-rootfs"))
must(os.Chdir("/"))

chroot redefines what / means for this process and all its children. After this call, when the shell opens /etc/passwd, the kernel resolves it as /home/faizan/alpine-rootfs/etc/passwd. The host filesystem becomes completely invisible. Run ls / and you see Alpine's bin, etc, usr, exactly like a real Alpine machine.

chroot changes where / points, but your current working directory doesn't move. So in the directory you are running the code from, you're still sitting there after the chroot, that means outside the jail. From there, a process can just do cd ../../.. and walk right out. os.Chdir("/") moves you inside the jail immediately, so there's nowhere to escape to, which is perfect.

Mounting `/proc` - Fixing What `ps` Reads

must(syscall.Mount("proc", "proc", "proc", 0, ""))

After chroot, Alpine's /proc is an empty directory. The ps command reads everything from /proc/<pid>/status without mounting something there, ps would just fail.

So we mount a fresh procfs. The key detail: this is not a copy of the host's /proc. The kernel populates it based on what the current PID namespace can see. Since we're inside CLONE_NEWPID from Phase 2, only the container's processes appear. Run ps aux now and you'll only see the container's shell. The host process flood is gone. This is PID isolation and filesystem isolation finally working together.

Mounting `tmpfs` at `/tmp`

must(os.MkdirAll("tmp", 0755))
must(syscall.Mount("tmpfs", "tmp", "tmpfs", 0, ""))

tmpfs is memory-backed. Anything written to /tmp inside the container lives in RAM, never touches your host's /tmp, and disappears the moment the container exits. This is also why CLONE_NEWNS from Phase 2 mattered. Without the mount namespace, these mounts would propagate to the host's mount table. The mount namespace is the prerequisite; these mounts are the payload.

Test

now check everything if it's showing file system and process of the container and not of the host

Phase 4 - Cgroups

We now have a container with real isolation, its own filesystem, its own process tree, its own hostname. But there's still one problem: nothing stops a process inside this container from consuming all of your host's CPU, spawning thousands of processes, or eating all your RAM. A simple fork bomb inside the container would take down your entire machine.

This is what cgroups (control groups) solve. While namespaces control what a process can see, cgroups control what it can use.

So update your code with this function:

func cg() {
    cgroupRoot := "/sys/fs/cgroup/"
    cgroupName := "container-cgroup"
    containerCgroup := filepath.Join(cgroupRoot, cgroupName)

    os.WriteFile(
        filepath.Join(cgroupRoot, "cgroup.subtree_control"),
        []byte("+pids +memory +cpu"),
        0644,
    )

    must(os.MkdirAll(containerCgroup, 0755))

    must(os.WriteFile(filepath.Join(containerCgroup, "pids.max"), []byte("20"), 0700))
    must(os.WriteFile(filepath.Join(containerCgroup, "memory.max"), []byte("52428800"), 0700))
    must(os.WriteFile(filepath.Join(containerCgroup, "cpu.max"), []byte("50000 100000"), 0700))

    must(os.WriteFile(
        filepath.Join(containerCgroup, "cgroup.procs"),
        []byte(strconv.Itoa(os.Getpid())),
        0700,
    ))
}

Cgroup v2

This is what I wrote this blog mainly for. You see, most of the blogs were based on cgroups v1, but it got changed to cgroup v2 a long time ago, so eventually the code's gotta change as well.

Cgroup v2 uses a unified hierarchy. Every controller—pids, memory, cpu, lives under a single tree at /sys/fs/cgroup/. This is different from v1, which had separate trees per controller, like /sys/fs/cgroup/pids/, /sys/fs/cgroup/memory/, and so on. If you've seen old container blogs using v1 paths, that's why they're broken on modern kernels.

Working with cgroups is entirely done through the filesystem—you create directories, write to files. No special syscalls needed.

os.WriteFile(
    filepath.Join(cgroupRoot, "cgroup.subtree_control"),
    []byte("+pids +memory +cpu"),
    0644,
)

First, we enable the controllers on the root cgroup. Writing +pids +memory +cpu to subtree_control tells the kernel to make these controllers available to child cgroups we create underneath. It's like unlocking the feature before using it.

Creating the Cgroup

must(os.MkdirAll(containerCgroup, 0755))

This is the entire cgroup creation. You make a directory under /sys/fs/cgroup/ and the kernel sees it, recognizes it as a new cgroup, and automatically populates it with control files, pids.max, memory.max, cpu.max, cgroup.procs, and more. Nothing else needed.

The Limits

must(os.WriteFile(filepath.Join(containerCgroup, "pids.max"), []byte("20"), 0700))
must(os.WriteFile(filepath.Join(containerCgroup, "memory.max"), []byte("52428800"), 0700))
must(os.WriteFile(filepath.Join(containerCgroup, "cpu.max"), []byte("50000 100000"), 0700))

pids.max is the most immediately important one. Setting it to 20 means the kernel will start rejecting fork() and clone() calls the moment the process count hits 20. A fork bomb inside the container just chokes and dies, the host is untouched.

memory.max is 52428800 bytes - 50 MiB. If the container crosses this, the kernel's OOM killer steps in and kills the process that pushed it over. The host's memory is never at risk.

cpu.max format is $MAX $PERIOD in microseconds. 50000 100000 means: out of every 100ms window, this cgroup gets at most 50ms of CPU time, 50% of one core. A runaway CPU loop inside the container gets throttled at the kernel scheduler level. Your machine stays responsive.

Moving the Process In

must(os.WriteFile(
    filepath.Join(containerCgroup, "cgroup.procs"),
    []byte(strconv.Itoa(os.Getpid())),
    0700,
))

Everything before this was just configuration. This line is what actually enforces it. Writing our PID to cgroup.procs moves the current process into the cgroup. From this point, this process and every child it spawns—including the shell and everything the user runs inside, is subject to all three limits above.

Test

Try a fork bomb inside the container:

:(){ :|:& };:

With pids.max = 20, the kernel rejects every fork() past the limit. The container shell dies. Open another terminal on your host, everything is running perfectly. Without cgroups, that fork bomb would have required a hard reboot.

That's it! You've built a real container from scratch with proper isolation using namespaces, filesystem virtualization with chroot, and resource limits with cgroups v2. This is fundamentally what Docker does under the hood, just with a lot more features, better UX, and production-grade tooling on top.

Why Nothing Really Gets Deleted Immediately: How Database Deletion Works Through Tombstones, LSM-Trees, and Compaction

Faizan Firdousi — Tue, 10 Feb 2026 19:58:53 +0000

Do you know that when you delete something, it doesn't actually get deleted and erased immediately? Like, you press the delete button and expect the database to be like "ok boss, I'll remove the existence of this thing" ..... but no, it doesn't happen like that.

When we talk about modern high-performance databases, NoSQL and NewSQL systems based on LSM-trees use append-only data structures. That means you can't just pick a random value and update or delete it.

Why Append-Only?

Because databases are highly optimized and they found out that they need to be performant for sequential writes, which are orders of magnitude faster than random writes on disk.

We all know that traditional hard disks are mechanical and have seek times. If you were to specify the particular location where to read/write the data, it becomes expensive at scale while SSDs do not suffer from mechanical seek time, random writes are still more expensive than sequential writes, just for a different reason which is Write amplification.
That's why databases are optimized for sequential writes and not random writes.

Append-only structures also provide immutability benefits:

No in-place updates means simpler concurrency control (no locks needed for reads)
Easier crash recovery
Natural support for versioning

How Data is Stored

Let's understand the working of the data structures in LSM-based databases first. When you write data, it goes to two places at the same time:

Memtable - A sorted data structure (usually a skip list or red-black tree) that holds recent writes in memory for fast access.

Write Ahead Logging (WAL) - An append-only disk file that records every operation sequentially before applying it.

WAL is very important in making the database reliable because if the system crashes before the memtable is flushed to disk, you can replay the WAL to recover all committed operations.

When the memtable gets bigger than some threshold (typically a few megabytes), it then writes it out to disk as an SSTable (Sorted String Tables - immutable sorted key-value files stored on disk) file. This is efficient because the data is already sorted by keys in the memtable, making it easier to maintain that order in SSTables as well.

How Delete Operations Actually Work

So, we use tombstones. These are one of the most elegant yet complex solutions in append-only databases.

A tombstone is a special write operation that marks data as deleted without removing it. When you execute a DELETE statement, the database treats it as an insert, not a removal. The tombstone contains:

The key being deleted
A timestamp
A deletion marker flag

When you delete a key, the tombstone follows the exact same path as a regular insert: written to Memtable → appended to WAL → flushed to SSTable.

So the actual deletion didn't happen yet.

Compaction: Where Deletion Really Happens

Compaction is the exact step where deletion happens. If you don't already know, compaction happens regularly after some time, where the segments are compacted to remove the old data and keep the most recent ones.

Tombstones are physically removed during compaction, but only when specific conditions are met:

Grace period must expire :- The tombstone must be older than the configured grace period (gc_grace_seconds in Cassandra or similar TTL-based settings in other systems)
All relevant SSTables must participate :- If SSTable-A has the tombstone but SSTable-B has older data for the same key, both must be compacted together

After this is done, the disk space is reclaimed again.

There are more real-world challenges and stuff like multi-level compaction strategies, but that's a topic for another deep dive.

If you liked the blog do follow me and read other of my blogs

Understanding Database Models: DDIA Chapter 2

Faizan Firdousi — Thu, 15 Jan 2026 16:01:34 +0000

This chapter from Designing Data-Intensive Applications explores different database models and strategies for structuring application data. Understanding these concepts is crucial for making informed architectural decisions in modern software development.

by the way,Read chapter 1 here

How Applications Store Data

From an application developer's perspective, the data flow works like this: collect real-world data, model it using data structures and APIs, then store it in a database. The database might use JSON/XML documents, relational tables, or graph models, all ultimately stored as bytes on disk.

While we'll explore various data models, the relational model has proven most resilient and remains widely used. Modern applications often combine relational databases with non-relational databases (polyglot persistence) to meet specific requirements.

NoSQL vs SQL: Understanding the Trade-offs

SQL databases are familiar to most developers, but NoSQL offers compelling advantages:

Higher scalability and write throughput for large datasets
More open-source options available
Support for queries not possible in relational databases
Less restrictive schemas
Better performance for certain use cases, matching application data structures more closely

The Object-Relational Impedance Mismatch

Most application code uses object-oriented programming, representing data as objects. However, relational databases store data in tables, rows, and columns. This creates an awkward translation layer between code and database the impedance mismatch.

Object-Relational Mappers (ORMs) help by eliminating manual SQL queries, but they mostly provide abstraction rather than truly solving the underlying problem.

When Document Models Excel

A document model is a NoSQL approach that stores data as flexible, semi-structured documents (JSON/XML) rather than rigid rows and columns. MongoDB is a popular example.

One-to-Many Relationships

Consider a LinkedIn profile where one user has multiple job positions. This one-to-many relationship was challenging for early SQL databases not designed to store multiple values per row. People created separate tables for positions, though modern SQL databases now support multi-valued fields.

Document models handle this elegantly because JSON provides better locality than multi-table schemas. Instead of multiple queries across tables, you retrieve all relevant data in a single query.

Many-to-One Relationships and Normalization

When storing user inputs like city, organization, or college, use ID references instead of raw strings (e.g., org_id = 5 instead of org = "Microsoft").

This approach:

Models many-to-one relationships naturally (many users, one organization)
Enables clean data validation through dropdowns
Eliminates ambiguity from duplicate names
Improves maintainability update once, reflect everywhere
Allows centralized changes without touching thousands of records

For deeper exploration of normalization and schema design:
Read my detailed blog on database normalization

The JOIN Challenge

Joins combine fields from different tables in relational databases. While straightforward in SQL, document models have weak or nonexistent join support. Without database-level joins, you must emulate them in application code creating performance overhead and shifting complexity from the storage layer to your application.

Evolution of Database Models

Hierarchical Model

The first database model, used in IBM's IMS, employed a tree structure with single parents ideal for one-to-many relationships.

Limitations:

No many-to-many relationship support
Difficult denormalization decisions

Network Model

Created to solve hierarchical limitations, the network model allowed multiple parents, supporting many-to-one and many-to-many relationships.

The fatal flaw: Records connected like programming pointers through "access paths." These access paths made querying and updating extremely complex, negating the benefit of multiple relationship support.

Relational Model

The relational model succeeded because it:

Stores data in simple tables (rows and columns)
Eliminates complicated access paths
Supports multiple relationships elegantly
Allows inserting rows without foreign key concerns

The game-changer: query optimizers that make writing efficient queries straightforward.

Imperative vs Declarative Queries

Imperative code tells the computer every step: loop through lists, check conditions, push to arrays like giving turn-by-turn directions.

Declarative queries (like SQL) specify what you want, not how to get it:

SELECT * FROM animals WHERE family = 'Sharks'

The database determines optimal execution. This is powerful because query optimizers improve performance behind the scenes without code changes.

The surprising benefit: declarative languages are naturally parallelizable. Since you don't dictate execution order, databases can freely split work across multiple cores.

Key Takeaways

Relational databases remain dominant but work well alongside NoSQL for specific use cases
Document models excel at one-to-many relationships with better data locality
Normalization using IDs prevents data duplication and eases maintenance
Declarative queries enable database-level optimization and parallelization
Understanding historical models (hierarchical, network) helps appreciate modern solutions

Database Design Best Practice: Store Categorical Data as IDs, Not Strings

Faizan Firdousi — Sun, 11 Jan 2026 15:21:20 +0000

When designing your database schema for applications that collect user information like cities, organizations, or college names, implementing a relational database structure with foreign keys is crucial for scalability and maintainability.

The Problem with Storing Raw String Data

Instead of storing org = "microsoft" directly in your users table, store a reference: org_id = 5. This database normalization technique offers multiple advantages for production applications.

Benefits of ID-Based References

Improved User Experience

Implement dropdown menus with predefined options for categorical data like cities and organizations. This approach handles one-to-many relationships efficiently—where multiple users belong to a single organization. The structured data entry prevents issues with:

Duplicate city names (Springfield exists in multiple states)
Spelling variations and typos
Inconsistent formatting

Database Performance Optimization

Consider the storage implications: storing "Microsoft" as plain text for 10,000 employees means duplicating that string 10,000 times. When the company rebrands, you'll need to update thousands of records individually.

With a normalized approach using a lookup table (organizations table with id = 3, name = "Microsoft"), you only store org_id = 3 for each user. Company name updates require modifying just one record in the reference table.

Database Normalization and Third Normal Form (3NF)

This design pattern follows Third Normal Form (3NF) principles, a fundamental database normalization rule that:

Eliminates redundant data storage
Ensures non-key attributes depend only on primary keys
Improves query performance through proper indexing
Maintains referential integrity with foreign key constraints

Implementation Example

-- Organizations lookup table
CREATE TABLE organizations (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Users table with foreign key
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255) NOT NULL,
  email VARCHAR(255) UNIQUE NOT NULL,
  org_id INT,
  FOREIGN KEY (

Key Takeaways for Backend Development

When building scalable applications, always normalize categorical data into separate lookup tables. This database design pattern reduces storage overhead, simplifies maintenance, and ensures data consistency across your application.

My Key Takeaways from DDIA Chapter 1: Reliability, Scalability, and Maintainability

Faizan Firdousi — Wed, 07 Jan 2026 10:44:12 +0000

This was an introductory yet useful chapter to begin with, as it starts with the high-level fundamentals you need to think about before designing systems.
here are my notes which are the things which felt more important for me

Reliability:

The application should continue to work even if things go wrong, so design it in a way that handles most of the mistakes users make and places where it could crash. While discussing this stuff, use terms like "resilient" as terms like "fault tolerant" are misleading since there is no system which is 100% fault tolerant.
The difference between fault and failure is that a fault means often one component is off, while failure means the whole system goes down.

Types of errors the system needs to handle are-

hardware errors (not much for us to worry about, but the errors can also be interconnected with software)
software errors (bugs in code can cause cascading failures)
human errors (like wrong config files).

Scalability:

It's the system's ability to cope with increased load. It depends on how you design the system so that it can handle more load. Also, it's meaningless to talk like "something is scalable or something doesn't scale."
While talking about load, it's best to define the load termed as load parameters as per your app's requirements the load can be requests per second, ratio of reads and writes to the database, or active users in a chat room.
It's important to manage the system's resources (CPU, memory, etc.) according to when you increase the load parameters.
There are various ways to cope with the load like horizontal and vertical scaling, while keeping in mind that there ain't one scaling strategy or one absolute secret sauce that is applicable for every system as it depends on various factors.

Latency and response time

Latency means the time the data took to travel across the network, while response time means what the user sees—in simple terms, the total time the client sees from sending the request to getting a response. Response time includes more things like network delays, queueing delays, etc.

The best statistic used to monitor the response times of users is by plotting it in sorted order from fast to slow in percentiles and using the median (also 50th percentile or p50) as a metric. Big companies like Amazon design their internal structure according to the response time of the 99.9th percentile, which means 1 in 1000 requests.

Maintainability:

You don't leave the system just after making it and have to maintain it, so while making it you need to keep in mind that it should be easy for maintenance. Important things to keep in mind are

operability (making it easier for operations teams)
simplicity (easier to understand, reduce complexity as much as you can by adding right abstractions)
evolvability (easier to incorporate changes in the future, so it should be modifiable and extensible).

Why Docker Is Not Truly Native on Windows and macOS

Faizan Firdousi — Sat, 29 Nov 2025 05:25:31 +0000

Docker isn’t truly native outside Linux, and here’s why.

If you’re using Docker on Windows or macOS, your containers aren’t running directly on those operating systems. They run inside a small Linux virtual machine, created by Docker Desktop using technologies like WSL2, Hyper-V, or a hypervisor.

Docker was originally built only for Linux because containerization, at its core, depends on Linux kernel features, specifically namespaces and cgroups.

Namespaces handle isolation, giving each container its own sandboxed view of system resources like processes, networks, mount points, and filesystems.

Cgroups (Control Groups) manage and restrict resource usage (CPU, memory, bandwidth, I/O) so containers don’t overload the host.

Other operating systems simply don’t implement these kernel mechanisms in the same way, which is why Docker can’t run Linux containers directly on Windows or macOS kernels. The workaround? Docker runs a lightweight Linux VM behind the scenes, and everything operates inside it — sharing its kernel, not the actual host OS kernel.

Yes, Windows containers exist and can run natively on the Windows kernel, but they are a separate container type. The moment you run a Linux container, a Linux kernel layer becomes mandatory, regardless of whether the host machine is running Windows or Mac.

Understanding Docker Networking: A Practical, Small-Scale Production Emulation

Faizan Firdousi — Sat, 29 Nov 2025 05:23:09 +0000

So I was as usual learning about Docker, and got to know that Docker networking is surprisingly powerful for containerized application design.

When you create a Docker container, it by default takes up the default bridge network, and the container is assigned a private IP by the internal IPAM (IP Address Management) driver automatically. But you can also create your own user-defined bridge network, and because of that, containers can talk to each other via their container names (service discovery), provided they are in the same network. In the default bridge network, containers can only communicate by IP address.

I tried creating a small production-style Docker architecture for understanding. Here you have four containers: an API server, web frontend, a database, and a reverse proxy, with three bridge networks: database, backend, and frontend, each playing a specific role in a microservices-like layout.

The API server is in both the database and backend networks, while the Nginx reverse proxy is in both the frontend and backend networks because it has to route traffic from one port to another. Containers in the same network can communicate and ping each other; others cannot unless you explicitly connect a container to multiple networks.

The database network is isolated and denied internet access using the --internal flag because it's a convenient way of securing your database. Although the containers inside this internal network can communicate with each other, they cannot access the internet, which adds an extra layer of security for sensitive data.

The rest of the containers get internet access in the classic but interesting way: each has its own private IP address and is connected to docker0 via virtual Ethernet pairs (veth pairs). The docker0 bridge acts like a virtual switch responsible for routing traffic between containers and the host’s network interface. This is fascinating because it feels like a small-scale simulation of how the internet works, except we have containers instead of physical devices.

Building a Production-Ready DevOps Pipeline: URL Shortener with Docker, GitHub Actions & AWS

Faizan Firdousi — Sun, 23 Nov 2025 06:40:49 +0000

I’ve been exploring Docker and AWS fundamentals for a while, and I finally pushed myself to build a complete, production-style project from scratch—something that aligns with real-world DevOps workflows and cloud-native deployment practices.

This is a URL shortener service powered by a Go backend API, PostgreSQL as the database engine, Redis for caching, and a lightweight frontend. The structure loosely follows a microservices-oriented pattern to ensure clean separation of components, better scalability, and easier containerized deployment.

For Infrastructure & Deployment, I containerized all services using Docker with multi-stage builds and orchestrated the full stack using 𝗗𝗼𝗰𝗸𝗲𝗿 𝗖𝗼𝗺𝗽𝗼𝘀𝗲:

-Frontend
-PostgreSQL
-Redis
-Backend

I intentionally held off on Kubernetes for now—wanted to master container orchestration fundamentals with Docker Compose before moving into full K8s clusters and cloud orchestration tools. Docker Hub acts as the central container registry, streamlining image management across the CI/CD pipeline.

Next, I configured 𝗚𝗶𝘁𝗛𝘂𝗯 𝗔𝗰𝘁𝗶𝗼𝗻𝘀 𝗖𝗜/𝗖𝗗 to automate the build, test, and deployment workflow:

CI pipeline builds the Docker image on every push to main and publishes it to Docker Hub for consistent environment packaging.

CD pipeline runs on a self-hosted GitHub Actions runner inside an AWS EC2 instance, automatically pulling updated images and redeploying the full stack using Docker Compose.

This setup offers smoother, near zero-downtime deployments with proper container health checks and reliable infrastructure automation. It also mirrors how modern engineering teams manage continuous delivery in cloud environments.

The process came with plenty of challenges—pipeline errors, YAML workflow fixes, and debugging different container services. But the grounding I’ve built in Linux, AWS, networking, Docker, and basic system design helped me move past most hurdles.

I’m looking forward to building more cloud-based projects, exploring scalable backend systems, and strengthening my DevOps engineering skills.

GitHub repo: https://github.com/faizanfirdousi/url_shortener

How War Shaped the Foundations of Modern Computer Science

Faizan Firdousi — Fri, 21 Nov 2025 10:27:43 +0000

Well, this is not a very technical post about something, but it's on something that I have learned or come to know in recent times.

The two major contributing factors in the growth of computer science were war and growth in science.

Lately, I have been doing some studying and reading a bit about World War 2 and what happened, and I got to know how electronics and computing machines played a very important role in the war. If you know about Oppenheimer, who led the Manhattan Project in Los Alamos, there was a lot of computation needed to make up an atomic bomb. Physicists were not good at doing all of these calculations, so the work for it fell to people who knew physics and programming at the same time. It was at that time that people like von Neumann contributed highly to the projects; with his help, they were able to significantly help the team of the ENIAC computer. Afterward, he helped them design EDVAC's new logical design, now called the von Neumann architecture, which we all know is the basis for all the computers of today.

Well, if you trace back, von Neumann took inspiration from Alan Turing, whom he met at one point. Turing is another genius whom fewer people know about, who helped the Allied powers crack the Enigma code, which was the most complex encryption machine the Germans made. And according to sources, he made this machine called the Bombe, which was the literal machine that cracked the Enigma machine. Apparently, with the help of this, Alan Turing indirectly reduced the war by 2 years, and nobody knew how it was happening precisely. At that time, he already worked on his concept of the Turing machine, which was an abstract concept that formed the basis for all Computer Science and AI.

Turing went on to prove the existence of a Universal Turing Machine: a single machine which was capable of simulating any other Turing Machine by reading its program as input. This fundamentally invented the programmable computer, since it showed that a single machine could perform any of a number of tasks simply by modifying its instructions, not its hardware.

Turing asked the question "Can machines think?" and proposed what became known as the Turing Test.

The combination of computability theory-what can be computed-and the question of machine thinking-how computers might exhibit intelligence-established the theoretical and philosophical basis on which the whole of computer science and AI were founded. Although born in such a warlike setting, these breakthroughs reach far beyond the fields of battle. Ideas forged by individuals like Turing and von Neumann created frameworks that each modern computer and AI system still follows to this day. What is remarkable is how problems once approached with the urgency of war came to define this peaceful technological world we take for granted. Understanding this history makes the evolution of computer science feel much more like a narrative about how human pressure, intellect, and circumstance shaped the founding moments of an entire field.

A Developer’s Guide to Terminal Editors: Vim, Nano, and Emacs Explained

Faizan Firdousi — Fri, 21 Nov 2025 10:26:24 +0000

you've probably spun up AWS EC2 instances when trying to deploy an app or worked in a Linux-based terminal system. If so, you've likely noticed text editors quite unlike VS Code or what people typically use.

Let me tell you about terminal-based code editors. Command-line text editors are essential tools for working on virtual servers (like AWS EC2) because these environments typically lack graphical interfaces, requiring administrators to edit configuration files, scripts, and code directly through SSH connections.

When you SSH into cloud servers (AWS, DigitalOcean, etc.), you only have terminal access without GUI support. In these scenarios, you need lightweight, reliable text editors that can:
-Edit configuration files quickly during system emergencies
-Work efficiently on low-resource or remote systems
-Handle file modifications without requiring file transfers
-Operate reliably in unstable network conditions

The three most famous and widely used text editors are:

Vim: It's the most famous, you've probably heard people bragging about how fast they are with Vim. It's mostly pre-installed on virtually all Linux distributions. It's extremely efficient once mastered, with keyboard shortcuts for rapid text manipulation, but it has a steep learning curve. People configure it extensively according to their preferences, with Neovim nowadays being their daily code editor choice.

Nano: It's the easiest text editor. Though it doesn't have many features like search functionality like Vim, it's good for users who need immediate productivity without memorizing commands. For system admins or people who don't spend much time with code, Nano works well, but it's only suitable for small files (under 100MB).

Emacs: It's the most extensible editor, arguably superior to others because it offers almost unlimited customization and can behave like an IDE. It has a whole community dedicated to plugins.

People debate which is better, but it mostly depends on individual choices.

For professional server work, knowing at least one of these editors is mandatory because GUI editors are unavailable over SSH connections. Vim is particularly valuable because it's guaranteed to be present on every Linux server. The ability to efficiently edit files remotely without file transfers saves considerable time and reduces errors in production environments.

The Evolution of HTTP: From HTTP/1.1 to HTTP/2 to HTTP/3

Faizan Firdousi — Tue, 02 Sep 2025 17:58:00 +0000

The Evolution of HTTP: From HTTP/1.1 to HTTP/2 to HTTP/3

We all know that the internet is evolving rapidly, and users increasingly expect everything to load fast. Website loading times have evolved significantly over time, driven by improvements in how browsers retrieve HTML webpages from servers.

In this blog, I'll discuss everything I've learned about HTTP and its evolution from HTTP/1.1 to HTTP/2, with HTTP/3 still on the horizon for future exploration.

As we know, everything operates on a client-server model. The more efficient we can make communication between both parties, the greater the benefits we'll achieve.

Quick Overview of How HTTP Works

When you enter a website URL in your browser, it sends a GET request to the server, and the server responds with the HTML file that you see displayed.

In 1996, HTTP/1.0 was released with a simple design. The client sends a request line:

GET /index.html HTTP/1.0

The server responds with a status line and headers:

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 1234

While simple, HTTP/1.0 had significant limitations. Remember that HTTP is an application layer protocol that uses TCP underneath, and TCP is inherently slow. In HTTP/1.0, every GET request required establishing a new TCP connection, along with a new TLS handshake for each request. This made performance quite poor. Additionally, there was no TLS defined in the specification itself, SSL/TLS existed but only as a separate convention.

HTTP/1.1

HTTP/1.1 was introduced in 1997 and later refined in 1999. It proved so robust that it survived for over 15 years.

HTTP/1.1 was a much-improved version of HTTP/1.0. Unlike its predecessor, HTTP/1.1 implemented persistent connections by default. This meant one TLS handshake per session, allowing multiple requests and responses per connection. The Connection: keep-alive header became implicit, representing a huge performance improvement.

Advanced caching was another major feature introduced in HTTP/1.1.

While TLS remained a separate convention in HTTP/1.1, it matured significantly over time. By the late 1990s, SSL had evolved into TLS and was designed to work seamlessly with HTTP/1.1.

However, as users, we're always seeking better performance...

HTTP/2

After HTTP/1.1 had been widely used for many years, HTTP/2 was eventually released to address its remaining shortcomings. While HTTP/1.1 was a major improvement over HTTP/1.0 due to its persistent TCP connections, allowing multiple requests and responses over the same connection rather than opening new ones for each resource ,it still had a serious limitation.

The design still suffered from head-of-line blocking: all responses on a single connection had to be returned in order. If one response was delayed, every other response behind it had to wait. To work around this, web browsers typically opened several parallel TCP connections (usually around six per domain) to fetch multiple resources simultaneously. While this approach helped, it was inefficient because it required extra TCP handshakes, redundant TLS negotiations, and increased network congestion.

HTTP/2 solved these issues by introducing multiplexing, where multiple requests and responses can truly share a single TCP connection simultaneously without blocking each other.

How Multiplexing Works

In HTTP/2, you don't need to spin up multiple TCP sockets like in HTTP/1.1. Instead, you have one single TCP connection, and within that pipe, you can send all your requests together simultaneously to the server.

When mixing multiple requests in the same channel, you need a way to track which chunk belongs to which request. That's where Stream IDs come in. Every request the client makes gets tagged with a unique stream ID, and the server does the same when sending responses. Even though all data is interleaved on the wire, both sides can reassemble it correctly.

Under the hood, HTTP/2 also abandoned the old text-based format and uses a binary framing layer. This means requests and responses are broken into smaller frames (tiny packets of data) that can be interleaved. For example, frames for request A, request B, and request C can travel in mixed order like [A1][B1][A2][C1][B2][A3]. Upon arrival, the receiver sorts them back based on the stream IDs.

With this design, one slow response no longer holds up others. Additionally, HTTP/2 compresses repeated headers like cookies and user-agent strings, making it significantly faster and more efficient than HTTP/1.1.

HTTP/3

But wait, we're still not satisfied! Even though HTTP/2 solved many problems, it still had one fundamental issue lurking underneath , head-of-line blocking at the TCP layer itself.

You see, while HTTP/2 eliminated head-of-line blocking at the HTTP layer through multiplexing, it still relied on TCP as its transport protocol. TCP guarantees that packets arrive in order, which sounds great in theory, but it means that if a single TCP packet gets lost somewhere in the network, every single HTTP/2 stream has to wait for that packet to be retransmitted and received before any of them can proceed. So in some cases, this made HTTP/2 even slower than HTTP/1.1!

This is where HTTP/3 comes in as a revolutionary solution. Instead of trying to patch TCP, HTTP/3 said "forget TCP entirely" and built itself on top of QUIC (Quick UDP Internet Connections), which runs over UDP.

What Makes HTTP/3 Different

HTTP/3 uses QUIC as its transport protocol, and QUIC is fundamentally different from TCP. While TCP establishes one ordered stream of data, QUIC creates multiple independent streams within a single connection. If one stream loses a packet, only that specific stream needs to wait for retransmission, all other streams can continue flowing normally.

Think of it like this: imagine TCP as a single-lane tunnel where one broken-down car blocks all traffic behind it. QUIC is like a multi-lane highway where each lane operates independently, if there's an accident in one lane, traffic in other lanes keeps moving smoothly.

Key Features of HTTP/3

Faster Connection Setup: One of the biggest wins with HTTP/3 is connection establishment speed. Traditional HTTP/2 requires separate handshakes for TCP and TLS, which typically takes 2-3 round trips before any actual data can be sent. HTTP/3 combines transport and encryption into a single handshake, reducing connection setup to just one round trip. Even better, for returning visitors, HTTP/3 supports 0-RTT (zero round-trip time) resumption, meaning requests can be sent immediately without any handshake delay.

True Multiplexing Without Blocking: While HTTP/2 implements multiplexing on top of TCP, HTTP/3 leverages QUIC's native multiplexing capabilities. Each resource (like CSS, JavaScript, images) downloads on its own independent stream. If your cat photo loses a packet, your CSS and JavaScript files continue downloading uninterrupted.

Connection Migration: This is huge for mobile users. With HTTP/2, when you switch from Wi-Fi to cellular data, your connection breaks and has to be completely re-established. HTTP/3 supports connection migration the same connection seamlessly continues when switching networks. Your downloads don't get interrupted when you walk out of Wi-Fi range.

Built-in Security: Unlike previous versions where TLS was layered on top, HTTP/3 has TLS 1.3 encryption built directly into QUIC. This eliminates redundant handshakes and provides enhanced security by default.

How HTTP/3 is Currently Used

As of 2025, HTTP/3 adoption has been growing rapidly. According to recent data, over 95% of major browsers now support HTTP/3, and it's being used by approximately 26-34% of the top websites worldwide. Major players like Google, Facebook, Cloudflare, and YouTube have already implemented HTTP/3.

Chrome enabled HTTP/3 by default back in 2020, Firefox followed in 2021, and Safari has support but keeps it disabled by default (typical Apple behavior, honestly). On the server side, web servers like LiteSpeed, Nginx, and even Microsoft IIS have working HTTP/3 implementations.

The interesting thing is that you've probably already used HTTP/3 without realizing it. If you're using Chrome and visiting Google services, YouTube, or any Cloudflare-protected site, you're likely already experiencing HTTP/3's benefits.

However, adoption isn't universal yet. Many smaller websites and older infrastructure still haven't made the switch, partly because the performance benefits are most noticeable for high-traffic sites or users on unreliable networks. For simple websites that are already "good enough," the complexity of upgrading might not seem worth it.

The Beautiful Evolution of Internet Infrastructure

Isn't it fascinating how something as simple as loading a webpage has evolved into such a sophisticated dance of protocols and optimizations?

When you hit Enter after typing a URL, you're not just requesting a simple HTML file anymore. Behind that seemingly simple action, there's this beautiful orchestration of technology that has evolved over decades. Your browser is making intelligent decisions about which protocol version to use, establishing encrypted connections in milliseconds, multiplexing dozens of resources simultaneously across independent streams, and seamlessly handling network switches, all to get that webpage to you as fast as possible.

What started as a simple request-response pattern in HTTP/1.0 has evolved into this incredibly efficient system where your browser can download images, stylesheets, scripts, and fonts all at once, without any of them blocking each other, over a single connection that maintains itself even when you switch from Wi-Fi to cellular data.

The journey from HTTP/1.1's persistent connections to HTTP/2's multiplexing to HTTP/3's QUIC-based streams represents decades of engineers identifying bottlenecks and innovating solutions. Each generation didn't just add features, it fundamentally reimagined how data should flow across the internet.

And the best part? This entire evolution has been largely invisible to users. The same simple action of clicking a link or typing a URL now delivers an exponentially better experience, thanks to all this networking magic happening behind the scenes. It's a testament to how the internet continues to evolve and optimize itself while maintaining the simplicity that makes it accessible to everyone.

That's the beauty of internet evolution, constant improvement in the background, making every webpage load a little bit faster, a little bit more reliable, and a little bit more secure than before.

How a Simple Bitwise AND Decides If Two Computers Can Talk Directly

Faizan Firdousi — Fri, 01 Aug 2025 06:28:46 +0000

Do you know one of the most practical uses of bitwise operations in computer networking?
It happens every time your computer needs to determine whether another computer is on the same local network or a different one.

Understanding the Role of Bitwise Operations in Networking

When a computer wants to communicate with another device, it doesn’t just blindly send data. Instead, it performs a quick logical check to decide if the destination device is on the same LAN (Local Area Network) or somewhere else on the internet.

This check is done using a bitwise AND operation.

How the Bitwise AND Operation Works

Get the IP Address and Subnet Mask – Every computer on a network has an IP address and a subnet mask.
Perform a Bitwise AND – The computer uses its own IP address and subnet mask to perform a logical AND operation, which produces the network address.
Repeat for the Destination IP – The same AND operation is applied to the destination IP address using the same subnet mask.
Compare the Results – If both network addresses match, the devices are on the same network. If they don’t, they are on different networks.

Example

If your IP address is 192.168.1.10 and your subnet mask is 255.255.255.0, a bitwise AND gives:

192.168.1.10
AND 255.255.255.0
= 192.168.1.0

The same calculation is done for the destination IP. If it results in the same network address (192.168.1.0 in this case), the computer knows the device is local.

Why This Matters

If the destination is local, the computer sends data directly to it.
If it’s outside the local network, the data is sent to the default gateway (usually a router), which then forwards it toward the correct destination.

While switches and routers help in actually forwarding packets, this bitwise AND decision happens inside your computer before sending the packet.

Key Takeaways

Bitwise operations aren’t just for programmers — they’re essential for network communication.

The logical AND operation with a subnet mask determines if two devices are on the same network.

This happens before data leaves your computer.

DEV Community: Faizan Firdousi

Build a Container from Scratch in Go (Modern Namespaces + cgroup v2)

What are containers?

Namespaces

Cgroups

Phase 0

Phase 1

What this code does

Test

Why This Matters

Phase 2

Test

Test The /proc Problem

Phase 3

Environment Variables

Chrooting (the important step)

Mounting /proc - Fixing What ps Reads

Mounting tmpfs at /tmp

Test

Phase 4 - Cgroups

Cgroup v2

Creating the Cgroup

The Limits

Moving the Process In

Test

Why Nothing Really Gets Deleted Immediately: How Database Deletion Works Through Tombstones, LSM-Trees, and Compaction

Why Append-Only?

How Data is Stored

How Delete Operations Actually Work

Compaction: Where Deletion Really Happens

Understanding Database Models: DDIA Chapter 2

How Applications Store Data

NoSQL vs SQL: Understanding the Trade-offs

The Object-Relational Impedance Mismatch

When Document Models Excel

One-to-Many Relationships

Many-to-One Relationships and Normalization

The JOIN Challenge

Evolution of Database Models

Hierarchical Model

Network Model

Relational Model

Imperative vs Declarative Queries

Key Takeaways

Database Design Best Practice: Store Categorical Data as IDs, Not Strings

The Problem with Storing Raw String Data

Benefits of ID-Based References

Improved User Experience

Database Performance Optimization

Database Normalization and Third Normal Form (3NF)

Implementation Example

Key Takeaways for Backend Development

My Key Takeaways from DDIA Chapter 1: Reliability, Scalability, and Maintainability

Reliability:

Scalability:

Latency and response time

Maintainability:

Why Docker Is Not Truly Native on Windows and macOS

Understanding Docker Networking: A Practical, Small-Scale Production Emulation

Building a Production-Ready DevOps Pipeline: URL Shortener with Docker, GitHub Actions & AWS

How War Shaped the Foundations of Modern Computer Science

A Developer’s Guide to Terminal Editors: Vim, Nano, and Emacs Explained

The Evolution of HTTP: From HTTP/1.1 to HTTP/2 to HTTP/3

The Evolution of HTTP: From HTTP/1.1 to HTTP/2 to HTTP/3

Quick Overview of How HTTP Works

HTTP/1.1

HTTP/2

How Multiplexing Works

HTTP/3

What Makes HTTP/3 Different

Key Features of HTTP/3

How HTTP/3 is Currently Used

The Beautiful Evolution of Internet Infrastructure

How a Simple Bitwise AND Decides If Two Computers Can Talk Directly

Understanding the Role of Bitwise Operations in Networking

Why This Matters

Key Takeaways

Mounting `/proc` - Fixing What `ps` Reads

Mounting `tmpfs` at `/tmp`