The Prefill That Times Out at Scale
An Adaptive Form uses a Form Data Model backed by a REST data source to prefill customer account details on load. The backing service returns a payload of about 2 MB per customer (including a full transaction history the form does not display). Average prefill latency in test is 1.2s; in production during peak (about 300 concurrent users) it rises to 9-12s and some requests time out at the 30s gateway limit. The form only needs six fields from the response. The data source is configured with default connection pooling, and the FDM service is invoked on form initialization for every open. The team also reports that editing a field triggers a re-fetch of the whole payload.
1. Identify the primary causes of the production latency and the re-fetch on field edit.
Read the worked answer
Three compounding causes:
- Over-fetching: the FDM pulls a 2 MB payload to populate six fields. Payload size, not compute, dominates latency, and it multiplies under 300 concurrent users.
- No request shaping / caching: every form open triggers a full service call. With default pooling and a slow upstream, connections queue under load, turning 1.2s into 9-12s and hitting the 30s gateway ceiling.
- Re-fetch on field edit indicates the form is bound such that a field change re-invokes the service (e.g., a service call wired to a change event or a binding that re-resolves the data source) rather than reading from already-loaded model data.
The 30s timeouts are a symptom of queueing behind a saturated upstream, not a fixed per-request cost.
2. Propose a remediation plan ordered by impact, and state what you would measure to confirm each step.
Read the worked answer
Ordered by impact:
- Shape the request - have the data source/service return only the six needed fields (server-side projection or a narrower endpoint). Measure: payload size and p95 prefill latency. This is the biggest lever because it attacks the dominant cost.
- Cache per customer - cache the projected response keyed by customer ID with a short TTL, so repeated opens and re-renders do not re-hit the upstream. Measure: upstream call rate vs. form-open rate.
- Decouple field edits from the service - bind fields to already-loaded FDM data; remove any change-triggered service invocation unless a field genuinely needs a fresh server lookup. Measure: service calls per session.
- Tune connection pooling / concurrency to the upstream's real capacity, and align gateway timeout with expected p95 rather than masking saturation. Measure: queue wait time and timeout count at peak.
Confirm success against the original symptom: p95 prefill under load and zero gateway timeouts at 300 concurrent users. Do not declare victory on average latency alone - the timeouts are a tail problem.