Search and reporting service

The infrastructure model outlines a standard containerized cloud deployment architecture of Pega Infinity, with an externalized Search and Reporting Service, as shown in the following figure. Externalizing the Search and Reporting Service involves separating the full-text search functionalities from the Pega Platform and running them as an independent microservice in the cloud. This approach enables you to scale, manage, and monitor the search service independently from the Pega nodes.

Lead System Architects (LSAs) select deployment architecture patterns based on organizational requirements, technical constraints, and operational capabilities. Each pattern involves trade-offs related to isolation, resource efficiency, operational complexity, and scalability.

Pattern 1: Dedicated Search and Reporting Service for each environment

Each Pega Platform environment (development, testing, staging, and production) uses a dedicated SRS instance deployed in Kubernetes. Non-production environments typically use smaller SRS deployments with fewer replicas and smaller Elasticsearch clusters. Production environments use a fully scaled, highly available configuration.

Benefits

This deployment approach provides several advantages:

• Maximum isolation between environments. Issues in development or testing do not affect production.
• Ability to run different SRS versions in different environments, which enables update testing before production rollout.

Considerations

This pattern involves higher infrastructure cost and operational overhead because each SRS instance requires separate Kubernetes resources and an Elasticsearch cluster.

A dedicated SRS is ideal for organizations that require strict isolation, such as regulated industries where production data must remain segregated, or organizations with separate teams that manage environments independently.

Pattern 2: Shared multi-tenant Search and Reporting Service across non-production

A single multi-tenant SRS instance serves all non-production environments (development, testing, and staging), while production uses a dedicated SRS instance. Each non-production environment connects as a separate tenant to support data isolation.

Benefits

This approach offers the following advantages:

• Reduced infrastructure cost compared to fully dedicated instances.
• Maintains isolation for production search features.

Considerations

Shared non-production SRS must be sized for the combined load, which is typically less than the production load.

This pattern works well when non-production usage differs from production, such as development and testing activity during business hours versus a continuous production load.

Pattern 3: Fully shared multi-tenant Search and Reporting Service

A single multi-tenant SRS instance serves all environments, including production. Each environment connects as a separate tenant with strict data isolation enforced by SRS. The shared Kubernetes deployment and Elasticsearch cluster must handle the combined peak load.

Benefits

This approach provides the following advantages:

• Lowest infrastructure cost and operational overhead.
• Only one SRS deployment to monitor, maintain, and upgrade.

Considerations

Review these factors before selecting this pattern:

• Requires advanced capacity planning to prevent overload.
• Performance issues or maintenance events affect all environments.

This pattern is best suited for organizations with limited infrastructure budgets, smaller scale, or mature DevOps practices. Robust monitoring and defined scaling processes are essential to manage growth and prevent cross-environment impact.

Search and Reporting Service supports the following use cases:

• Finding Case and Data Objects
  Pega developers and users can find Case and data objects that contain a given word or phrase in the values of any properties.
• Filtering Case and Data Objects
  Pega Developers and End Users can find Case and data objects that match a single filter condition or a combination of filter conditions (compounded with AND / OR) with comparators such as =, !=, <, <=, >, >=, and between.
• Finding Rules
  Pega developers can find Rules that contain a given word or phrase in the values of any text properties.
• Unaggregated/summary queries
  Pega developers and users can perform unaggregated/summary queries through report definitions.
• Enforcing security policies
  The system enforces RBAC policies defined on classes and ABAC policies defined on the properties of classes that pass as filters to the service.

• Multi-tenancy
  Multiple instances of Pega Infinity environments can connect to the same Search and Reporting Service instance and store data with appropriate data isolation.
• Scalability
  Both Search and Reporting Service Pods and the AWS Elasticsearch cluster can scale independently of Pega Infinity nodes.
• Independent release cycles
  Search and Reporting Service has a release cycle independent of  Pega Infinity, which means the Service API is backward compatible. Earlier versions of Pega Infinity can continue to use newer versions of Search and Reporting Service.

Check your knowledge with the following interaction: