48 Pickup Badges, 48 RESTlet Calls on Mobile
Luma Sportswear has a SuiteCommerce Advanced storefront with 38 stores and 4,800 SKUs. Each product card on a 48-item category page renders a 'Pick up today' badge. The current frontend extension calls a custom RESTlet once per card after page load; each call takes about 600 ms and the page issues 48 calls. On a mid-tier Android phone over 4G, LCP is 6.4 seconds and total blocking time is 1.9 seconds. The RESTlet performs a saved search per SKU. During a Memorial Day promotion, NetSuite concurrency limits were reached and some badges showed 'Unavailable' even though stock existed. The store selector is in the header and persisted in a cookie. The team can deploy extensions but cannot modify the core theme or add a CDN worker. Analytics shows 62% of sessions are mobile.
1. Diagnose why the page is slow and why raising RESTlet concurrency is not a fix.
Read the worked answer
Client-side cause. The extension creates a fan-out: 48 independent RESTlet calls start after page load. Browsers limit concurrent connections per origin, so the calls queue and the later cards wait behind earlier ones. Each callback runs on the main thread, which explains the 1.9-second total blocking time and the 6.4-second LCP on a mid-tier phone. Even if each call were fast, the pattern would still be slow because of connection setup, auth handling, and callback overhead.
Server-side cause. The RESTlet performs a saved search per SKU. That is an N+1 query pattern inside an already repeated request: 48 requests become 48 searches, each with its own script invocation and governance cost. There is no batching and no reuse of the store context across cards.
Why more concurrency is wrong. Increasing concurrency or parallel requests pushes more simultaneous work into NetSuite during the exact traffic spike when the account is least able to absorb it. It may improve one page's latency while degrading all pages and triggering the same concurrency ceiling. The Memorial Day false 'Unavailable' badges are a correctness symptom: the client likely mapped a timeout or throttled response to unavailable rather than to unknown. The fix must reduce request count and distinguish failure from absence of stock.
Conclusion. The page needs one batched request, a server-side set-based lookup, and a UI that tolerates an unknown result. Tuning concurrency treats the amplification as a capacity problem.
2. Design the frontend and server-side changes to render 48 badges with one request and correct store context.
Read the worked answer
Server endpoint. Add one SSP service endpoint that accepts a store identifier and an array of SKUs. Resolve availability with a single search using an IN filter over the SKU list, ideally against a compact availability record rather than loading item and inventory records row by row. Return a map of SKU to status plus an asOf timestamp and a storeId. Cap the array size and reject oversized batches explicitly.
Caching. Cache results per store and SKU for a short TTL, for example 5 minutes, using the platform's cache facility or a small availability record. Inventory is perishable; a long TTL will show false availability. Do not cache customer-specific or contract data in a shared key. The store identifier must be part of every cache key, or the header selector will show another store's stock.
Frontend flow. Wait until the store is known from the cookie or header, then issue one request for the visible SKU list. Render a neutral skeleton badge immediately. If the shopper changes store, abort the in-flight request, clear the badges, and refetch; otherwise a late response can paint the previous store's availability. For long category pages, batch the first screen immediately and lazy-load below-the-fold badges with IntersectionObserver rather than requesting all 48 at once when only a few are visible.
Why an extension still works. The extension can add the module, template fragment, and client script without modifying the core theme. Keep the badge rendering in an extension template and the request logic in a custom module so future theme updates do not remove it.
3. How should the UI handle timeouts and false 'Unavailable' results, and which metrics prove success?
Read the worked answer
Failure semantics. Distinguish three states: available, unavailable, and unknown. A timeout, throttling response, or malformed payload must produce unknown, displayed as 'Check store' or a neutral badge, never as 'Unavailable'. False unavailability loses sales and destroys trust in the badge. Include the asOf timestamp and show a subtle stale indicator when the data is older than the agreed threshold.
Retry policy. Use one retry with backoff for a failed batch, not a retry per card. If the retry fails, render unknown and stop. Avoid an automatic retry loop during a concurrency incident; that turns a transient failure into a sustained one.
Accuracy check. Sample at least 100 SKUs across several stores against the store operations report immediately after a batch load. Track the unknown rate and the disagreement rate. A low request count with a high unknown rate is not success.
Performance metrics. Success means one availability request per category page for the initial viewport, server p95 under 1 second, LCP under 2.5 seconds on the mid-tier Android profile, total blocking time under 200 ms, and no concurrency alarms during a promotion test. Track these with real-user monitoring segmented by mobile and desktop, not only with a lab test on a fast desktop.
Business metric. Monitor pickup-badge click-through and store pickup conversion before and after. If badges become more accurate but conversion does not move, the team may have solved a technical problem that was not the customer's main obstacle.