DEV Community: Mohammad

OverlayFS Explained: How Docker's Filesystem Layers Actually Work

Mohammad — Sun, 28 Jun 2026 20:15:33 +0000

Preface

I have planned to write a series of articles to understand Docker under the hood and containers. I will start with the Overlay filesystem 🙂, but every journey should begin from the fundamentals.

When you hear “Docker”, the first thing that comes to mind is “container”.

And what about “Kubernetes”? Again, containers.

Two different systems, same mental model.

So what exactly are containers? And are they truly isolated and independent units of software?

The short answer is: yes, but not in the way people usually think.

Containers have existed in Unix/Linux systems long before Docker. What Docker and Kubernetes did was to make them portable, standardized, and operationally usable at scale.

Recreation Time

Sometimes I say K8s because there are 8 letters between “K” and “s”.

K[ubernete]s → “ubernete” = 8 characters → K8s.

Just a naming shortcut. Nothing deeper.

Fun practice

How would you shorten my family name “Ghalambaz”?

Maybe “G7z”. Now try your own version.

Let’s get back to containers.

What is a container really?

A container is not a virtual machine.

Instead, it is:

A normal Linux process that is isolated using kernel features like namespaces and cgroups.

This isolation makes the process feel like it has its own system, but in reality it is still running on the host kernel.

One of the core mechanisms behind this isolation is Linux’s namespace system, which includes a system call called unshare.

So yes, unshare is powerful, but it is only one piece of a much larger puzzle.

We will come back to this later.

For now, we start with something even more fundamental to containers:

👉 the filesystem layer model used by Docker: OverlayFS

File Systems

Have you ever heard of filesystems like FAT32, NTFS, or EXT4?

They define how the operating system:

stores data on disk
organizes files
manages metadata
retrieves data efficiently

Each filesystem has different design goals, but I are not focusing on them here.

Instead, I focus on a special filesystem type:

OverlayFS is the foundation of Docker image layering

What is OverlayFS?

OverlayFS is a union filesystem in Linux.

It allows multiple directories (called layers) to appear as a single unified directory.

Simple mental model

Imagine two directories:

Directory A

A.txt
C.txt

Directory B

B.txt
C.txt

Now I “merge” them into a virtual directory M.

What do you see in M?

A.txt
B.txt
C.txt

But here is the important detail:

There is no real merging or copying happening.

OverlayFS just simulates a merged view.

Important questions (this is where it gets interesting)

What happens when:

Two files have the same name?
You modify a file from the merged view?
Where does a new file actually get written?

These are the exact problems OverlayFS solves using a layered model. Keep these three questions in mind. I will answer all of them in the next section.

OverlayFS Architecture

OverlayFS has three main concepts:

1. Lower Layers (Read-only)

Multiple directories can exist
They are stacked together
They are immutable (read-only)

These layers typically represent:

Docker image layers
Base OS filesystem
Application dependencies

Answers question 1: if a file exists in more than one lower layer, the layer listed first (the “topmost” one) wins. I will see this live in the hands-on section.

2. Upper Layer (Writable)

This is where changes happen.

New files are created here
Modified files are copied here (copy-on-write)
It is writable

Answers question 3: any new file you create always goes here, never into a lower layer.

3. Merged Layer (View Layer)

This is what the user sees.

A unified view of all layers
Read/write interface
Does not contain real merged data

A note on `workdir`

There is actually a small 4th directory the kernel needs, called workdir. You will see it in the hands-on example below.

workdir is not a “layer” you read from it’s internal scratch space the kernel uses to do copy-up operations safely (so a crash mid-write can’t corrupt your data). Two rules:

it must live on the same filesystem as upperdir
you should never read or write to it yourself. just create an empty folder and let the kernel manage it > ⚠️ Don’t mix this up with Docker’s WORKDIR instruction. They share a name, but they are completely different things: > - OverlayFS workdir : a kernel-level scratch directory for copy-up operations. Nothing to do with Docker directly; you only see it when mounting OverlayFS yourself or when reading docker inspect output. > - Docker WORKDIR : a Dockerfile instruction that sets the current working directory inside the image, for any RUN, CMD, ENTRYPOINT, COPY, and ADD instructions that follow it. For example: > > plaintext > WORKDIR /app > COPY . . > RUN npm install >

Here, COPY and RUN both execute inside /app. It’s a metadata-only instruction (no real file content), so as I covered earlier, it creates an empty layer.

Mental Model (Important)

Think of it like this:

User View (Merged)
                 |
     -----------------------------
     |            |             |
 Lower Layer   Lower Layer   Upper Layer
 (read-only)   (read-only)   (read-write)
                                  |
                              workdir
                          (kernel scratch space)

How file resolution works

When you access a file:

Step 1: Check Upper Layer

If file exists → return it

Step 2: Check Lower Layers (top to bottom)

If found → return it

Step 3: Not found → file does not exist

What happens on modification?

This is where OverlayFS becomes powerful.

Scenario: file exists in lower layer

If you modify it:

File is copied to upper layer
Modification happens on the copied file
Original lower layer remains unchanged

This is called:

Copy-on-write (CoW)

Answers question 2: modifying a file you see in the merged view never touches the lower layer. It only touches the copy in the upper layer.

What happens when you create a new file?

New files always go to the upper writable layer.

Why OverlayFS matters for Docker

Docker images are built using layers.

Each instruction in a Dockerfile adds an entry to the image, but not every instruction writes new files to disk. There are two kinds:

Instructions that create a layer with real file content:

RUN – runs a command and saves the file changes it makes
COPY – copies files from your build context into the image
ADD – like COPY, but can also extract .tar archives and fetch from a URL

Instructions that only add metadata (empty layer, 0 bytes):

ENV – sets an environment variable
LABEL – adds metadata, like a tag
CMD – sets the default command for the container
ENTRYPOINT – sets the command that always runs
EXPOSE – documents which port the container listens on
WORKDIR – sets the working directory
USER – sets which user runs the next instructions
ARG – defines a build-time variable

So yes, every instruction shows up in the image’s history. But only RUN, COPY, and ADD actually change the filesystem and create a layer with real content. The rest just attach information to the image.

You can check this yourself:

docker history <image-name>

Layers that come from metadata-only instructions will show 0B as their size.

Example Dockerfile:

FROM ubuntu
RUN apt-get update
RUN apt-get install nginx
COPY app /app

Here, FROM brings in the base image layers, and each RUN and the COPY create one new content layer, then four content layers in total.

When you run a container:

Docker stacks all image layers (lower layers)
Adds a writable upper layer
Uses OverlayFS to merge them

WSL connection

WSL (especially WSL2) provides a real Linux kernel environment on Windows.

This enables:

Linux namespaces
cgroups
OverlayFS support

So OverlayFS is part of the Linux kernel features used inside WSL. This is also why Docker Desktop’s WSL2 backend can run real Linux containers on Windows without a separate full virtual machine.

In Practice (hands-on idea)

Let’s create a simple structure:

mkdir ofs
cd ofs

mkdir lower1 lower2 upper work merged

Note the work directory, this is the workdir I talked about above. It’s easy to forget, but the mount will fail without it.

Create files:

echo "A" > lower1/A.txt
echo "C1" > lower1/C.txt

echo "B" > lower2/B.txt
echo "C2" > lower2/C.txt

Now mount OverlayFS:

sudo mount -t overlay overlay \
  -o lowerdir=lower1:lower2,upperdir=upper,workdir=work \
  merged

Now inspect:

ls merged

You should see:

A.txt
B.txt
C.txt

Here is what just happened, mapped to our actual files:

lower1 (top priority)     lower2 (bottom)         upper (empty so far)
├── A.txt                 ├── B.txt
└── C.txt  ─┐             └── C.txt  ─┐           (nothing written yet)
            │  shadowed,  ┘            │
            │  lower1 wins
            ▼
      ┌─────────────────────────────────────┐
      │              merged                  │
      │  A.txt   ← from lower1               │
      │  B.txt   ← from lower2               │
      │  C.txt   ← from lower1 (wins,        │
      │            because it's listed first) │
      └─────────────────────────────────────┘

lower2/C.txt still exists on disk. it’s just hidden behind lower1/C.txt in the merged view, because lower1 was listed first in lowerdir=lower1:lower2.

Test copy-on-write

echo "modified" > merged/A.txt

Now check:

upper/A.txt → exists (copied + modified)
lower1/A.txt → unchanged

Docker connection

You can inspect this same behavior in Docker, with a real image.

Step 1: pull and run an image

docker pull nginx:latest
docker run -d --name overlay-demo nginx:latest

Step 2: inspect the GraphDriver

docker inspect overlay-demo --format '{{json .GraphDriver}}'

You will get something like this (your IDs will be different from these samples):

{
  "Data": {
    "LowerDir": "/var/lib/docker/overlay2/abc123-init/diff:/var/lib/docker/overlay2/def456/diff",
    "MergedDir": "/var/lib/docker/overlay2/abc123/merged",
    "UpperDir": "/var/lib/docker/overlay2/abc123/diff",
    "WorkDir": "/var/lib/docker/overlay2/abc123/work"
  },
  "Name": "overlay2"
}

Notice the pattern matches exactly what I just did by hand:

LowerDir has multiple paths joined with : , one per image layer
UpperDir is the container’s own writable layer
MergedDir is what the container actually sees as its root filesystem
WorkDir is the kernel scratch space I mentioned earlier

Step 3: open the directories and compare

sudo ls /var/lib/docker/overlay2/<lower-id>/diff
sudo ls /var/lib/docker/overlay2/<upper-id>/diff

Right after docker run, UpperDir will be almost empty the container hasn’t changed anything yet.

Step 4: trigger copy-on-write live

docker exec overlay-demo sh -c "echo hello > /usr/share/nginx/html/test.txt"
sudo cat /var/lib/docker/overlay2/<upper-id>/diff/usr/share/nginx/html/test.txt

The new file appears inside UpperDir, not in any lower layer exactly the same behavior you saw with merged/A.txt in the manual example.

Key Takeaway

OverlayFS gives containers the illusion of a complete, writable filesystem while actually using immutable layers + a writable delta layer

This is one of the core reasons Docker is fast and efficient.

Amazon S3, Object Stores, and the Directories That Don't Exist

Mohammad — Thu, 25 Jun 2026 17:54:27 +0000

S3 and Object Storage

Most of us have used Amazon S3 at some point and may have wondered:

If AWS provides S3, why are we using Linode Object Storage or MinIO instead?

The reason is that Amazon S3 is both a service and a de facto API standard for object storage.

AWS provides S3 as its managed object storage service, but other vendors such as Linode and MinIO also offer object storage solutions that implement the S3-compatible API. This allows applications written for S3 to work with different storage providers with little or no code changes.

Recently, we migrated our object storage from MinIO to Linode. Although we do not use AWS S3 itself, our applications still communicate using the S3-compatible API.

One important thing to keep in mind is that third-party implementations are not always identical to AWS S3. Some providers may only partially implement the S3 API, behave slightly differently, or not support all available features.

Directories in Object Storage

When working with object storage, you've probably seen structures that look like directories:

versions/
└── object/
    └── g0/
        └── something.xxx

At first glance, this looks very similar to a traditional filesystem. But are these actually directories?

The answer is no.

Object storage does not store files in real directories. Instead, every object is stored with a unique key (identifier). What looks like a path is simply part of the object's name.

For example, an object may have the following key:

versions/object/g0/something.xxx

This is a single object key, not a file stored inside nested directories.

The / character is simply a naming convention used to organize object names. Management tools and UIs use these prefixes to simulate a directory structure, but the folders themselves do not actually exist.

Understanding this helps explain why operations such as recursively deleting a directory or listing directories are not native object-storage operations. In reality, there are no directories to delete—only objects whose keys share a common prefix.

Why "Creating a Directory" Looks Instant

When you create a directory in a traditional filesystem, metadata is written to disk.

In object storage, creating a directory is often just creating an empty object or simply displaying a prefix in the UI. No real directory structure is created behind the scenes.

For example, after uploading:

versions/object/g0/file.txt

many S3 clients will automatically display:

versions/
└── object/
    └── g0/

even though those directories do not actually exist.

What Happens When We List a "Directory"?

Consider the following command:

mc ls s3-pimcore-stg/nbb-pimcore-stg/version

At first glance, it looks like we're listing the contents of a directory called version, but that's not actually what's happening.

The path can be interpreted as:

s3-pimcore-stg   -> configured storage alias/endpoint
nbb-pimcore-stg -> bucket name
version         -> object key prefix

The object storage server does not navigate a directory tree. Instead, it searches for objects whose keys begin with the specified prefix.

Conceptually, this is closer to:

Find all objects in bucket "nbb-pimcore-stg"
where key starts with "version"

For example, if the bucket contains:

version/object/g0/file1.jpg
version/object/g1/file2.jpg
version/thumbs/file3.jpg

all of these objects may be returned because they share the same prefix.

This is not a regular-expression search. It is a prefix-based lookup, which is one of the core concepts used by object storage systems to simulate directories.

Why Recursive Delete Can Be Expensive

Deleting a directory in a traditional filesystem usually involves traversing the directory tree and removing its contents.

In object storage, deleting a "directory" is fundamentally different:

List all objects that share a specific prefix.
Delete each matching object individually (or in batches).

For a prefix containing thousands or millions of objects, this operation can become expensive and time-consuming because the storage system must first discover all matching objects before they can be removed.

This is another consequence of the fact that object storage does not have real directories—it only has objects and object keys.

Mental model: Treat object storage as a giant key-value store where the key happens to look like a file path. Once you think of it that way, most S3 behaviors become much easier to understand.

Why This Matters

Understanding that object storage has objects and prefixes, not directories changes how you design applications around it.

The same prefix-based lookup that makes a "directory delete" expensive also applies to listing: every time an application "opens a folder," the storage service performs a prefix lookup rather than traversing a real directory tree. For a few dozen objects this is invisible. For millions, it shows up as extra LIST calls, slower responses, and—depending on your provider's pricing model—extra cost.

Design For Prefixes, Not Directories

A common mistake is treating object storage like a traditional filesystem.

Instead of repeatedly listing prefixes:

versions/
 └── object/
      └── g0/

consider storing the object keys you already know in a database or index.

For example:

id | object_key
---+-----------------------------------
1  | versions/object/g0/file1.jpg
2  | versions/object/g0/file2.jpg

Now you can fetch the keys directly and perform batch operations without repeatedly asking the object store to discover them.

Similarly:

Prefer batch deletes over deleting objects one by one.
Avoid repeatedly listing the same prefix in loops.
Use lifecycle policies when objects have predictable expiration dates.
Organize object keys so that related objects share predictable prefixes.

The goal is simple:

If your application already knows the object keys, don't ask the storage system to find them again.

A Note About Costs

Many object storage providers charge not only for stored data but also for API requests. AWS S3, for example, charges for LIST, PUT, COPY, and GET operations, while DELETE requests themselves are free. However, deleting a large prefix often requires LIST operations first, which are billable.

Because of this, good object-storage design is usually about reducing unnecessary discovery operations:

Less efficient:

for each user:
    list user folder
    find files
    delete files

More efficient:

query database for object keys
delete objects in batches

S3 even provides a bulk delete API that can remove up to 1,000 objects in a single request, significantly reducing request overhead compared to deleting objects individually.

A good rule of thumb is:

Treat LIST operations as searches and DELETE operations as actions. Searches are often the expensive part, so avoid performing them when you already know the answer.

Final Words

Treat object storage as a giant key-value store where the key happens to look like a file path—that one shift in thinking explains most of S3's quirky behavior around directories, listing, and deletes.

Listening to the Heartbeat of Your Database: Understanding Change Data Capture (CDC)

Mohammad — Fri, 19 Jun 2026 12:06:56 +0000

CDC stands for Change Data Capture.

What You Will Learn

What CDC is
The story behind it
How it works internally
Common use cases
A simplified implementation example

What Is CDC?

Change Data Capture (CDC) is a technique for capturing changes made to data and exposing those changes to external systems.

Instead of repeatedly querying a database to check whether something has changed, CDC allows applications to consume a stream of inserts, updates, and deletes as they happen.

Think of CDC as a way to listen to the heartbeat of your database.

Every time data changes, the database records that change internally. CDC makes those changes available so that other systems can react to them in real time.

The Story Behind CDC

To understand CDC, it helps to understand how databases have worked for decades.

Whenever data changes, databases do not simply overwrite the old value and move on. They maintain an internal record of operations that have occurred.

These records are commonly stored in transaction logs.

Historically, every database implemented these logs differently, but the purpose was always the same:

Record every change made to the database
Recover from failures
Replicate data to other nodes
Maintain consistency

Every insert, update, and delete operation generates a log entry.

These entries are ordered and identified by a unique position or token.

The ordering is critical.

Imagine the following sequence:

Create User
Update User
Delete User

If a replica applied these operations in a different order, it would end up with completely different data.

Because these logs are ordered, databases can reliably replay changes and reconstruct state over time.

This is how replication works in many database systems.

A replica typically starts with an initial snapshot and then continuously applies new changes by replaying the transaction log.

Where CDC Comes In

Originally, these logs were intended for the database itself.

CDC extends that idea by allowing external applications to consume those same changes.

Instead of only replicas reading database changes, your applications can read them too.

This means that whenever data changes, you can react immediately without constantly querying the database.

The underlying idea is simple:

Expose an ordered stream of database changes that external systems can consume reliably.

How CDC Works

Different databases implement CDC differently, but the concept remains the same.

MongoDB

MongoDB provides CDC through Change Streams.

Each event contains a resume token, which allows consumers to continue reading from the last processed change after a restart or failure.

MySQL

MySQL exposes changes through its Binary Log (Binlog).

CDC tools can read the binlog and transform database operations into events.

PostgreSQL

PostgreSQL provides CDC through Logical Decoding and Logical Replication.

These mechanisms allow applications to consume database changes in order.

Although the implementations differ, they all provide the same capability:

An ordered stream of database changes.

CDC Is Usually Pull-Based

One common misconception is that databases push changes directly to your application.

In reality, most CDC implementations are fundamentally pull-based.

The consumer requests the next available change from the database.

However, applications typically maintain a long-lived connection or cursor, making the experience feel very similar to receiving pushed events.

For example, MongoDB's watch() API keeps a stream open and continuously delivers new events as they become available.

From the application's perspective, it feels real-time.

A Simplified CDC Example

To understand the concept, imagine that every database change is converted into a standardized event.

function captureDataChange($operation, $table, $id, $before, $after)
{
    $cdcEvent = [
        "metadata" => [
            "operation" => $operation,
            "table" => $table,
            "id" => $id
        ],
        "before" => $before,
        "after" => $after
    ];

    echo "Streaming event: " . json_encode($cdcEvent) . PHP_EOL;
}

captureDataChange(
    "UPDATE",
    "users",
    42,
    ["name" => "Alice", "role" => "Developer"],
    ["name" => "Alice", "role" => "Architect"]
);

Output:

{
  "metadata": {
    "operation": "UPDATE",
    "table": "users",
    "id": 42
  },
  "before": {
    "name": "Alice",
    "role": "Developer"
  },
  "after": {
    "name": "Alice",
    "role": "Architect"
  }
}

Real CDC systems work differently under the hood, but the idea is very similar:

Detect a database change
Convert it into an event
Publish it to interested consumers

CDC vs Traditional Polling

Without CDC, applications often use polling.

For example:

SELECT *
FROM orders
WHERE updated_at > :last_seen_timestamp;

This approach works, but it has drawbacks:

Additional load on the database
Expensive queries at scale
Possibility of missing updates
Duplicate processing logic

CDC avoids these problems by consuming changes directly from the database's change stream.

Instead of repeatedly asking:

"Has anything changed?"

the database tells you:

"This is what changed."

Why CDC Matters

CDC is more than a database feature.

It is an architectural building block.

Once database changes become events, many new possibilities emerge.

Common use cases include:

Search index synchronization (Elasticsearch/OpenSearch)
Analytics pipelines
Event-driven architectures
Cache invalidation
Audit trails
Data warehouse synchronization
Building materialized views
Synchronizing data across services

For example, when a product is updated in your database, a CDC consumer can automatically update:

Search indexes
Caches
Reporting systems
Recommendation engines

without requiring changes to the original application.

CDC in Modern Architectures

Many organizations use CDC platforms such as Debezium to provide a unified way of consuming changes across different databases.

These platforms often publish CDC events into systems such as Apache Kafka, where multiple consumers can process the same stream independently.

This makes CDC a key building block in modern event-driven systems.

Final Thoughts

At its core, CDC is a simple idea:

Every database change is already being recorded somewhere. CDC allows external systems to listen to those changes.

Whether it is MongoDB Change Streams, MySQL Binlogs, or PostgreSQL Logical Replication, the principle remains the same:

An ordered stream of database changes that can be consumed reliably.

Once you start viewing database updates as events rather than rows being modified, CDC becomes one of the most powerful tools for building scalable and loosely coupled systems.

From Notion to Everywhere: Building Calligra

Mohammad — Thu, 18 Jun 2026 18:11:58 +0000

Every developer blog needs a first post.

Mine starts with a pen, a family name, and a workflow I got tired of doing by hand.

The Publishing Problem

I write almost everything in Notion.

It is where ideas begin, drafts evolve, and articles eventually take shape. But publishing those articles was always the same repetitive process:

Copy the content from Notion.
Fix formatting issues.
Paste it into my blog.
Repeat for Dev.to.
Repeat for Hashnode.
Repeat for Medium.
Upload cover images multiple times.
Configure canonical URLs manually.

None of these steps were difficult.

They were simply repetitive.

And as developers, repetitive work usually means there is an opportunity for automation.

The Goal

I wanted a publishing workflow that looked like this:

Notion → Calligra → Personal Blog + Dev.to + Hashnode + Medium

Write once.

Publish everywhere.

Keep my own domain as the source of truth.

That simple idea became Calligra.

What Is Calligra?

Calligra is an open-source CLI tool that takes content from Notion and publishes it to multiple destinations with a single command.

make sync
make build
make publish

Behind the scenes, Calligra:

Fetches content from the Notion API
Converts the content into platform-specific formats
Uploads images and assets
Publishes to supported platforms
Sets canonical URLs back to your own website

The goal is simple:

Your personal blog owns the content. Other platforms help distribute it.

Screenshot: Publishing Workflow

Content Flow

┌──────────┐
│  Notion  │
└────┬─────┘
     │
     ▼
┌──────────┐
│ Calligra │
└────┬─────┘
     │
     ├──► Personal Blog
     ├──► Dev.to
     ├──► Hashnode
     └──► Medium

The Story Behind the Name

Before the code, there is the name.

The Craft

The word Calligra comes from the same roots as calligraphy — the art of beautiful writing.

Calligraphy is not just about words.

It is about intention, structure, and craftsmanship.

The Heritage

My family name is Ghalambaz (قلم‌باز).

A rough translation would be:

"Pen player."

Historically, it referred to someone who practiced writing as both a craft and an art.

Someone who enjoyed working with words.

When I built a tool dedicated entirely to writing and publishing, the name felt inevitable.

Calligra connects a modern publishing workflow with a much older tradition of writing.

Open Source from Day One

Although Calligra started as a personal tool, I built it to be useful for other developers as well.

If you write in Notion or anywhere else and publish technical content, you might find it useful.

The project is open source, and contributions, feedback, and ideas are always welcome.

Repository: Ghalambaz/Calligra

Why Start This Blog?

Calligra solves the publishing problem.

Now it's time to focus on the writing.

This blog will be a place for practical engineering lessons, architectural decisions, debugging stories, and lessons learned from building software in production.

Not tutorials copied from documentation.

Not generic AI-generated content.

I do use AI—but as an editor, not an author.

AI is great at fact-checking, catching mistakes, improving clarity, challenging assumptions, and helping me communicate ideas more effectively. The experiences, opinions, successes, and failures will still be my own.

The goal is simple: share real engineering stories, real production problems, and solutions that might help someone else avoid the same mistakes.

What's Next?

This post marks the beginning of the journey, not the destination.

Over time, I'll be writing about software architecture, backend engineering, distributed systems, debugging sessions, performance bottlenecks, deployment lessons, and the occasional mistake that taught me something valuable.

Some articles will be technical deep dives.

Some will be lessons learned from real projects.

Some may simply document a problem that took far longer to solve than it should have.

The goal is not to publish content for the sake of publishing.

The goal is to share experiences, capture lessons before they are forgotten, and hopefully help other engineers who run into similar challenges along the way.

Final Thoughts

Calligra started as a way to eliminate a repetitive workflow.

Now it has become the foundation of this blog.

If you are a developer who writes in Notion and owns a personal domain, I hope it saves you time as well.

Thanks for stopping by.

See you in the next post.

—

Mohammad Ghalambaz

writing at Calligra.dev

DEV Community: Mohammad

OverlayFS Explained: How Docker's Filesystem Layers Actually Work

Preface

Recreation Time

Fun practice

What is a container really?

File Systems

What is OverlayFS?

Simple mental model

What do you see in M?

Important questions (this is where it gets interesting)

OverlayFS Architecture

1. Lower Layers (Read-only)

2. Upper Layer (Writable)

3. Merged Layer (View Layer)

A note on workdir

Mental Model (Important)

How file resolution works

Step 1: Check Upper Layer

Step 2: Check Lower Layers (top to bottom)

Step 3: Not found → file does not exist

What happens on modification?

Scenario: file exists in lower layer

What happens when you create a new file?

Why OverlayFS matters for Docker

WSL connection

In Practice (hands-on idea)

Test copy-on-write

Docker connection

Step 1: pull and run an image

Step 2: inspect the GraphDriver

Step 3: open the directories and compare

Step 4: trigger copy-on-write live

Key Takeaway

Amazon S3, Object Stores, and the Directories That Don't Exist

S3 and Object Storage

Directories in Object Storage

Why "Creating a Directory" Looks Instant

What Happens When We List a "Directory"?

Why Recursive Delete Can Be Expensive

Why This Matters

Design For Prefixes, Not Directories

A Note About Costs

Final Words

Further reading:

Listening to the Heartbeat of Your Database: Understanding Change Data Capture (CDC)

What You Will Learn

What Is CDC?

The Story Behind CDC

Where CDC Comes In

How CDC Works

MongoDB

MySQL

PostgreSQL

CDC Is Usually Pull-Based

A Simplified CDC Example

CDC vs Traditional Polling

Why CDC Matters

CDC in Modern Architectures

Final Thoughts

From Notion to Everywhere: Building Calligra

The Publishing Problem

The Goal

What Is Calligra?

Screenshot: Publishing Workflow

Content Flow

The Story Behind the Name

The Craft

The Heritage

Open Source from Day One

Why Start This Blog?

What's Next?

Final Thoughts

A note on `workdir`