Claims Intake Latency and Data Page Scope

I would keep requestor scope and add a reload-if-older-than-5-minutes refresh strategy, combined with parallel loading of the two services. The reasoning is that D_CustomerSummary is customer-level data, so node scope with a customer-ID parameter would cache many customers across users, creating memory pressure and a region-security risk; application scope is even less suitable. Requestor scope with a 5-minute refresh reduces the 3–4 repeated calls per session to at most one call per 5 minutes, preserving freshness and access control. However, scope alone does not meet the sub-2-second target because the first load still costs about 2.25 seconds. Split the summary into two data pages, D_PolicyDetails and D_ClaimsHistory, and load them concurrently on case open so the critical path is roughly the slower service (1.4 s) plus rendering. If the summary were region-level rather than customer-level, node scope with a region parameter would be viable, but here it is not. Validate the design with access-control tests and a load test at 1,800 concurrent users.

Before implementation, validate four things. First, confirm the data page parameterization and access control: a requestor-scoped data page still needs role- and region-based access checks, and the refresh strategy must not expose stale data after a user changes region. Second, review service-call behavior: timeouts, retry limits, error handling, and whether a failed policy call should block the summary or degrade gracefully. Third, check memory and cluster behavior: requestor-scoped pages persist per session, so estimate heap growth at 1,800 concurrent users and confirm session timeout clears the pages appropriately. Fourth, confirm that the parallel data pages do not create circular dependencies or unnecessary declarative processing. Also verify that the 5-minute freshness applies only to policy data; claims history may tolerate a longer refresh if the business agrees. This avoids optimizing for a requirement that only applies to one source.

Test in three layers. Performance: run a load test simulating 1,800 concurrent users with realistic think times and 3–4 screen transitions per session; measure p95 screen load and confirm it is under 2 seconds. Also measure service call counts per session to prove the 5-minute cache is working. Freshness: create a controlled update to a policy record, then verify that a new requestor sees the updated value immediately and that an existing session sees it after the 5-minute window, not before. Security: test users assigned to different regions and confirm they never receive another region's customer summary, including after refresh. Finally, monitor production for cache hit ratio, service latency, and session memory. If p95 remains above target, the next step is not a broader scope but asynchronous pre-fetch or a summary projection service.