How Netflix Uses Java and Project Leyden to Improve Startup Performance

 The speaker began by asking the audience a simple question: “Who here uses Netflix?” Nearly everyone raised their hand. For those unfamiliar with Netflix, he explained that every interaction with the Netflix app—whether on a phone, laptop, or TV—involves communication with thousands of backend services.

Whenever a user searches for a show, clicks a button, or receives a recommendation, the Netflix application communicates with multiple services running behind the scenes. Each of these services may have hundreds or even thousands of running instances.

Most of these services are built using Java. In fact, Netflix runs a massive amount of Java applications across its infrastructure. While the company also uses other programming languages, the focus of the talk was on Java and the Java Virtual Machine (JVM).

Netflix Infrastructure and AWS

Netflix primarily runs its services on Amazon Web Services (AWS). Their infrastructure is distributed across multiple AWS regions around the world.

Normally, this setup works extremely well. However, when an AWS region experiences problems or outages, Netflix shifts traffic away from the affected region to healthy ones. This sudden increase in traffic requires services in the remaining regions to scale rapidly.

Most JVM-based services can automatically scale by launching additional JVM instances. Users usually never notice these failovers because the system responds automatically.

However, not all services start quickly enough. Some applications have slow startup times, which prevents them from participating effectively in auto-scaling environments.

To solve this issue, Netflix traditionally maintained idle JVM instances running in every region. These standby services were ready to handle traffic immediately during failures, but this approach was expensive because many resources remained unused most of the time.

This created strong motivation for Netflix’s Java and JVM teams to improve startup performance.

Introducing Project Leyden

Netflix became very interested in Project Leyden because it promises faster startup times for Java applications.

Project Leyden focuses on improving Java startup speed and reducing warm-up time. It achieves this by moving some JVM operations from runtime to “ahead-of-time” (AOT) processing.

Normally, tasks such as class loading and class linking occur during application startup, which slows applications down. Leyden allows many of these tasks to be completed earlier, before the application starts serving traffic.

For Netflix, this was especially valuable because reducing startup times would allow more services to participate in auto-scaling, reducing the need for expensive idle infrastructure.

Challenges of Using Leyden in Production

Although Netflix saw promising results with Leyden, integrating it into a large production environment was not straightforward.

Using Leyden is more complicated than simply enabling a JVM flag. Because AOT processing happens outside runtime, it introduces operational complexity.

Netflix needed to determine:

• Where to capture AOT training data
• How to distribute AOT archives
• How to ensure compatibility between environments
• How to integrate everything into existing deployment pipelines

Several requirements had to match between the environment where recordings were created and where they were later used:

• The classpath had to be identical
• JVM versions and configurations had to match exactly
• Operating systems and CPU architectures needed to match
• CPU features such as vectorization support also needed to align

If these conditions were not satisfied, applications would still run, but they would lose the performance benefits of AOT optimization.

Finding the Best Place to Capture Training Data

Netflix evaluated several stages of their deployment pipeline:

Local Builds

Local development environments were unsuitable because developers often used different operating systems, CPU architectures, and JVM versions.

CI Builds

Continuous Integration environments solved some compatibility problems but still lacked exact JVM and runtime consistency.

Test Environments

Testing environments matched production more closely, but they did not experience realistic production traffic patterns.

Production

Production traffic represented the ideal workload, but capturing recordings directly in production introduced too much operational complexity.

Canary Testing: The Ideal Solution

Netflix eventually chose canary testing environments.

Canary deployments are small production-like deployments that receive real user traffic before full rollout. These environments provided:

• Realistic production traffic
• Matching hardware and operating systems
• Identical JVM versions and configurations
• Natural start and end points for capturing recordings

The team jokingly described this strategy as:

“Just-in-time ahead-of-time.”

How Netflix Implemented the Workflow

Netflix integrated AOT handling directly into their application startup scripts.

When a service started inside a canary environment:

1. An AOT orchestrator process launched
2. The main application started normally
3. The orchestrator monitored the canary deployment
4. Once canary testing completed, the orchestrator gracefully terminated the application
5. The JVM generated the AOT archive
6. The archive was uploaded to storage

The archive names included:

• Application name
• Cluster details
• A hash of the classpath

This ensured that production systems used only compatible AOT recordings.

Optimizing Uploads and Downloads

Netflix compressed AOT archives using the Zstandard algorithm because it offered:

• Excellent compression ratios
• Fast compression and decompression
• Parallel upload and download support
• Metadata embedding capabilities

Archives were typically around 200 MB before compression, but Zstandard reduced their size dramatically.

The download process was heavily optimized because startup speed remained critical. Netflix parallelized downloads and reconstructed archives in memory to minimize delays.

Security Considerations

To prevent tampering:

• Each archive received a cryptographic digest
• Digests were signed using application identities
• Downloads verified signatures and file integrity

Netflix decided not to encrypt the archives because they contained no sensitive information.

Performance Results

The results were encouraging.

One benchmarked application showed:

• Original startup time: 50 seconds
• Startup with Leyden AOT: 40 seconds
• Download overhead: 2 seconds
• Net improvement: 16%

Netflix emphasized that these were real production applications, not small demonstration projects.

Warm-Up Performance

Although Leyden improved startup speed, Netflix had not yet observed major improvements in JVM warm-up time.

The team explained that future benefits are expected once Project Leyden supports caching compiled code, allowing production JVMs to skip expensive JIT compilation phases.

Future Plans

Netflix plans to expand this infrastructure across all compatible JDK 25 applications using canary deployments.

They are also exploring:

• Earlier archive downloads during container initialization
• Sidecar containers containing preloaded AOT caches
• Improvements arriving in JDK 26 and future JDK 25 updates

The team believes that investing in Leyden now will allow Netflix to benefit automatically from future JVM improvements.

Why Not GraalVM Native Image?

During the Q&A session, audience members asked why Netflix did not use GraalVM Native Image instead.

The Netflix engineers explained several reasons:

1. Their services are long-running systems where peak JVM performance matters more than startup alone.
2. GraalVM Native Image requires substantial operational and application changes.
3. Supporting thousands of services would make migration extremely difficult.
4. Leyden preserves the dynamic behavior and optimizations of the JVM.

They emphasized that they admire GraalVM and see value in it for smaller tools and specialized workloads, but it was not the right fit for Netflix’s large-scale service ecosystem.

Conclusion

Netflix demonstrated how large-scale Java deployments can benefit from Project Leyden in practical production environments.

Their implementation:

• Reduced startup times significantly
• Avoided centralized orchestration systems
• Integrated smoothly into existing deployment pipelines
• Leveraged real production traffic for training

Although the system is still evolving, Netflix sees Project Leyden as a promising step toward faster, more scalable Java applications in the future.