The hardest part of modern infrastructure isn’t choosing your deployment environments — it’s bridging communication between them. Large enterprises are constantly facing the challenge of keeping everything connected, secure, and fast when their infrastructures are spread across different clouds and on-premises systems.
PayPal faces this challenge every day, managing a global infrastructure that processes $1.6 trillion in annual payments across 436 million active accounts. Their environment is a complex mix of on-premises data centers and three major cloud providers (AWS, GCP, and Azure). With over 3,500 applications in service — some modern, others still relying on HTTP/1.1 — they dealt with overlapping CIDR / IP addresses, where multiple business units used the same private IP address ranges, and inconsistent cloud-native tools that made seamless communication difficult.
To solve this, they didn't just patch their network; they built a Universal Mesh with HAProxy Enterprise load balancer and HAProxy Fusion Control Plane. This unified connectivity fabric, known internally as Project Meridian, supersedes earlier mesh technologies to provide a holistic framework for internal and external application delivery. Meridian serves as a universal translator across conflicting networks, creating a multi-tenant solution that eliminates the need to reinvent access patterns for every cloud provider.
In their recent HAProxyConf presentation, Senior Staff Network Engineers Kalaiyarasan Manoharan and Siddhartha Mukkamala detailed PayPal’s transformation. Here are the seven key steps they took to master multi-cloud networking.
1. Identify core challenges
The PayPal environment presented a number of challenges that demanded a unified solution:
Connectivity. The core PayPal business and its business units, such as Braintree, Venmo, and Zettle, had applications spread across AWS, Azure, and GCP, with no unified way to communicate between them or share core services.
Overlapping CIDR / IP addresses. Most business units used the same network ranges/subnets, making direct routing impossible. Overlap in private IP address space and subnets necessitated the routing of traffic over the public internet to connect services across different clouds, as there was no way to distinguish between identical internal addresses within different business units.
Exposing services. Without a private path, services often had to communicate over the public internet, which increased latency and expanded the attack surface.
Visibility. There was no "single pane of glass" to view end-to-end traffic flows, making troubleshooting a nightmare.
Any solution had to address these challenges, making inter-service communication faster, easier, and more secure, with improved observability.
2. Specify the architectural approach
PayPal’s goal was to create a "reusable solution that can abstract the complexity of the cloud providers." They envisioned a connectivity fabric that would provide a simple and unified way for business units to communicate securely, regardless of where any given service or data resource was hosted.
The project was split into two main components:
Inner Meridian: Handles private connectivity between internal business units and internal cloud services.
Outer Meridian: Manages connectivity to external partners, SaaS providers, and AI models, such as GCP Gemini.
This simple division divided up the challenges involved in the overall solution into two manageable buckets.
3. Build a non-overlapping IP fabric
The most significant hurdle for Project Meridian to overcome was the overlapping CIDR / IP addresses. This overlap drove PayPal to expose many endpoints over the public internet. Project Meridian pulls these endpoints off the public grid.
How did they do it? Instead of re-IPing thousands of servers (a multi-year nightmare), PayPal's engineers created a neutral zone using the 198.18.0.0/15 IP address range (defined in RFC 5735). This special-use range is designated for testing and is not routable over the public internet. This allowed them to leave the internal IP addresses alone and translate them only at the edge.
By building their "Meridian Edge Services Fabric" with this non-overlapping range, they created a private "bridge" that allowed all business units to communicate without re-addressing their entire existing infrastructure.
Furthermore, HAProxy Enterprise’s ability to perform Source Network Address Translation (SNAT) allows Meridian to create a virtual network across incompatible existing networks. NATing makes traffic from outside a network appear as if it originated locally, without any changes to an application’s network configuration.
This clever move created a private, non-overlapping, intermediary network layer with its own unique IP space. This allows PayPal to connect all the disparate cloud environments, without needing to “re-address” existing infrastructure.
4. Deploy HAProxy Enterprise as the multi-cloud gateway
While PayPal initially explored cloud-native services, they soon realized they needed a more flexible, vendor-agnostic tool. They chose HAProxy Enterprise as the core component because it provided a unified, multi-tenant solution that works the same way in AWS as it does in GCP, Azure, or on-premises.
They deployed HAProxy Enterprise clusters, known as Meridian Edges, across different clouds and regions for each business unit to ensure high availability. These edges handle the heavy lifting: SSL termination, protocol translation (converting HTTP/1.1 to modern HTTP/2), and Source Network Address Translation (SNAT) to bridge the different IP ranges.
HTX, the HTTP abstraction layer in HAProxy, is responsible for parsing and converting different HTTP versions, the HTTP multiplexers, and the application part. It standardizes the representation of messages between the different versions of HTTP.
5. Implement smart routing
With the CIDR problem solved, PayPal needed a way to route traffic to the correct application. Traditional DNS propagation is too slow for dynamic cloud environments. Instead of relying on complex DNS subdomains, they adopted a simple and effective strategy that leverages HAProxy Enterprise’s powerful path-based routing capabilities.
By moving routing logic out of DNS and into the mesh (HAProxy), PayPal decoupled service location from network location. This is a hallmark of Universal Mesh architecture.
For example, a request destined for "App 2" in "Business Unit 2" is sent to a unified endpoint, such as example.paypal.com/bu2/app2. The HAProxy Enterprise-powered Meridian Edge at the source receives the request and terminates the SSL. Using a dynamic map file, HAProxy Enterprise performs a high-performance lookup of the URI path to determine the exact destination Meridian Edge. This allows for granular, intelligent traffic steering without the administrative overhead of managing thousands of individual DNS records.
The destination HAProxy Enterprise instance rewrites the intended URI path and forwards the request to the internal application, making the entire process seamless for the end services: “the Meridian Edge Service Fabric is an entirely private path.”
6. Centralize observability and control
To manage this distributed network of HAProxy Enterprise clusters, PayPal uses HAProxy Fusion as its management layer. This provides a "single pane of glass" where engineers can look up a unique correlation ID to see exactly how a request performed at every hop—from the network round-trip time to the application response time.
This provides clear evidence of where a bottleneck actually exists, leading to faster resolution.
7. Measure the results and build forward
The impact of Project Meridian has been transformative for PayPal:
24% latency reduction: By redirecting traffic away from the public CDN path and onto the private fabric with persistent HTTP/2 connections, they achieved a significant performance improvement.
Enhanced security: Moving applications to an entirely private path significantly reduced their external attack surface.
Operational efficiency: Service onboarding is now much faster. Once a service is in the Meridian directory, other units can connect to it easily without weeks of manual firewall tickets.
Conclusion
With Meridian, all three major public cloud providers, as well as any in-house assets that PayPal controls, function as a single, unified set of services and resources. A payments API in AWS can communicate with a risk API in GCP and then a compliance API in Azure, eliminating the need to generate traffic across the public internet. Most enterprise companies can only be envious of such an effective solution.
As Siddhartha concluded, “Building that private connectivity between the business units is especially hard when there is an IP address overlap. We partnered with HAProxy, which helped us provide consistent connectivity across cloud providers.”
And PayPal isn't finished yet. They are currently working on a self-service automation model and partnering with HAProxy to implement advanced service discovery. This will further accelerate PayPal’s ability to innovate across its global footprint.
PayPal’s Meridian is a powerful real-world use case of Universal Mesh succeeding at enterprise scale. Universal Mesh is a unified connectivity fabric designed to solve the challenges of traditional networking and fractured connectivity models. It is an emergent architectural pattern that provides a holistic framework for application delivery, superseding earlier mesh technologies by addressing a broader scope of problems with a more elegant and scalable design.
Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.
