Netflix Hollow, and how one producer feeds many readers

A snapshot library for data that does not change often

Hollow is a Java library and toolset for disseminating in-memory datasets from a single producer to many consumers for high performance read-only access, and the project links the Netflix announcement post that introduced it.

The shape of the problem is specific. There is one service that owns the truth about a dataset, and many services that need to read it. The obvious designs are a database query per read, which is expensive when the data is large and the read is hot, or a cache per consumer, which is a distributed cache problem with all of the invalidation problems that come with it. Hollow takes a third route: the producer publishes a snapshot, and the consumers hold it in memory and read it directly.

The read-only part is not a limitation in the design but the design. If the data changes, a new snapshot is published, and the consumers pick it up. There is no in-place mutation, so a consumer reading the dataset never sees a half updated state, and the dataset can be held in a form that is fast to query, which is the point of pushing it into memory in the first place.

The tooling around the library is as much of the project as the library. The repository carries a diff UI, an explorer UI, a performance module, a test module and several adapters, which tells you the intended workflow is not just publish and read but also inspect what changed, compare snapshots and profile the read path.

The documentation is at hollow.how, the quick start guide is the recommended entry point, and the project claims a demo running in minutes and a production-scalable implementation in about an hour. The primary language is Java and the licence is Apache-2.0, with a NOTICE file and OSSMETADATA in the repository.

The dependency, and the version the README does not mention

The README gives the coordinates for the artifact, with the group identifier com.netflix.hollow and the artifact name hollow, and a Maven snippet.

        <dependency>
                <groupId>com.netflix.hollow</groupId>
                <artifactId>hollow</artifactId>
                <version>5.1.3</version>
        </dependency>

And the Gradle equivalent, written with the older compile configuration.

        compile 'com.netflix.hollow:hollow:5.1.3'

The important detail is the version. The README table lists 5.1.3 as the latest stable version, and the download badge points at a bintray endpoint, and the release candidate instructions point at a bintray URL for the oss-candidate repository. Meanwhile the tags in the project are in the 7.15 line, with v7.15.3 from 2026-10-02, v7.15.3-rc.1 from 2026-09-30 and v7.15.2 from 2026-09-22.

So the installation instructions in the README are from a much older point in the project's life than the code. Do not take the version number from the README; take it from the repository's release list and from Maven Central, where the project says the release binaries are available.

For a project whose whole purpose is to be a shared dependency inside other people's build, a stale installation snippet is a genuine problem rather than a cosmetic one, because it is the first thing a new user copies.

The adapters, and the tools around them

The repository is a multi-project Gradle build, and the directory names describe the pieces of the system.

There are three adapters, which are the ways a dataset gets into Hollow. hollow-protoadapter, hollow-jsonadapter and hollow-zenoadapter are three different serialisation formats, and hollow-fakedata is a generator of fake data for testing, which is a necessary piece for a project whose whole value depends on realistic dataset sizes.

Then the core library, hollow/, and the supporting modules. There is hollow-perf, a performance module, hollow-test, the test module, and hollow-ui-tools, the shared code for the user interfaces.

The user interfaces are the interesting ones for an adopter deciding whether they will actually use this. hollow-diff-ui shows what changed between two snapshots, which is the feature that makes a push based dataset operable: when a consumer starts behaving differently, the question is always what changed, and a diff tool is the answer. hollow-explorer-ui is for browsing the dataset itself, which is what you need when you are modelling a new consumer and need to know what the data actually contains.

There is also a config directory, a docs directory and the top level build files, and the CHANGELOG.md is present, so the release history is in the repository rather than only in the tag messages.

Taken together, the modules describe a pipeline: produce a snapshot in one of the supported formats, publish it, let consumers read it in memory, and use the diff and explorer tools to understand what changed and what is in it.

Gradle for the code, a Makefile for the work around it

The build is Gradle, with the wrapper committed, and the Makefile on top of it is a convenience layer for the tasks that are not the Java build.

make build

That runs the Gradle build. The test target runs the Gradle testAll task, and the clean target runs the Gradle clean task. The wrapper is invoked as./gradlew, so the build does not depend on a system Gradle installation.

The Makefile is a good example of a project keeping two toolchains side by side. The Java side is Gradle with build.gradle, settings.gradle, a gradle directory and a gradlew wrapper, plus a dependencies.lock file that pins the dependency versions so that a build is reproducible. The documentation side is Python with MkDocs, and there are two included makefiles,.makefile.inc and.makefile.identity.inc, that hold shared fragments.

The Makefile itself has a small bug worth noting because it is charming. The project name is defined as the basename of the current directory, and the shell call there is misspelled as SHELl rather than shell. The same file also sets the default goal to help, and the help target prints a list of available targets by running a helper script over the makefiles, with the identity include supplying the banner.

The practical upshot is that a contributor who only wants to build the Java does not need Python installed, and a documentation contributor does not need a Java toolchain.

The documentation site, which needs a Python virtualenv

The docs are built with MkDocs and served locally, and the instructions are in the README.

make site-serve

That starts the MkDocs server at http://127.0.0.1:8000/. There is also a site-build target to build the site locally, a site-deploy target to deploy it to GitHub, and a site-clean target that removes the site directory.

The site targets depend on a venv target, which creates a virtual environment if it does not already exist, using virtualenv with python3, and then installs the requirements into it with pip. The requirements file is short, with mkdocs pinned to a 1.4 series and mkdocs-material to a 9.1 series, and the comment above it says these are the requirements for building the docs.

The README is honest about the assumptions here. MkDocs runs with Python, the Makefile via the venv task should take care of setting up the virtual environment for the site tasks, and it assumes that virtualenv is available as a command and that the target is python3. Installing Python 3 is out of scope, and the project points at your operating system package manager, with homebrew suggested for macOS.

The configuration is a mkdocs.yml at the top level and a deploy_docs.sh script, and the docs directory holds the content.

Ownership, support, and what a good release cadence looks like

Hollow is maintained by the Platform Data Technologies team at Netflix, and support is obtained directly from the team or from other users through Gitter, or by opening an issue in the project.

That ownership statement is the thing to weigh in an evaluation. The library is used inside Netflix, which is the strongest possible signal that the design survives contact with a large production system, and it also means the priorities are the priorities of a platform data team rather than of the wider Java community. The project is not trying to be the general purpose answer for in-memory data distribution, and it does not need to be.

The release history shows a project that is very much alive, with v7.15.3 from 2026-10-02 following v7.15.3-rc.1 from 2026-09-30, which is the release candidate for the same version published two days before the final, and v7.15.2 from 2026-09-22. The last push was on 2026-10-14, and the repository is not archived.

The licensing is the standard Apache 2.0 text with a copyright of 2016 Netflix, Inc., and the repository carries a NOTICE file and an OSSMETADATA file, which are the artefacts a project publishes when it wants to be clear about what it contains and under what terms.

There is also a NetflixOSS Lifecycle badge in the header, which is the signal for the state of the project as a whole, and a Gitter badge for the chat. The build status badge points at Travis CI, which is another detail from the earlier era of the project.

Editorial conclusion

Adopt Hollow if you have a service that publishes a large, read-mostly dataset to many JVM consumers and want the consumers to hold it in memory rather than query a database, since that is the problem the project was built to solve at Netflix scale. Do not adopt it for frequently changing data or for a small dataset, because a producer that pushes snapshots pays for the dissemination. Before you commit, check the current release on Maven Central rather than the version in the README, because the README still lists 5.1.3 while the tags are in the 7.15 line, and read the docs on hollow.how to see how the read side is meant to be wired into your application.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Netflix/hollow on GitHub
4. README
5. Releases