Docker layers and build cache efficiency

WHAT THIS TESTS Whether you understand image layers as content-addressed, stacked units and can exploit that for fast transfers and fast builds.

A GOOD ANSWER COVERS A Docker image is a stack of read-only layers. Most instructions in a Dockerfile, such as RUN, COPY and ADD, create a new layer capturing the filesystem changes that step made; the layers are combined at runtime by a union or overlay filesystem that presents one merged view, with a thin writable layer added on top for the running container. Each layer is content-addressed by a digest of its contents. This drives transfer efficiency: when you push or pull, the registry and client exchange only layers whose digests are not already present, so shared base layers are transferred once and reused across images and across pulls, and unchanged layers are skipped entirely. The same content addressing powers the build cache: Docker reuses a cached layer if the instruction and its inputs are unchanged, but the moment one layer changes, every layer after it is invalidated and rebuilt. The practical lever is Dockerfile ordering: put stable steps, like installing OS packages and language dependencies, early, and volatile steps, like copying your application source, late, so a code change only rebuilds the cheap tail. Copying a lockfile and installing dependencies before copying the rest of the source is the classic pattern.

COMMON WRONG ANSWERS Treating an image as one monolithic blob with no reuse. Thinking reordering does not matter, or copying all source first then installing dependencies, which busts the cache on every code change. Forgetting that changing an early layer invalidates all later ones. Confusing layers with multi-stage builds, though both help.

LIKELY FOLLOW-UPS How do multi-stage builds shrink final images? How does BuildKit improve caching and parallelism, including remote cache? Why combine commands to reduce layers, and the tradeoff with cache granularity? How does a .dockerignore protect the cache?

ONE CONCRETE EXAMPLE A Node Dockerfile that copies the whole repo then runs npm install rebuilds dependencies on every commit. Reorder it to copy package.json and lockfile, run npm install, then copy the rest. Now a source-only change reuses the cached dependency layer, and the registry pull on deploy skips the unchanged base and dependency layers, cutting both build and transfer time dramatically.