Pega deployment architecture

A Pega node is a runtime instance of Pega Platform. In a containerized deployment, a Pega node runs in a Kubernetes pod.

Node types identify the categories of work that Pega Platform assigns to a node. Examples include web application processing, background utility processing, search processing, Pega Business Intelligence Exchange™ processing, and decisioning workloads.

A deployment tier is a logical and operational group of Pega nodes that share deployment settings. These settings include assigned node types, resources, configuration, replica count, and scaling strategy. In a containerized environment, the Pega Helm chart configuration assigns one or more node types to each tier.

Separating workloads into tiers prevents resource-intensive background processing from affecting interactive user requests. Tier separation also lets architects allocate and scale resources independently for different workloads.

By default, a Pega Platform deployment includes two primary tiers:

A deployment can define additional tiers when workloads require separate resources, configurations, availability settings, or scaling strategies. For example, a decisioning deployment might isolate Adaptive Decision Manager (ADM), Real-Time Data Grid (RTDG), batch, or real-time processing in dedicated tiers. The names and groupings of these additional tiers depend on the deployment.

Pega Platform includes 16 standard node types. For more information, see Node types for containerized deployments.

The Pega database provides persistent storage for Pega Rules and Pega-managed application data. All Pega nodes in the cluster access the database.

Pega Platform recommends a split-schema configuration in which Rules and application data reside in separate schemas:

A split-schema configuration improves maintainability and supports out-of-place update and patch processes. In a highly available system, an out-of-place process can support near-zero downtime.

A deployment can also use an optional customer data schema to store data that is not specific to Pega separately from the default Pega data schema. The application and enterprise data architecture determine whether to use a customer data schema.

The Pega database is not necessarily the system of record for all enterprise data that an application uses. External business systems can remain authoritative for the data that they own. Externalized platform services maintain their own service-specific state.

Because every Pega node depends on the database, architects must address database capacity, performance, availability, backup, recovery, security, and future growth.

Backing services extend the capabilities of Pega Platform. These services run separately from Pega nodes and the database. They support specialized functions such as search, reporting, and the Pega Constellation™ user experience.

The following backing services are commonly used in Pega Platform deployments:

External services are third-party technologies that Pega Platform uses for capabilities that are outside the core platform. Services such as Apache Kafka, Elasticsearch or OpenSearch, and Apache Cassandra run separately from Pega Platform. Organizations can manage, update, and scale these services independently.

The following externalized services are commonly used in Pega Platform deployments:

Consult the Platform Support Guide before selecting an external service product or version.

Add-on services are optional infrastructure services that help organizations operate and manage a Pega Platform deployment. These services support requirements such as traffic routing, access management, logging, and monitoring.

The following add-on services are available for Pega Platform deployments:

Pega provides add-on services for organizations that require a ready-to-use operational foundation. Organizations can instead use enterprise-standard tools that meet their deployment requirements.

A typical user request enters through a load balancer or Kubernetes ingress and is routed to a Pega pod in the web tier. The Pega node accesses Rules and application data in the relational database. The node invokes backing services or external services when the requested capability requires them. Nodes in the batch tier or additional specialized tiers process background work.

Multiple replicas in the web tier do not make the complete application highly available. The database and each required backing or external service must also meet the availability and recovery objectives of the application.

The following diagram shows the application services, backing services, external technologies, and optional add-on services in a containerized Pega Platform deployment:

Pega Platform supports multiple deployment models for different enterprise and regulatory requirements. Each model defines where Pega Platform runs and which organization manages the infrastructure.

• Pega Cloud®: A Pega-managed deployment model in which Pega operates the platform and infrastructure services.
• Client-managed cloud: A deployment model in which Pega Platform runs in the client’s cloud environment, and the client manages the infrastructure.
• Pega Cloud for Government: A deployment model that supports governmental security and compliance requirements.

The LSA must understand the responsibility boundary for the selected deployment model. A client-managed deployment requires clear ownership of the Kubernetes platform, database, ingress, external services, logging, monitoring, security, backup, recovery, patching, and capacity management.
 

Check your knowledge with the following interaction: