How Palo Alto Networks Built a Zero-Downtime, Multi-Region SASE Health Portal with MongoDB Atlas

This guest blog post is from Kunal Kannav, Principal Site Reliability Engineer for Palo Alto Networks—a global cybersecurity leader delivering best-of-breed platforms, world-class threat intelligence and expert services to deliver what’s next in cybersecurity.

In the high-stakes arena of enterprise cybersecurity, a service health status portal is far more than a dashboard—it is the ultimate currency of customer trust.

At Palo Alto Networks, our Prisma SASE (Secure Access Secure Edge) platform secures the hybrid infrastructure of the world's largest enterprises, providing best-in-class security to one-third of the Fortune 500. When operating at such a massive global scale, delivering crystal-clear, real-time visibility into service health is a critical business imperative. If a network disruption occurs on the public internet, enterprise security teams need to know instantly how it impacts their network.

To deliver this unparalleled, visual "source of truth," we recently launched the new Palo Alto Networks SASE Health Portal. Building a global service health status portal presents a daunting engineering challenge— providing maximum redundancy to keep customers informed during an incident.

To achieve this, we had to rethink our architectural foundations from the ground up. We needed our communication and status-tracking layer to remain highly available, even when underlying cloud infrastructure was degraded or failing. This is the breakdown of how we translated our blueprint into a resilient production reality, leveraging the globally distributed foundation of MongoDB Atlas.

The breaking point: Scaling past legacy data structures

During major public cloud outages, global BGP routing leaks, or third-party CDN degradations, traffic to a status page doesn't just grow—it spikes exponentially. Because Prisma SASE serves as the critical security gateway connecting remote enterprise employees to their hybrid cloud applications, any downstream network degradation immediately points suspicion toward the secure edge.

In these critical moments, enterprise network administrators flood our health portal to answer a high-stakes triage question: Is the bottleneck localized within our secure Palo Alto Networks systems, or is the downstream public cloud hosting region experiencing a systemic outage?

To provide instant clarity during global events, our SREs regularly prepare our status engines to handle sudden traffic surges within minutes.

Initially, our backend data strategy relied heavily on cloud data warehousing and traditional relational database clusters. While exceptional for internal historical analytics, this tightly coupled, rigid-schema architecture presented two major friction points for real-time, high-pressure incident communication:

1. The schema migration bottleneck: In a relational database, managing a highly complex, nested user subscription matrix requires intricate table structures and performance-draining JOIN queries. Every time our product teams wanted to onboard a new SASE service, regional gateway, or subscription tier, we had to execute expensive schema migrations (ALTER TABLE commands). These migrations risked locking active database tables at the very moment we needed maximum throughput.
2. Fate-sharing & regional lock-In: Relying on a single, rigid cloud database meant that our service health status portal’s availability was inherently bound to a localized cloud region. If that specific hosting region experienced a catastrophic outage, our portal risked going down with it, violating the core principles of resilient systems engineering.

We needed to stop spending valuable engineering cycles fighting database migrations and focus on what we do best: building highly resilient, feature-rich customer experiences. We needed a transactional data store capable of handling highly dynamic profiles under sudden write/read surges, with true survivability.

The blueprint: Designing for multi-region resilience

To insulate our customers from localized cloud failures, our architects designed a decentralized, topologically dispersed application.

We deployed our containerized application services across multiple geographically isolated cloud zones, running in active-active configurations across our Kubernetes clusters. This enables our frontends, API routing layers, and microservices to not share fate with any single localized hosting region or zone.

To power this application layer, we required a database backend that matched our geographical footprint and provided low-latency data replication. We turned to MongoDB Atlas to serve as our globally replicated, highly flexible persistence engine, focusing our integration on two key technical capabilities:

1. Global high availability

To secure our data layer from regional outages, we established a resilient, multi-region MongoDB Atlas cluster spanning three distinct geographical zones across our cloud network.

Because MongoDB Atlas natively supports automated cross-region replication, our critical system health states are replicated in real time across different zones.

In the rare event of a total regional outage in our primary zone, MongoDB’s automated failover mechanism seamlessly promotes a secondary node in an alternative region to primary status. The SASE Health Portal application instantly continues to read and write health telemetry without a single dropped connection or manual operator intervention.

Figure 1. High-level SASE Health Portal multi-region data architecture.

2. Eliminating alert fatigue with dynamic document modeling

A primary functional goal of our modernized SASE Health Portal was to combat "alert fatigue" for our customers. Security administrators shouldn't be inundated with alerts about a localized data plane issue on another continent. We wanted to empower them to subscribe only to the precise products, components, and geographic regions that directly impact their active business footprint.

To achieve this without degrading database performance, we moved away from relational tables and designed our subscription engine around MongoDB’s flexible, polymorphic JSON model. We represent deeply nested, customized customer profiles inside single, self-contained documents:

Figure 2. JSON schema for a subscriber's Prisma Access and SD-WAN subscriptions.

By leveraging this model, we achieved three massive engineering victories:

• Zero relational joins: Our notification microservices query a single document per user, enabling us to match incoming system incidents to customer profiles in microseconds.
• Frictionless onboarding of complex products: When rolling out a new security service with distinct attributes or regional parameters (e.g., dynamic AI security inspection planes), we avoid risky schema migrations. We simply update the application-level logic to write the new fields into the JSON documents. The database accepts the polymorphic structure on the fly with zero downtime, proving that our data foundation is built for continuous change.
• Simplified engineering cycles: Our developers can focus on shipping features and writing clean, object-oriented code, rather than translating data objects back and forth across complex relational mappings.

The engineering verdict: A new standard for transparency

By pairing Palo Alto Networks' robust multi-region application design with the globally resilient data foundation of MongoDB Atlas, we transformed the Health Status portal for Prisma SASE Services from a standard web dashboard into an ironclad, enterprise-grade transparency platform.

We successfully decoupled operational monitoring from localized cloud fates, automated rapid failover paths, and gave our customers the granular control they need to defend their networks from alert fatigue.

For enterprise engineering teams, the lesson behind the SASE Health Portal is clear: building lasting customer trust starts at the data layer. When you design an application with a highly flexible schema and a resilient, provider-agnostic database architecture, you ensure your platform stays operational when your customers need it the most.