Diagnosing a Slow Order History Screen at Peak

The screen is doing three expensive things at once. Highest impact: Max Records 0 with Fetch At Start returns every order for the customer and loads them into the screen; for a long-tenured customer this can be thousands of rows, repeated per request. Second: the loop calls a shipment aggregate per order, an N+1 pattern; 2,000 orders become 2,001 queries. Third: the missing composite index on CustomerId+CreatedOn forces a scan and sort on 1.2M rows; the separate count aggregate doubles the work. Fourth: no server-side pagination means the UI cannot limit data. The category cache is irrelevant because the bottleneck is order data and query count. Rank by expected reduction: remove N+1 and cap records first, add the index second, combine or replace the count third. Use the database execution plan and OutSystems logs to confirm before changing. Do not start by scaling the app tier; that hides the query pattern and increases database load.

Use a server-side paginated data action. Set the aggregate Max Records to 50 or 100 and Fetch to Only on Demand; pass CustomerId and a page cursor or offset. Sort by CreatedOn descending and use the composite index. Replace the per-order shipment aggregate with a single aggregate that joins Order and Shipment, or a batch fetch by order ID set, then map in memory. Avoid a separate count per page: either show load more without a total, or compute a count once per customer and cache it briefly with invalidation on new order. Expose the data through a data action used by the screen; keep the preparation light and move optional calls to on-demand. If a SQL widget is needed for a covering query, keep parameters bound and verify the plan. Add a performance budget: p95 under 2 seconds at 1,200 users. Test with a customer who has 5,000 orders, not the seeded test user with 10.

Load test the order history and checkout paths at 2,400 concurrent users with realistic data distribution. Instrument the screen and aggregates; monitor p95, database CPU, slow queries, thread pool and error rate. Capacity: add a read replica only if reads are the bottleneck and the driver supports it; scale the app tier horizontally; move noncritical work such as email and export to timers or async. Add caching only for stable reference data, with explicit invalidation. Put a query review gate on any aggregate over a large entity: max records, index, filter, and expected cardinality. In LifeTime, create alerts on database CPU above 80% and p95 above 3 seconds. Do a monthly performance regression test. The goal is not one fast screen; it is a rule that no production screen can fetch unbounded rows or loop a query. Track the number of N+1 patterns found in code review as a leading metric.