A team's Dockerfile does `COPY target/app.jar app.jar` as a single layer, and every deploy — even a one-line code change — pushes and pulls the full 45 MB jar to and from the registry. What does switching to Spring Boot's layered jar actually change at the registry and node level, and why doesn't the same benefit apply to the fat jar no matter how the Dockerfile is restructured around it?

A single fat jar is one indivisible file as far as Docker's layer model is concerned — any change anywhere inside it, even to one class, produces a jar with different bytes overall, so the layer that COPYs it in gets a completely new content hash and has to be pushed and pulled in full, every time, regardless of how the rest of the Dockerfile is organized. Spring Boot's layered jar splits the jar's own contents by rate of change — dependencies, Spring's own loader, snapshot dependencies, application code — into separate directories, and the Dockerfile then COPYs each one as its own layer. Dependencies change only when the POM does, so that (largest) layer keeps its same content hash across deploys where only code changed, and both the registry push and the node's pull skip it entirely, transferring only the small application-code layer instead. Restructuring the Dockerfile around a fat jar can't get the same benefit because the fat jar itself is still one file with one hash — splitting it into layers requires actually splitting what's inside it, which is exactly what the layered-jar extraction step does and a single-file COPY cannot.