Data Architecture is one of the most important areas for a Senior Pega Developer, Lead System Architect, and Principal Architect interview.
At a basic level, developers often think about data as properties on a Case. A senior architect thinks much further:
- Who owns the data?
- Where is the System of Record?
- Should Pega store the data or retrieve it?
- How should Pega access the data?
- Should the data be live or a Case snapshot?
- How should the data be cached?
- How should the Data Page be scoped?
- How do we prevent unnecessary database or API calls?
- How do we secure sensitive information?
- How do we handle high-volume and high-cardinality data?
This article explains all of these concepts using a fictional banking application, Alpha Bank, so you can use the examples directly during a Pega interview.
1. How would you design data architecture for a large Pega banking application?
Interview Answer:
I would start by identifying the major business entities and their Systems of Record. For Alpha Bank, these could be Customer, Account, Loan, Card, KYC and Transaction. I would model them as reusable Data Objects and expose them through Data Pages. The Case Types would consume these Data Objects instead of directly calling databases or external APIs.
I would start by identifying the major business entities and their Systems of Record. For Alpha Bank, these could be Customer, Account, Loan, Card, KYC and Transaction. I would model them as reusable Data Objects and expose them through Data Pages. The Case Types would consume these Data Objects instead of directly calling databases or external APIs.
My architecture would look like this:
Case Type
→
Data Object
→
Data Page
→
Integration
→
System of Record
For example:
- Customer → Customer Master / CRM
- Account → Core Banking System
- Loan → Loan Servicing System
- Card → Card Management System
- KYC → KYC Provider
- Transaction → Transaction/Banking System
The important architectural principle is:
The Case owns the workflow. The Data Object represents the business entity.
The Data Page manages access to that entity. The System of Record owns the
authoritative data.
2. What is a Data Type/Data Object in Pega?
Interview Answer:
A Data Object represents a reusable business entity and defines the data associated with that entity. Examples are Customer, Account, Loan and Card. Depending on the Pega version and terminology, you may hear Data Object or Data Type.
A Data Object represents a reusable business entity and defines the data associated with that entity. Examples are Customer, Account, Loan and Card. Depending on the Pega version and terminology, you may hear Data Object or Data Type.
For example, Alpha Bank's Customer Data Object could contain:
CustomerID FirstName LastName DateOfBirth Email Phone Address CustomerStatus
The important point is that the Customer entity can be reused by multiple Case Types.
3. What is the difference between a Data Object and a Case Type?
| Data Object | Case Type |
|---|---|
| Represents business data | Represents business work |
| Customer, Account, Loan | Customer Onboarding, Loan Application |
| Reusable entity | Workflow transaction |
| Usually accessed through Data Pages | Consumes data during case processing |
Simple interview explanation:
Customer is data. CustomerOnboarding is the work performed using that data.
Customer is data. CustomerOnboarding is the work performed using that data.
4. How do you identify Data Objects?
Interview Answer:
I identify reusable business entities from the requirements. I look for entities that have their own identity, business meaning, lifecycle, ownership or System of Record and that may be reused by multiple processes.
I identify reusable business entities from the requirements. I look for entities that have their own identity, business meaning, lifecycle, ownership or System of Record and that may be reused by multiple processes.
For example:
Customer applies for a Loan using an Account and Card.
Likely Data Objects:
- Customer
- Loan
- Account
- Card
The actual application workflow could be a Case Type: LoanApplication.
5. What Data Objects would you create for Alpha Bank?
| Data Object | Purpose |
|---|---|
| Customer | Customer master information |
| Account | Bank account information |
| Loan | Loan information |
| Card | Debit/credit card information |
| KYC | Identity verification information |
| Transaction | Financial transaction information |
| Address | Reusable address information |
| Branch | Branch information |
6. How would you model Customer?
Interview Answer:
I would model Customer as a reusable enterprise Data Object rather than copying customer information into every Case Type.
I would model Customer as a reusable enterprise Data Object rather than copying customer information into every Case Type.
Customer ├── CustomerID ├── FirstName ├── LastName ├── DateOfBirth ├── Email ├── Phone ├── Address └── CustomerStatus
The Customer Data Object can be populated from the Customer System of Record through a Data Page.
7. How would you model Account?
Interview Answer:
Account would be modeled as a separate reusable Data Object. If the core banking system owns Account, that system remains the System of Record and Pega retrieves the information through a Data Page.
Account would be modeled as a separate reusable Data Object. If the core banking system owns Account, that system remains the System of Record and Pega retrieves the information through a Data Page.
Account ├── AccountNumber ├── AccountType ├── AccountStatus ├── Currency ├── AvailableBalance ├── CurrentBalance └── OpenDate
I would be especially careful with values such as balances because they may need to be retrieved live rather than stored permanently in the Case.
8. How would you model Loan?
Interview Answer:
Loan is a reusable Data Object containing the business information associated with a loan. LoanApplication is the workflow that processes the loan request.
Loan is a reusable Data Object containing the business information associated with a loan. LoanApplication is the workflow that processes the loan request.
Loan ├── LoanID ├── CustomerID ├── LoanType ├── RequestedAmount ├── ApprovedAmount ├── InterestRate ├── Term └── LoanStatus
9. How would you model Card?
Interview Answer:
Card would be modeled as a reusable Data Object. I would avoid storing unnecessary sensitive card information inside the Case and would normally use masked values when the business only needs display information.
Card would be modeled as a reusable Data Object. I would avoid storing unnecessary sensitive card information inside the Case and would normally use masked values when the business only needs display information.
Card ├── CardID ├── CustomerID ├── AccountID ├── CardType ├── Status ├── ExpirationDate └── MaskedCardNumber
10. How would you model KYC?
Interview Answer:
I would model KYC as a reusable Data Object containing the identity verification information and verification result. The authoritative identity information would remain in the appropriate enterprise system, while Pega orchestrates the KYC process.
I would model KYC as a reusable Data Object containing the identity verification information and verification result. The authoritative identity information would remain in the appropriate enterprise system, while Pega orchestrates the KYC process.
KYC ├── CustomerID ├── VerificationID ├── VerificationStatus ├── VerificationDate ├── VerificationProvider ├── RiskLevel └── FailureReason
11. How would you model Transaction?
Interview Answer:
Transaction is typically a high-volume entity. I would not retrieve an unbounded transaction history into a Case. I would use a parameterized Data Page with filtering and pagination so only the required transactions are retrieved.
Transaction is typically a high-volume entity. I would not retrieve an unbounded transaction history into a Case. I would use a parameterized Data Page with filtering and pagination so only the required transactions are retrieved.
Transaction ├── TransactionID ├── AccountID ├── TransactionDate ├── Amount ├── Currency ├── TransactionType └── Status
Architectural warning:
A List Data Page returning thousands or millions of transactions can create serious memory and performance problems.
A List Data Page returning thousands or millions of transactions can create serious memory and performance problems.
12. How do you decide which system owns the data?
Interview Answer:
I identify the system that owns the business entity's authoritative lifecycle and data. That system becomes the System of Record. Pega then integrates with that system instead of creating another competing master copy.
I identify the system that owns the business entity's authoritative lifecycle and data. That system becomes the System of Record. Pega then integrates with that system instead of creating another competing master copy.
| Entity | Example SOR |
|---|---|
| Customer | Customer Master / CRM |
| Account | Core Banking |
| Loan | Loan Servicing |
| Card | Card Management |
| KYC | KYC Provider |
13. What is a System of Record?
Interview Answer:
A System of Record is the authoritative system responsible for maintaining the official version of a particular business entity.
A System of Record is the authoritative system responsible for maintaining the official version of a particular business entity.
For example, if Alpha Bank's Core Banking System owns Account information:
Pega → D_Account → Account API → Core Banking SOR
14. Should Pega become the System of Record?
Interview Answer:
Not automatically. Pega can be the System of Record when the enterprise architecture intentionally assigns ownership of the data to Pega. If another enterprise platform already owns the data, I would normally integrate with that system rather than create another authoritative copy in Pega.
Not automatically. Pega can be the System of Record when the enterprise architecture intentionally assigns ownership of the data to Pega. If another enterprise platform already owns the data, I would normally integrate with that system rather than create another authoritative copy in Pega.
15. When should Pega store data?
Interview Answer:
Pega should store data when Pega owns the data, when the Case needs workflow state, when a historical snapshot is required, or when the enterprise architecture explicitly defines Pega as the System of Record.
Pega should store data when Pega owns the data, when the Case needs workflow state, when a historical snapshot is required, or when the enterprise architecture explicitly defines Pega as the System of Record.
Examples include:
- Case status
- Approval decision
- Workflow timestamps
- Case-specific comments
- Business decisions
- Audit information
- Required historical snapshots
16. When should Pega retrieve data from an external system?
Interview Answer:
When another system owns the authoritative data, I would retrieve it through a Data Object and Data Page rather than copying the entire entity into the Case.
When another system owns the authoritative data, I would retrieve it through a Data Object and Data Page rather than copying the entire entity into the Case.
CustomerOnboarding
|
v
D_Customer[CustomerID]
|
v
Customer API
|
v
Customer Master
17. How do you avoid duplicating customer data across Cases?
Interview Answer:
I keep Customer as a reusable Data Object and retrieve it through a parameterized Data Page. The Case stores the CustomerID and only takes a snapshot of selected fields when the business requires historical data.
I keep Customer as a reusable Data Object and retrieve it through a parameterized Data Page. The Case stores the CustomerID and only takes a snapshot of selected fields when the business requires historical data.
Instead of:
Case A → Full Customer Case B → Full Customer Case C → Full Customer Case D → Full Customer
I would use:
Customer SOR
|
v
D_Customer[CustomerID]
|
+---- Case A
+---- Case B
+---- Case C
+---- Case D
18. What is a Data Page?
Interview Answer:
A Data Page is Pega's reusable data access layer. It retrieves data from a configured source and exposes that data in a standard Pega structure. Depending on its configuration, it can also cache the data and support saving changes back to the source.
A Data Page is Pega's reusable data access layer. It retrieves data from a configured source and exposes that data in a standard Pega structure. Depending on its configuration, it can also cache the data and support saving changes back to the source.
Case → Data Page → Data Source
The Case does not need to know whether the source is REST, SOAP, database, Pega data or another supported system.
19. Why would you use a Data Page?
Interview Answer:
I use Data Pages to centralize data retrieval, caching, source integration, mapping and reuse. This prevents multiple Case Types from implementing the same integration logic independently.
I use Data Pages to centralize data retrieval, caching, source integration, mapping and reuse. This prevents multiple Case Types from implementing the same integration logic independently.
20. What problem does a Data Page solve?
Interview Answer:
A Data Page solves the coupling problem between the business process and the physical data source. The Case works with a logical business entity while the Data Page manages how that entity is retrieved or saved.
A Data Page solves the coupling problem between the business process and the physical data source. The Case works with a logical business entity while the Data Page manages how that entity is retrieved or saved.
Strong interview phrase:
"The Data Page acts as an abstraction boundary between the business process and the physical data source."
"The Data Page acts as an abstraction boundary between the business process and the physical data source."
21. What are the four major configuration areas of a Data Page?
Interview Answer:
I think about a Data Page in four major areas: its definition, its source, its mapping/transformation, and its loading/saving behavior.
I think about a Data Page in four major areas: its definition, its source, its mapping/transformation, and its loading/saving behavior.
| Area | Purpose |
|---|---|
| Definition | Structure, object type, scope and parameters |
| Data Source | Where the data comes from |
| Transformation | Maps source data into Pega's logical model |
| Load/Save Behavior | Caching, refresh and persistence behavior |
22. What are the different Data Page structures?
Interview Answer:
The important distinction is whether the Data Page represents one business object or a collection of objects. In Pega discussions you will commonly hear Page, List and Object Data Page terminology depending on the Pega version and UI being used.
The important distinction is whether the Data Page represents one business object or a collection of objects. In Pega discussions you will commonly hear Page, List and Object Data Page terminology depending on the Pega version and UI being used.
23. What is a Page Data Page?
Interview Answer:
A Page Data Page represents one structured page of information rather than a collection of records.
A Page Data Page represents one structured page of information rather than a collection of records.
D_Customer[CustomerID=C10001]
The result represents one Customer.
24. What is a List Data Page?
Interview Answer:
A List Data Page represents a collection of records.
A List Data Page represents a collection of records.
D_CustomerAccounts[CustomerID=C10001]
↓
Account 1001
Account 1002
Account 1003
Account 1004
Important:
Never design a large List Data Page assuming it will always return a small number of records. Filter and paginate large datasets at the source.
Never design a large List Data Page assuming it will always return a small number of records. Filter and paginate large datasets at the source.
25. What is an Object Data Page?
Interview Answer:
An Object Data Page represents a single instance of a business object such as one Customer, one Account or one Loan. The exact terminology can vary between Pega versions, so I focus on the runtime behavior rather than only the label.
An Object Data Page represents a single instance of a business object such as one Customer, one Account or one Loan. The exact terminology can vary between Pega versions, so I focus on the runtime behavior rather than only the label.
D_Account[AccountID=123456]
26. What are the different Data Page scopes?
Interview Answer:
The major Data Page scopes are Thread, Requestor and Node. Scope determines where the Data Page instance can be reused and has an important impact on performance, memory and data freshness.
The major Data Page scopes are Thread, Requestor and Node. Scope determines where the Data Page instance can be reused and has an important impact on performance, memory and data freshness.
| Scope | General Meaning |
|---|---|
| Thread | Current thread/interaction |
| Requestor | Requestor/session context |
| Node | Application server node |
27. What is Thread scope?
Interview Answer:
Thread scope makes the Data Page available within the current thread. I use it when the data is specific to the current interaction and should not be broadly shared.
Thread scope makes the Data Page available within the current thread. I use it when the data is specific to the current interaction and should not be broadly shared.
For example:
D_LoanEligibility Scope = Thread
28. What is Requestor scope?
Interview Answer:
Requestor scope allows reuse of the Data Page within the requestor/session context. It can be useful when multiple interactions for the same user can reuse the same information.
Requestor scope allows reuse of the Data Page within the requestor/session context. It can be useful when multiple interactions for the same user can reuse the same information.
Example:
D_UserPreferences Scope = Requestor
29. What is Node scope?
Interview Answer:
Node scope allows the Data Page to be shared at the application server node level. It can be useful for broadly reusable data that does not require request-specific isolation.
Node scope allows the Data Page to be shared at the application server node level. It can be useful for broadly reusable data that does not require request-specific isolation.
Examples include relatively stable reference information such as:
- Country codes
- Branch types
- Product categories
- Reference lists
Do not use Node scope simply because it is faster.
Consider memory, freshness, security and sharing requirements first.
30. When would you use each Data Page scope?
| Requirement | Scope | Example |
|---|---|---|
| Specific to current interaction | Thread | Loan eligibility calculation |
| Reusable within user's session | Requestor | User preferences |
| Broadly reusable reference data | Node | Country list |
31. What is a parameterized Data Page?
Interview Answer:
A parameterized Data Page accepts parameters that determine which record or subset of data it retrieves.
A parameterized Data Page accepts parameters that determine which record or subset of data it retrieves.
D_Customer[CustomerID]
At runtime:
CustomerID = C10001
32. Why would you parameterize a Data Page?
Interview Answer:
Parameterization allows one reusable Data Page definition to retrieve many different records instead of creating a separate Data Page for each record.
Parameterization allows one reusable Data Page definition to retrieve many different records instead of creating a separate Data Page for each record.
Bad design:
D_Customer10001 D_Customer10002 D_Customer10003
Better design:
D_Customer[CustomerID]
33. How would you design D_Customer[CustomerID]?
Interview Answer:
I would create a single-record Customer Data Page with CustomerID as the parameter. The Data Page retrieves the customer from the Customer System of Record and maps the response into the Customer Data Object.
I would create a single-record Customer Data Page with CustomerID as the parameter. The Data Page retrieves the customer from the Customer System of Record and maps the response into the Customer Data Object.
Data Page: D_Customer Structure: Page / Object Parameter: CustomerID Object: AlphaBank-Data-Customer Source: Customer REST API Mapping: API response → Customer Data Object
CustomerOnboarding
↓
D_Customer[CustomerID]
↓
Customer API
↓
Customer Master
↓
D_Customer[CustomerID]
↓
Customer API
↓
Customer Master
34. How does Data Page caching work?
Interview Answer:
When a Data Page is loaded, Pega can reuse the loaded instance according to its scope, parameters and refresh configuration. This avoids unnecessary calls to the underlying source.
When a Data Page is loaded, Pega can reuse the loaded instance according to its scope, parameters and refresh configuration. This avoids unnecessary calls to the underlying source.
First request
D_Customer[C10001]
↓
Customer API
↓
Cached Data Page
Second request
D_Customer[C10001]
↓
Existing cached instance
The actual reuse behavior depends on scope, parameters and refresh settings.
35. What happens when a Data Page becomes stale?
Interview Answer:
When the Data Page reaches its configured refresh condition, Pega can reload the data from the source according to the configured refresh strategy.
When the Data Page reaches its configured refresh condition, Pega can reload the data from the source according to the configured refresh strategy.
The architecture must balance:
- Freshness
- Performance
- API/database load
- Business impact of stale information
36. How do you configure refresh strategies?
Interview Answer:
I choose the refresh strategy based on the business freshness requirement rather than choosing an arbitrary refresh interval.
I choose the refresh strategy based on the business freshness requirement rather than choosing an arbitrary refresh interval.
| Data | Example Approach |
|---|---|
| Country codes | Long refresh period |
| Customer profile | Moderate refresh |
| Account balance | Short refresh or live retrieval |
| Loan status | Business-driven refresh |
Architectural point:
Refreshing every minute is not automatically better. The correct strategy is based on the business requirement for freshness.
Refreshing every minute is not automatically better. The correct strategy is based on the business requirement for freshness.
37. What problems can occur with high-cardinality Data Pages?
Interview Answer:
A parameterized Data Page can create many cached instances when there are many unique parameter combinations. This can increase memory usage while providing very little cache reuse.
A parameterized Data Page can create many cached instances when there are many unique parameter combinations. This can increase memory usage while providing very little cache reuse.
D_Customer[C000001] D_Customer[C000002] D_Customer[C000003] ... D_Customer[C900000]
If every parameter value is unique and accessed only once, caching may not provide much benefit.
38. What happens if you have thousands of unique Data Page parameters?
Interview Answer:
I would evaluate whether the Data Page is actually benefiting from caching. Thousands of unique parameter values can create a large number of cached instances and increase memory pressure.
I would evaluate whether the Data Page is actually benefiting from caching. Thousands of unique parameter values can create a large number of cached instances and increase memory pressure.
I would investigate:
- Data Page scope
- Parameter cardinality
- Cache reuse rate
- Refresh configuration
- Result size
- Whether the data should be retrieved on demand
- Whether the source query can be filtered or paginated
Senior Architect phrase:
"I don't treat caching as free. I evaluate cache-hit potential, cardinality, memory footprint and data freshness before selecting the scope."
"I don't treat caching as free. I evaluate cache-hit potential, cardinality, memory footprint and data freshness before selecting the scope."
39. When would you use a Savable Data Page?
Interview Answer:
I use a Savable Data Page when Pega needs to modify data owned by the underlying System of Record and the Data Page has a configured save plan that knows how to persist the change.
I use a Savable Data Page when Pega needs to modify data owned by the underlying System of Record and the Data Page has a configured save plan that knows how to persist the change.
Case ↓ D_Customer ↓ Save Plan ↓ Customer API ↓ Customer Master
40. What is the difference between Read-Only, Editable, and Savable Data Pages?
| Mode | Meaning |
|---|---|
| Read-Only | Used to consume source data |
| Editable | Data Page contents can be modified in the application context |
| Savable | Configured with a mechanism to persist changes to the source |
Important interview point:
Editable does not automatically mean the external System of Record has been updated. The save behavior must be explicitly configured.
Editable does not automatically mean the external System of Record has been updated. The save behavior must be explicitly configured.
41. How does a Savable Data Page write data back to the System of Record?
Interview Answer:
The Savable Data Page uses a configured save plan to determine how modified data is persisted. Depending on the implementation, the save operation can invoke a connector, database save mechanism, activity or another supported persistence mechanism.
The Savable Data Page uses a configured save plan to determine how modified data is persisted. Depending on the implementation, the save operation can invoke a connector, database save mechanism, activity or another supported persistence mechanism.
Case
→
D_Customer
→
Save Plan
→
Customer API
→
Customer SOR
42. What is a Data Transform's role with a Data Page?
Interview Answer:
A Data Transform can be used to map and transform data between the external representation and Pega's logical Data Object representation. This keeps mapping logic separate from the Case workflow.
A Data Transform can be used to map and transform data between the external representation and Pega's logical Data Object representation. This keeps mapping logic separate from the Case workflow.
External API Response
↓
Data Transform
↓
Customer Data Object
↓
D_Customer
↓
Case
43. How do you map an external API response into a Pega Data Object?
Interview Answer:
I define the logical Data Object first, configure the external source, and then map the external response into the Data Object using the appropriate mapping or Data Transform configuration.
I define the logical Data Object first, configure the external source, and then map the external response into the Data Object using the appropriate mapping or Data Transform configuration.
External API
cust_no → CustomerID
first_name → FirstName
last_name → LastName
email_addr → Email
↓
Customer Data Object
44. How do you prevent the Case from knowing the details of the external API?
Interview Answer:
I hide integration details behind the Data Object and Data Page. The Case references business concepts such as Customer and Account instead of knowing whether the underlying implementation is REST, SOAP, database or another technology.
I hide integration details behind the Data Object and Data Page. The Case references business concepts such as Customer and Account instead of knowing whether the underlying implementation is REST, SOAP, database or another technology.
Strong interview phrase:
"The Case should know the business contract, not the physical integration contract."
"The Case should know the business contract, not the physical integration contract."
45. How would CustomerOnboarding retrieve Customer data?
Interview Answer:
CustomerOnboarding would receive or identify the CustomerID and use D_Customer[CustomerID]. The Data Page retrieves the authoritative customer information from the Customer System of Record.
CustomerOnboarding would receive or identify the CustomerID and use D_Customer[CustomerID]. The Data Page retrieves the authoritative customer information from the Customer System of Record.
CustomerOnboarding
↓
D_Customer[CustomerID]
↓
Customer API
↓
Customer Master
↓
D_Customer[CustomerID]
↓
Customer API
↓
Customer Master
46. How would CustomerOnboarding retrieve KYC data?
Interview Answer:
I would use a dedicated KYC Data Object and Data Page. The Case would not directly implement the KYC provider integration.
I would use a dedicated KYC Data Object and Data Page. The Case would not directly implement the KYC provider integration.
CustomerOnboarding
|
v
D_KYC[CustomerID]
|
v
KYC Provider
|
v
KYC Data Object
If KYC is asynchronous, the Case should wait for the result rather than keeping the user interaction open.
47. How would you design Customer → Accounts relationships?
Interview Answer:
I would keep Customer and Account as separate Data Objects and retrieve the relationship through a parameterized List Data Page.
I would keep Customer and Account as separate Data Objects and retrieve the relationship through a parameterized List Data Page.
D_CustomerAccounts[CustomerID]
Customer
|
v
List of Accounts
|
+-- Account 1001
+-- Account 1002
+-- Account 1003
48. When should you use a live Data Page versus a Case snapshot?
Interview Answer:
I use a live Data Page when the Case needs the current authoritative value. I use a Case snapshot when the business needs to preserve what was true at a specific point in time.
I use a live Data Page when the Case needs the current authoritative value. I use a Case snapshot when the business needs to preserve what was true at a specific point in time.
| Requirement | Pattern |
|---|---|
| Current account balance | Live retrieval |
| Current customer profile | Live retrieval |
| Address used during historical application | Case snapshot |
| Approved loan amount | Case-owned decision |
| Historical KYC result | Snapshot/audit record |
Architect's question:
"Does the business need today's value, or the value that existed when this Case decision was made?"
"Does the business need today's value, or the value that existed when this Case decision was made?"
49. How do you handle sensitive data in Pega?
Interview Answer:
I start with data minimization. I only store sensitive information when the business process requires it. Then I apply appropriate authorization, masking, encryption and access controls according to the enterprise security architecture.
I start with data minimization. I only store sensitive information when the business process requires it. Then I apply appropriate authorization, masking, encryption and access controls according to the enterprise security architecture.
For a banking application, I would pay particular attention to:
- Personally identifiable information
- Government identification data
- Account information
- Payment information
- KYC documents
- Authentication-related information
Important:
Do not depend only on hiding a field in the UI. Backend authorization and data protection must also be enforced.
Do not depend only on hiding a field in the UI. Backend authorization and data protection must also be enforced.
50. How do you secure specific properties?
Interview Answer:
First I determine whether the requirement is field visibility, authorization or protection of stored data. Then I apply the appropriate Pega security controls and, where necessary, encryption or masking.
First I determine whether the requirement is field visibility, authorization or protection of stored data. Then I apply the appropriate Pega security controls and, where necessary, encryption or masking.
For example:
Customer ├── Name → General access ├── Email → Controlled access ├── CustomerID → Controlled access └── GovernmentID → Highly restricted
The exact implementation depends on the Pega version and enterprise security model, but the principle remains: UI visibility is not sufficient security.
51. How do you improve Data Page performance?
Interview Answer:
I optimize the source query first and then the Data Page configuration. I use appropriate parameterization, scope, caching and refresh strategies. I return only the data required, filter at the source and avoid unnecessarily large List Data Pages.
I optimize the source query first and then the Data Page configuration. I use appropriate parameterization, scope, caching and refresh strategies. I return only the data required, filter at the source and avoid unnecessarily large List Data Pages.
Performance Checklist
- Return only required fields.
- Filter at the source.
- Use parameterized Data Pages.
- Avoid huge List Data Pages.
- Use pagination for large datasets.
- Choose scope intentionally.
- Configure refresh based on business freshness.
- Avoid unnecessary reloads.
- Review REST/API latency.
- Review database query performance.
- Monitor high-cardinality parameter usage.
- Review Data Page memory usage.
Senior Architect answer:
"I don't start by increasing the cache. I first identify whether the bottleneck is the source query, connector, payload size, transformation, refresh strategy or Data Page configuration."
"I don't start by increasing the cache. I first identify whether the bottleneck is the source query, connector, payload size, transformation, refresh strategy or Data Page configuration."
52. How do you troubleshoot a slow Data Page?
Interview Answer:
I troubleshoot the Data Page layer by layer. First I determine whether the request is using cached data or loading from the source. Then I investigate the connector, external system, payload size, transformation, refresh strategy and parameter cardinality.
I troubleshoot the Data Page layer by layer. First I determine whether the request is using cached data or loading from the source. Then I investigate the connector, external system, payload size, transformation, refresh strategy and parameter cardinality.
Step 1 – Check the Data Page
- What parameters are being passed?
- What scope is configured?
- Is this a cache hit or a new load?
- What refresh strategy is configured?
Step 2 – Check the integration
- Is the REST/SOAP call slow?
- Is the network slow?
- Is the external system slow?
- Is the response payload too large?
Step 3 – Check database performance
- Is the query properly filtered?
- Are appropriate indexes available?
- How many rows are being returned?
- Is the query doing unnecessary work?
Step 4 – Check transformation
- Is the Data Transform processing a large payload?
- Are unnecessary fields being mapped?
- Are large nested structures being copied?
Step 5 – Check caching
Determine whether the Data Page is being refreshed more frequently than necessary or whether thousands of unique parameter values are creating many cached instances.
Step 6 – Separate the timing
Total Data Page Time
=
Pega Processing
+
Connector / Network
+
External API
+
External Database
+
Response Mapping
Production troubleshooting principle:
Do not simply say "the Data Page is slow." Identify which layer is slow.
Do not simply say "the Data Page is slow." Identify which layer is slow.
Complete Alpha Bank Data Architecture
Now let's combine everything into one architecture.
Alpha Bank Pega Data Architecture
CustomerOnboarding
LoanApplication
AccountService
↓
Customer
Account
Loan
KYC
Card
↓
D_Customer
D_Account
D_Loan
D_KYC
D_Card
↓
Customer API
Core Banking
Loan System
KYC Provider
Card System
Senior Architect Interview Framework
When an interviewer gives you a new data requirement, use this sequence:
1. Entity → 2. Owner → 3. SOR → 4. Data Page → 5. Freshness → 6. Security → 7. Performance
The seven questions I ask
- What business entity am I modeling?
- Who owns the entity?
- What is the System of Record?
- Should Pega store it or retrieve it?
- Should the data be live or a snapshot?
- What Data Page pattern should I use?
- What are the security, caching and performance implications?
30-Second Interview Answer: "Explain Your Data Architecture"
Interview-ready answer:
"For a large banking application, I start with the enterprise data model and identify reusable business entities such as Customer, Account, Loan, Card and KYC. For each entity, I identify the System of Record and create a logical Data Object in Pega.
I expose those entities through Data Pages so the Case Types do not directly depend on databases or APIs. I use parameterized Data Pages for entity lookup, choose Thread, Requestor or Node scope based on reuse and freshness, and configure refresh strategies according to the business requirement.
For updates, I use Savable Data Pages where Pega needs to write back to the System of Record. I also consider security, data minimization, caching, high-cardinality parameters and source-system performance.
The key architectural principle is that the Case owns the workflow, the Data Object represents the logical business entity, the Data Page manages data access, and the System of Record owns the authoritative data."
Final Pega Data Architecture Checklist
| Area | Architect Question |
|---|---|
| Data Model | What are the reusable business entities? |
| Ownership | Who owns each entity? |
| SOR | Where is the authoritative record? |
| Data Object | What is the logical representation? |
| Data Page | How is the entity accessed? |
| Parameterization | What identifies the record? |
| Scope | Thread, Requestor or Node? |
| Refresh | How fresh must the data be? |
| Persistence | Read-only, editable or savable? |
| Security | Who can see or modify the data? |
| Performance | How much data is retrieved and cached? |
| Historical Data | Does the Case need a snapshot? |
| Integration | Can the Case remain independent of the API? |
Key Takeaway
Good Pega Data Architecture is not about creating more properties. It is about creating the right separation between business data, workflow, integration and Systems of Record.
A strong Pega architect should be able to explain not only what data Pega needs, but also:
- Where the data comes from
- Who owns the data
- How Pega accesses it
- How it is cached
- When it becomes stale
- How it is updated
- How it is secured
- How it performs under high load
- What happens when the source system is unavailable
References and Further Reading
- Pega Academy – Understanding Data Objects
- Pega Academy – Data Modeling
- Pega Academy – Data Pages
- Pega Academy – Data Page Scopes
- Pega Academy – Data Page Refresh Strategies
- Pega Academy – Savable Data Pages and Save Plans
- Pega Documentation – Data Pages
- Pega Documentation – Data Page Performance and Caching
- Pega Support / Pega Community – Data Page troubleshooting and performance discussions
Note: Pega terminology and configuration screens can vary between Pega Platform versions and between Dev Studio, App Studio and Constellation. For interviews, focus on the underlying architecture and explain the version-specific implementation when necessary.
Powered by PegaHelp.com
No comments:
Post a Comment