Customer Profile Integration Under Rate Limits
TelcoNova's Pega application displays customer profile, account balance, and active services from a REST service. The service averages 600 ms but has a 3-second p95 and enforces 200 requests per second. The application has 4,000 concurrent users and 1.2 million customers. Today a requestor-scoped data page for customer profile is loaded on every access, and support reports two problems: balance is stale after a payment, and login spikes to 4,000 requests per second. The JSON response contains nested arrays for services and optional fields such as middle name and billing address. The service returns 404 for unknown customers and 503 during peak. The integration team wants to avoid building a separate database cache. Agents must still open a case and capture notes when the service is down.
1. Recommend data page scope and refresh strategy for profile, balance, and active services. Explain trade-offs and how you would stop the login spike.
Read the worked answer
Profile changes slowly, so use a broader scope, such as node or application, with a reload-if-older-than strategy of about 15 minutes. Balance changes quickly, so use requestor scope with a short reload interval, for example 1 minute, plus an explicit refresh after payment. Active services can use node or application scope with a 5-minute interval if the business tolerates that delay. Avoid thread scope for data shared across a case or user.
The login spike comes from loading profile on every access. Remove the login-time load and load the data page only when the first screen needs it. Add asynchronous prefetch if needed, enforce client-side throttling, and monitor calls against the 200 requests per second limit. Do not use reload-on-every-access for high-volume data.
2. Design the integration error handling and mapping so agents can work during a 503 and optional nested fields are preserved.
Read the worked answer
Configure the REST connector with an error handler that distinguishes business errors from technical errors. A 404 should be handled as unknown customer and shown to the agent, not retried indefinitely. A 503 should trigger a bounded retry with backoff and, if it still fails, fall back to the last cached page with a visible stale-data banner. Do not block case creation or note capture; queue a refresh or retry through a queue processor.
Map the response with a data transform. For the services array, use an apply-data-transform loop to create a page list. Map optional middle name and billing address with when conditions so missing values become blank or null rather than causing mapping failure. Validate required fields after mapping and log the correlation ID so support can trace failures.