Pega Runtime Architecture – How Nexus Runs at Runtime
Application Architecture – Runtime Deep Dive
We have already designed the Alpha Bank Nexus application from the application, case, data, integration, inheritance, and security perspectives. But there is one important question left: How does the application actually run?
When John opens a Customer Onboarding case, clicks Submit, and expects Pega to validate the data, execute business rules, call KYC, save the Case, and return the next screen, a lot happens behind that single click.
The browser is only one small part of the runtime architecture. The request travels through the load balancer, Pega web tier, application context, Access Group, Application Version, Ruleset Stack, class hierarchy, rule resolution, business logic, database, integrations, background processing, and monitoring components.
This article walks through that complete runtime path using the Alpha Bank Nexus application.
1. Explain Pega Runtime Architecture
Pega runtime architecture is the collection of components that work together to execute a Pega application after it has been deployed.
At a simplified level, the Alpha Bank Nexus runtime looks like this:
User / API Client
↓
Load Balancer / Ingress
↓
Pega Web Tier
↓
Authentication / Session
↓
Operator + Access Group
↓
Application + Application Version
↓
Ruleset Stack
↓
Class Hierarchy
↓
Rule Resolution
↓
Case / Data / Business Logic
↓
┌───────────────┬────────────────┬──────────────────┐
│ │ │ │
Database Integrations Background Processing Search
│ │ │ │
└───────────────┴────────────────┴──────────────────┘
↓
Response / Updated Case State
Modern Pega deployments can contain multiple runtime nodes working together as a cluster. The nodes share application rules and data through common persistence infrastructure, while interactive and background workloads can be distributed across the deployment.
Pega describes a node as a runtime instance of Pega Platform. Nodes can be organized into processing tiers such as web and batch/background tiers.
Runtime architecture is not simply "browser → Pega server → database." The important architectural question is: which runtime component performs which responsibility, under what execution model, and where does the state live?
The major runtime building blocks
| Component | Primary Responsibility |
|---|---|
| Browser / Client | User interaction and HTTP requests |
| Load Balancer | Routes traffic across available Pega nodes |
| Pega Web Node | Processes interactive requests |
| Application | Defines application context and referenced components |
| Access Group | Determines application context and runtime authorization context |
| Ruleset Stack | Determines which Rules are available and their precedence |
| Class Hierarchy | Determines where Rules can be inherited from |
| Database | Persists Rules, Cases, configuration, and application data |
| Search | Supports indexed search and related capabilities |
| Background Processing | Executes asynchronous work, scheduled work, and other background workloads |
2. What Happens When a User Submits a Request to Pega?
Let's use a real Nexus example.
John is an Alpha Bank employee. He opens a CustomerOnboarding Case, enters customer information, and clicks Submit.
At a high level:
- The browser sends an HTTP request.
- The request reaches the load balancer or ingress.
- The request is routed to an available Pega web node.
- Pega identifies the authenticated user/session.
- The user's Access Group provides the application context.
- The Application Version determines the application configuration.
- The runtime uses the Ruleset Stack for rule availability and precedence.
- The requested operation is mapped to Pega runtime behavior.
- Rule resolution identifies the applicable rules.
- Case data is validated and processed.
- Data Pages and integrations may be invoked.
- Database changes may be persisted.
- Background work may be queued.
- The resulting response is returned to the client.
Example: CustomerOnboarding Submit
Suppose the Submit action needs to:
- Validate mandatory customer fields
- Validate date and address information
- Perform duplicate customer checking
- Call KYC
- Evaluate AML rules
- Create or update customer information
- Move the Case to the next stage
- Assign the next work item
- Persist the Case
Not all of these activities necessarily execute in the same request. This is one of the most important runtime architecture concepts.
3. Walk Me Through the Complete Request Lifecycle
This is one of the most important Principal-level interview questions.
A strong answer should explain the request from the browser all the way to rule execution and persistence.
Step 1 – Browser Creates the Request
John clicks Submit. The client-side Pega UI generates the appropriate request to the server.
Depending on the UI technology and operation, the request may represent a Case action, data operation, navigation request, API request, or other server-side operation.
Step 2 – Network Layer Receives the Request
The request enters the enterprise network through the configured entry point, typically a load balancer or ingress layer.
The load balancer determines which available Pega web node should receive the request.
Step 3 – Pega Web Node Receives the Request
The selected Pega web node becomes responsible for processing the interactive request.
The web node identifies the appropriate Pega runtime/session context and processes the request through the Pega application.
Step 4 – Authentication and Operator Context
Pega needs to know who is making the request.
The runtime establishes or uses the authenticated Operator context. Depending on the security architecture, authentication may involve Pega authentication or an external Identity Provider such as an enterprise SSO/SAML provider.
Step 5 – Access Group Determines Application Context
The Operator's Access Group is extremely important because it establishes the application context used for the session.
The Access Group references an application and version. Pega uses that application context to assemble the Ruleset Stack.
Step 6 – Application Version Is Resolved
Suppose John's Access Group points to:
The runtime uses that application definition and its referenced application components to establish the available rule environment.
Step 7 – Ruleset Stack Is Established
The Ruleset Stack determines which Rulesets are available to the session and their precedence.
For example, conceptually:
AlphaBank-Framework
AlphaBank-Enterprise
Pega Platform
These names are illustrative for Nexus. The actual deployed Ruleset names depend on the application's implementation.
Step 8 – Runtime Identifies the Operation
Pega now needs to determine what the request is asking it to do.
For a Case action, this could involve a Flow Action, validation, process transition, assignment creation, data operation, or other rule-driven behavior.
Step 9 – Rule Resolution
Pega does not simply search for a rule by name.
Rule resolution considers the requested rule, the Apply To class, class inheritance, Ruleset availability and precedence, and other rule-resolution factors such as availability and specialization.
For example, suppose Nexus has:
└── Alpha-Banking-Work-CustomerOnboarding
A rule requested from Alpha-Banking-Work-CustomerOnboarding may be found in that class or inherited from an appropriate parent class, depending on the rule-resolution context.
Step 10 – Business Logic Executes
The selected rules execute.
This can involve:
- Validation Rules
- When Rules
- Decision Tables
- Decision Trees
- Data Transforms
- Flow Actions
- Activities where appropriate
- Data Pages
- Integrations
- Declarative Rules
- Case lifecycle processing
Step 11 – Persistence
If the request changes persistent Case or application data, Pega performs the necessary persistence operations.
The database is therefore not simply a reporting repository. It is a core part of the runtime architecture.
Step 12 – Background Work
If the architecture intentionally separates work from the interactive request, additional processing can be placed onto background processing mechanisms.
Examples include:
- Queue Processor work
- Scheduled processing
- Asynchronous integrations
- Notifications
- Long-running background operations
Step 13 – Response
Once the interactive portion finishes, Pega returns a response to the client.
The UI then reflects the resulting Case state, validation messages, navigation, assignment, or other outcome.
4. What Happens Between the Browser and the Pega Application?
There is normally an infrastructure layer between the browser and the Pega application.
↓
DNS / Network
↓
Firewall / Security Layer
↓
Load Balancer / Ingress
↓
Pega Web Tier
↓
Pega Runtime
Why is this important?
Because when an application is slow, the problem is not necessarily inside the Pega rules.
The latency could come from:
- Network latency
- Load balancer configuration
- SSL/TLS processing
- Web node resource constraints
- Pega rule execution
- Database latency
- External API latency
- Search service latency
Never assume "Pega is slow" means the Pega application layer is the root cause. First identify which layer is actually consuming the time.
5. What Is a Pega Web Node?
A Pega node is a runtime instance of Pega Platform. A Web Node is a node assigned to process interactive, user-initiated requests.
For Nexus, a web node may process requests such as:
- Open Case
- Load a screen
- Submit a Flow Action
- Save Case information
- Execute synchronous business logic
- Call a synchronous REST integration
- Return UI data
A production environment normally has multiple nodes rather than a single Pega server.
Example
├── Pega Web Node 1
├── Pega Web Node 2
├── Pega Web Node 3
└── Pega Web Node 4
The nodes operate as part of the Pega deployment and use shared persistence and application resources.
6. Why Do You Need Multiple Web Nodes?
Multiple web nodes provide both scalability and resilience.
Scalability
If one node can comfortably handle 500 concurrent users and the business requires substantially more capacity, additional nodes can distribute interactive workload.
High Availability
Suppose Nexus has four web nodes:
Web Node 2 — Healthy
Web Node 3 — Failed
Web Node 4 — Healthy
The load balancer can stop sending new traffic to the unhealthy node and route traffic to available nodes, depending on the health-check and infrastructure configuration.
Capacity Planning
More nodes are not automatically the answer to every performance problem.
If all nodes are slow because the database is saturated, adding more web nodes can increase database pressure rather than solve the problem.
I scale horizontally when the workload is constrained by web-tier capacity. Before adding nodes, I identify the bottleneck because scaling the wrong tier can simply move or amplify the bottleneck.
7. What Does a Load Balancer Do?
The load balancer is the controlled entry point for application traffic.
Its primary responsibility is to distribute incoming requests across available Pega web nodes.
↓
Load Balancer
├── Node 1
├── Node 2
├── Node 3
└── Node 4
Typical responsibilities
- Traffic distribution
- Health checks
- Routing away from unavailable nodes
- TLS termination or pass-through depending on architecture
- Single application endpoint
- Supporting horizontal scaling
In cloud-native environments, an ingress controller or equivalent platform component may perform some of these responsibilities.
Important distinction
The load balancer does not determine which Pega Rule should execute.
It only determines where the request is sent.
Pega Runtime: What should the application do with the request?
8. How Does Pega Handle Multiple Web Nodes?
Multiple Pega nodes work together as part of the deployment. They share access to common application Rules and persistent data.
Conceptually:
Node 2 ─┤
Node 3 ─┼── Shared Pega Database
Node 4 ─┘
This shared architecture is important because a request should not depend on a particular node having a completely separate copy of the application's persistent state.
Example
John opens a CustomerOnboarding Case through Node 1. Later, another request may reach Node 2.
The architecture must therefore support the application session and persistent Case state across the cluster.
This is why distributed Pega deployments require careful consideration of:
- Session management
- Shared database
- Cluster communication
- Cache behavior
- Node health
- Background workload distribution
- Externalized services where applicable
9. What Role Does the Database Play?
The Pega database is a core part of the runtime architecture.
It is used for persistent application information including Rules, configuration, Case/work data, and other application data.
Think about the database in three runtime categories
1. Rules
Pega Rules are persisted so that the runtime can resolve and execute the appropriate application behavior.
2. Case / Work Data
When John's CustomerOnboarding Case is saved, the Case state and associated persistent data must be stored.
3. Application / Configuration Data
Various Pega configuration and platform data are persisted as part of the application runtime.
Database performance matters
Consider a Customer 360 screen that executes six expensive queries every time it opens.
The web node may appear slow, but the actual bottleneck may be database CPU, I/O, locking, connection pressure, or inefficient queries.
10. What Role Does the Search Engine Play?
Search infrastructure provides indexed search capabilities rather than replacing the transactional database.
For Nexus, imagine an operations user searching:
- CustomerOnboarding Cases
- Loan Applications
- Fraud Reviews
- Customer identifiers
- Case attributes
Search infrastructure can provide an efficient indexed way to locate information that would otherwise require expensive transactional queries.
Database vs Search
| Database | Search |
|---|---|
| System of persistent transactional data | Indexed search capability |
| Transactional consistency | Search-oriented indexing |
| Source for persisted application state | Optimized for locating indexed information |
Therefore, if newly created Cases are not appearing in search, the investigation should include indexing and search health rather than immediately assuming that the Case was not saved.
11. What Role Does Background Processing Play?
Background processing allows Pega to execute work without forcing the interactive user request to perform every operation synchronously.
This is critical for enterprise applications such as Nexus.
Example
John submits a CustomerOnboarding Case. The business requires:
- Save the Case immediately
- Send a notification
- Run additional verification
- Perform a long-running external operation
- Update downstream systems
Some of these operations may be appropriate for asynchronous processing.
Queue Processor
Queue Processors are used for asynchronous background processing. A queue item can be placed for processing and handled outside the immediate user interaction.
Conceptually:
↓
Save Case
↓
Add Background Work
↓
Return Response
Later...
↓
Queue Processor
↓
External API / Business Processing
↓
Update Case
Why is this important?
Imagine 10,000 onboarding requests arriving during a business peak. If every request performs multiple slow external calls synchronously, the web tier can become saturated.
Asynchronous architecture allows interactive capacity and background capacity to be managed independently where appropriate.
12. What Happens Synchronously?
Synchronous processing means the current request waits for the operation to complete before the response can continue.
Example
John's Submit action requires immediate validation:
↓
Submit
↓
Pega Web Node
↓
Validate customer information
↓
Execute business rule
↓
Save Case
↓
Return response
↓
Browser
The user expects the result immediately.
Examples of operations that may be synchronous
- Field validation
- Required-field validation
- Simple business rules
- Immediate Case state changes
- Short-lived data retrieval
- Short, reliable integrations when the business requires immediate results
The danger of excessive synchronous processing
Suppose Nexus calls:
AML → 4 seconds
Credit Bureau → 5 seconds
Core Banking → 3 seconds
Document Management → 4 seconds
If these calls are performed sequentially inside the user's request, the user could wait for a very long time.
At enterprise scale, that can also consume web-node capacity and increase connection pressure on downstream systems.
13. What Happens Asynchronously?
Asynchronous processing separates the user's immediate interaction from work that can complete later.
Example: AML Screening
Suppose the business does not require John to wait for the entire AML screening process before the Case can be submitted.
↓
Pega saves Case
↓
Queue AML Screening
↓
Return "Submitted"
Background processing
↓
AML API
↓
Process result
↓
Update Case
↓
Route Case accordingly
Asynchronous design requires more than a Queue Processor
A Principal Architect should ask:
- What happens if the external system is unavailable?
- How many retries are allowed?
- What is the retry delay?
- How is duplicate processing prevented?
- What happens after maximum retries?
- How is the failure visible to operations?
- Can the Case continue?
- Does the user need notification?
- How is reconciliation performed?
A robust asynchronous design is therefore an operational design as much as it is a technical design.
14. How Does the Runtime Locate a Rule?
This is where runtime architecture connects directly with inheritance architecture and Ruleset architecture.
Suppose Nexus needs a Decision Table named:
The runtime cannot simply say:
The rule resolution process considers the runtime context.
Important inputs include
- Rule type
- Rule name
- Apply To class
- Ruleset availability
- Ruleset precedence
- Class hierarchy
- Rule availability
- Specialization/circumstance where applicable
- Other rule-resolution criteria applicable to that rule type
Example
Suppose:
└── Alpha-Banking-Work-CustomerOnboarding
There might be a generic rule at:
and a specialized rule at:
The runtime evaluates the applicable candidates using Pega's rule-resolution mechanism rather than relying on a simplistic "last rule created wins" model.
"At runtime, Pega uses the current application context and Ruleset Stack, then performs rule resolution using the requested rule and its Apply To class, class inheritance, Ruleset precedence, availability, and other applicable specialization criteria."
15. How Does the Runtime Locate Case Behavior?
A Case Type is not one single Rule.
A Case Type is implemented using multiple rule types and runtime components.
For:
runtime behavior may involve:
- Case Type configuration
- Stages
- Processes
- Flow rules
- Flow Actions
- Views
- Data Objects
- Data Pages
- Validation rules
- Decision rules
- Service-level rules
- Assignment/routing rules
- Security configuration
- Integration rules
Runtime example
John submits CustomerOnboarding.
Pega determines the current Case state and executes the rules necessary to move the Case through its lifecycle.
For example:
↓
Capture Customer Information
↓
Validate Data
↓
KYC Verification
↓
AML Screening
↓
Credit / Risk Decision
↓
Banking Officer Review
↓
Customer Creation
The runtime evaluates the Case's current state and determines what behavior is available and what should happen next.
Case behavior is distributed across multiple rule types
This is why a Principal Architect should not describe a Case Type simply as "a Flow."
A Case Type is a runtime composition of process, data, business rules, integrations, security, assignments, and persistence.
16. How Does Access Group Affect Runtime Execution?
The Access Group is one of the most important runtime security and application-context objects in Pega.
Think of the runtime relationship as:
↓
Access Group
↓
Application + Version
↓
Ruleset Stack
↓
Runtime Rule Resolution
Alpha Bank example
Suppose Mary is a Credit Manager.
Her Operator ID is associated with an Access Group such as:
That Access Group can identify the application/version context and the security configuration relevant to Mary's session.
Another user, Bob, may have:
Bob and Mary may therefore execute the same Nexus application while having different authorization contexts.
Access Group influences more than the visible menu
It participates in establishing the runtime application context and available Rulesets. Security authorization is then enforced through the relevant roles, privileges, access controls, and other security mechanisms.
17. How Does the Application Version Affect Runtime Execution?
Application versioning allows Pega to distinguish one application configuration from another and supports controlled release cycles.
For example:
Nexus:01.02
Nexus:02.01
The exact versioning strategy depends on how the organization manages application releases.
Why does this matter at runtime?
The Access Group references an application and version. That application configuration determines the Ruleset Stack used by the runtime session.
Therefore, two users can potentially have different runtime behavior if their Access Groups point to different application versions or otherwise establish different runtime configurations.
Production example
Suppose development has:
while production is still running:
A developer may see the new behavior in one environment while production users continue to execute the older application configuration.
This is one reason why "the rule exists in the database" does not necessarily mean "the production user will execute that rule."
18. How Does the Ruleset Stack Affect Runtime Execution?
This is one of the most important runtime concepts in Pega.
The Ruleset List / Ruleset Stack determines which Rulesets are available to a particular application/session and the precedence used during rule resolution.
Pega Academy explicitly describes the Ruleset list as governing Rule execution at runtime, and the order of the Rulesets matters because the rule-resolution process uses that order. :contentReference[oaicite:0]{index=0}
Conceptual Nexus stack
─────────────────────────
Nexus Implementation Rulesets
Alpha Banking Framework Rulesets
Alpha Enterprise Rulesets
Pega Platform Rulesets
─────────────────────────
Lower precedence
The names above are illustrative. The actual stack depends on the application's configuration.
Why does order matter?
Suppose the same type of Rule exists in multiple available Rulesets.
The Ruleset Stack participates in determining which candidate is selected during rule resolution.
This gives application teams the ability to specialize application behavior while retaining reusable lower-level framework behavior.
How is the Ruleset Stack assembled?
Pega Academy explains that the process begins with the versioned Application Rule referenced by the Access Group. The application definition references Rulesets, and built-on applications contribute to the resulting Ruleset list. :contentReference[oaicite:1]{index=1}
Conceptually:
↓
Access Group
↓
Application Version
↓
Application Rulesets
↓
Built-on Applications
↓
Ruleset Stack
↓
Rule Resolution
Ruleset versioning
Application versioning and Ruleset versioning are closely connected. Pega documentation explains that application versioning preserves prior application configurations and that Ruleset versions participate in determining which Rules are used during rule resolution. :contentReference[oaicite:2]{index=2}
For example, imagine:
AlphaBank-Nexus:01-01-02
A newer version can contain a modified Rule that supersedes an older version when the relevant application/ruleset configuration makes that version available.
This is why deployment is not simply "copy some files to production." The application version, Ruleset versions, Access Groups, and deployment configuration all have to line up.
Putting Everything Together – The Complete Nexus Runtime Flow
Now let's connect all 18 concepts into one runtime picture.
John / API Client
│
▼
Browser / API Consumer
│
▼
Network / HTTPS
│
▼
Load Balancer / Ingress
│
▼
┌──────────────────────────────────────┐
│ Pega Web Tier │
│ │
│ Web Node 1 Web Node 2 Web Node 3│
└──────────────────────────────────────┘
│
▼
Authentication / Session
│
▼
Operator
│
▼
Access Group
│
▼
Application + Version
│
▼
Ruleset Stack
│
▼
Class Hierarchy
│
▼
Rule Resolution
│
▼
Case / Data / Business Logic
│
├───────────────┐
│ │
▼ ▼
Data Pages Integrations
│ │
▼ ▼
Database KYC / AML / Core
│
├───────────────┐
│ │
▼ ▼
Search Background Processing
│
▼
Queue Processors
│
▼
Async Work
│
▼
Persistence / Case State
│
▼
Response
│
▼
Browser / API Client
Runtime Architecture vs Design-Time Architecture
A common interview mistake is mixing design-time concepts with runtime concepts.
| Design-Time Concept | Runtime Question |
|---|---|
| Application Rule | Which application/version is the session running? |
| Ruleset | Is this Ruleset available and what precedence does it have? |
| Class | Where does runtime search for the applicable Rule? |
| Case Type | What behavior should the current Case execute? |
| Data Page | Where should runtime data come from and how should it be reused? |
| Integration Rule | How should runtime communicate with an external system? |
Runtime Troubleshooting – Where Do You Start?
Suppose Alpha Bank reports:
A Principal Engineer should not immediately open an Activity and start debugging.
Start by identifying the layer.
| Symptom | Possible Layer |
|---|---|
| All pages slow | Web tier, database, infrastructure, external dependency |
| One node slow | Specific node/resource/configuration issue |
| One screen slow | Rule, query, Data Page, integration, UI processing |
| Search slow | Search/indexing layer |
| Cases stuck | Assignment, SLA, integration, background processing, locking, errors |
| Old Rule executes | Ruleset Stack, Application Version, class hierarchy, rule availability/resolution |
| API requests slow | External integration, network, authentication, connector configuration |
Pega Tools Used During Runtime Troubleshooting
The exact tools available and UI locations can vary by Pega Platform version, but a production troubleshooting strategy commonly includes:
- Tracer – trace rule execution and runtime events
- PAL – analyze performance statistics
- Performance Profiler – investigate expensive processing
- Log analysis – identify exceptions and runtime failures
- Queue Processor monitoring – investigate asynchronous backlog
- System health/administration tools – inspect platform health
- Database monitoring – identify expensive SQL and database pressure
- APM tools – correlate application and infrastructure behavior
Example troubleshooting approach
Suppose the CustomerOnboarding Submit button takes 20 seconds.
- Confirm whether the problem affects all users or a subset.
- Check whether the problem occurs on one node or all nodes.
- Check application and platform health.
- Measure request duration.
- Use tracing/profiling where appropriate.
- Identify expensive Rules.
- Check Data Page activity.
- Check database calls.
- Check synchronous integrations.
- Check external API latency.
- Check background processing if the request depends on it.
- Correlate the timeline with recent deployments or configuration changes.
The Rule-Level Runtime Mental Model
For interviews, this is the mental model I recommend using.
1. Who is calling?
↓
2. How was the user authenticated?
↓
3. Which Operator?
↓
4. Which Access Group?
↓
5. Which Application + Version?
↓
6. Which Ruleset Stack?
↓
7. Which Case / Data class?
↓
8. Which Rule is being requested?
↓
9. What does Rule Resolution select?
↓
10. What business logic executes?
↓
11. What data does it need?
↓
12. Does it call an external system?
↓
13. Is the work synchronous or asynchronous?
↓
14. What gets persisted?
↓
15. What happens in the background?
↓
16. What response is returned?
↓
17. How do we monitor and troubleshoot it?
Four Concepts You Must Never Mix Up
These four concepts are frequently confused during Pega interviews.
1. Application Hierarchy
Determines how applications are composed and built on other applications.
2. Class Hierarchy
Determines pattern inheritance and where Rules can be inherited from.
3. Ruleset Stack
Determines which Rulesets are available to the runtime session and their precedence.
4. Rule Resolution
Determines which specific Rule candidate should execute based on the runtime context.
Application hierarchy = What applications are composed together?
Class hierarchy = Where can the Rule be inherited from?
Ruleset Stack = Which Rule definitions are available and what is their precedence?
Rule Resolution = Which specific Rule should execute?
How I Would Answer This in a Principal Applications Engineer Interview
If the interviewer asks:
A strong practical answer would be:
"I look at Pega runtime as several layers working together.
The user request first reaches the load balancer, which routes it to an
available Pega web node. Pega establishes the user and session context,
and the user's Access Group determines the application and version context.
From that application, Pega establishes the Ruleset Stack.
Once the request is mapped to a Case or business operation, Pega performs
rule resolution using the requested Rule, Apply To class, class hierarchy,
Ruleset precedence, availability, and other applicable resolution criteria.
The selected Rules execute the business logic, which may involve Case data,
Data Pages, validations, decisions, integrations, and persistence.
I then separate synchronous work from asynchronous work. Anything required
for the immediate user response remains synchronous where practical, while
long-running or independently retryable workloads can be moved to
background processing such as Queue Processors.
The Case and application state are persisted in the database, search
infrastructure supports indexed search, and background processing handles
asynchronous workloads. In production, I also consider multiple web nodes,
load balancing, database capacity, search health, monitoring, and failure
recovery.
So when troubleshooting a runtime problem, I don't start with a Rule blindly.
I first identify which layer is actually responsible: network, load balancer,
web node, Pega rule execution, database, search, integration, or background
processing."
Alpha Bank Nexus – Complete Runtime Example
Let's put everything together with one realistic scenario.
Mary, an Alpha Bank Credit Manager, opens a Loan Application and clicks Approve.
Runtime sequence
- Mary's browser sends the request.
- The request reaches the load balancer.
- The load balancer routes the request to an available Pega web node.
- Pega identifies Mary's authenticated Operator context.
- Mary's Access Group establishes the relevant Nexus application context.
- The Application Version determines the application configuration.
- The Ruleset Stack determines available Rulesets and precedence.
- The runtime identifies the LoanApplication Case and its current state.
- Pega evaluates the Approve Flow Action and associated security.
- Rule resolution identifies the applicable Flow Action and supporting rules.
- Validation and business rules execute.
- The Credit Decision may be evaluated.
- Required Data Pages may retrieve information.
- A synchronous Core Banking call may occur if the business requires an immediate response.
- Other independent work may be placed into background processing.
- The Case state is persisted.
- The appropriate next assignment or stage is established.
- The response is returned to Mary's browser.
What looks like one button click is therefore a complete runtime execution path.
Common Runtime Architecture Mistakes
-
Assuming one Pega server handles everything.
Enterprise Pega deployments are normally distributed. -
Putting every operation in the web request.
Long-running work should be evaluated for asynchronous processing. -
Adding web nodes without identifying the bottleneck.
A database or external API bottleneck will not necessarily improve. -
Confusing the Ruleset Stack with class inheritance.
They are different runtime concepts. -
Assuming the newest Rule automatically executes.
Rule resolution considers runtime context and multiple criteria. -
Using UI visibility as security.
Hiding an Approve button does not replace server-side authorization. -
Calling every integration synchronously.
External dependency latency can directly affect interactive capacity. -
Ignoring background processing.
Queue backlog can cause SLAs and downstream Case processing to fall behind. -
Assuming search and database are the same thing.
Search is an indexed search capability; the transactional database remains a core persistence component. -
Troubleshooting only the Pega Rule.
Production incidents often cross multiple infrastructure and application layers.
Principal-Level Follow-Up Questions
Once you explain runtime architecture, an interviewer may go deeper:
- What happens if one web node goes down?
- How do you determine whether a performance issue is Pega or the database?
- How do you troubleshoot a Rule that exists but is not executing?
- How does the Access Group influence the Ruleset Stack?
- What happens if production has the wrong Application Version?
- When would you use synchronous versus asynchronous processing?
- How do you handle a Queue Processor backlog?
- What happens if an external API is slow?
- How do you prevent a retry storm?
- How do you troubleshoot one slow node versus all nodes?
- What happens if a Case is saved but does not appear in search?
- How do class hierarchy and Ruleset precedence work together?
- How would you design runtime architecture for one million Cases per day?
- How would you isolate background workloads from interactive workloads?
- How do you design for high availability?
Runtime Architecture Checklist
☐ Load Balancer / Ingress is defined
☐ Multiple Web Nodes are available where required
☐ Web and background workloads are appropriately separated
☐ Application and Application Version are controlled
☐ Access Groups are correctly configured
☐ Ruleset Stack is understood
☐ Class hierarchy is understood
☐ Rule resolution is understood
☐ Database capacity is planned
☐ Search architecture is planned
☐ Synchronous operations are minimized to what the business requires
☐ Asynchronous processing has retry and failure handling
☐ Queue Processor capacity is monitored
☐ Integrations have timeout and error handling
☐ Production monitoring is implemented
☐ Logging and auditing are available
☐ High availability is designed
☐ Disaster recovery is defined
☐ Performance troubleshooting procedures are documented
The Big Picture
Pega runtime architecture is the point where all the architectural decisions we made throughout the Nexus series finally come together.
The application hierarchy defines how the application is composed. The Case architecture defines business processes. The Data architecture defines business information. The Integration architecture connects external systems. The Inheritance architecture provides reuse. The Security architecture controls access.
Runtime architecture is where all of those decisions are executed.
A strong Pega architect therefore thinks beyond individual Rules. The question is not only: "How do I configure this Rule?"
The bigger question is:
That is the difference between designing a Pega application and designing a production-ready enterprise Pega platform.
No comments:
Post a Comment