Architecture diagrams are useful. They’re also misleading about time. A box labeled CDP connected by an arrow to a box labeled AI layer doesn’t tell you when the connection happens, what data is available at that moment, or what breaks first if the connection degrades.
This is a trace of a single Add to Cart request through the Webscale data plane. Timestamps are normalized to a baseline 100ms request. It’s meant to make the architecture concrete.
1. The first ten milliseconds
A returning shopper on a Webscale-hosted Adobe Commerce storefront clicks Add to Cart.
- T+0ms: The request enters Webscale’s CloudEDGE layer at the nearest point of presence. SSL terminates here. The request hasn’t touched your origin yet.
- T+2ms: Web Controls evaluates the request. Security rules run. Bot scoring runs. Rate limiting checks run. For a dynamic cart update, it passes to the next layer.
- T+6ms: The request reaches the CDP layer, inline in the data plane. The CDP reads the session token, looks up the shopper’s first-party profile, and records the cart event. The profile update is synchronous with the request, not queued for later.
- T+7ms: AI Segmentation reads the updated profile. The shopper has added their third item this session. Their segment classification updates in the same data plane, not via an external service.
- T+8ms: The AI Shopping Assistant has the current cart state and the updated segment when generating the next recommendation. No separate API call to a warehouse. No waiting for a data pipeline to propagate the cart event. The recommendation the shopper sees is based on the session they’re in right now, not a behavioral snapshot from minutes earlier.
- T+10-100ms: The request travels to origin. The cart update is processed. The response is returned.
- T+return: The session event is logged. The profile is complete with this interaction.
In this request trace, the CDP and AI layers added roughly 2ms to the request path. For a 100ms total request time, that’s 2% overhead.
2. What external CDP query latency costs
Querying an external CDP and waiting for a response adds 30–80ms at normal load. At 3x baseline traffic, that number climbs. External CDP query latency under peak load is commonly 150–300ms. That’s not the same as 2ms.
More importantly: the AI layer at T+7ms has current data. Not data from the last sync cycle. Not data from this morning’s pipeline run. The profile it reads includes every event from this session, up to the Add to Cart click.
For a shopper on their third product view with two items already in cart, the difference is real. Recommendations diverge. Segment classifications diverge. The AI Shopping Assistant surfaces different products. That gap grows as session complexity increases.
For the broader context on why data staleness compounds under load, see Two Minutes of Stale Data: What Latency Costs in Commerce AI.
3. The failure mode you’re not monitoring
In an inline architecture, if the CDP layer has a problem, it shows up in request latency immediately. Every request that passes through the degraded layer adds latency. The on-call engineer sees a spike in the same dashboard they already monitor. Response time is fast because the signal is loud.
In an application-layer architecture, if the external CDP is slow or unavailable, the commerce application either waits for the CDP response or falls back to serving unpersonalized content, silently. The second behavior is more common. The application is technically responding correctly. It’s just responding without the data it needs. No alert fires.
Inline failure is loud. External failure is quiet. Loud failures get found. Quiet failures run until someone notices conversion rate dropped.
For how this plays out under real peak load conditions, see What Breaks First When Ecommerce Traffic Doubles in 90 Seconds.
What to ask in your next infrastructure evaluation
Two questions worth asking any vendor with an AI personalization layer.
Verify how your CDP behaves when it’s degraded, not when it’s healthy. Is the fallback a stale profile, a generic profile, or an error? Which is the default behavior, and how would you know it’s happening?
Ask your vendor for CDP query latency at 2x peak, not just at normal load. If they can’t give you a P95 number for both conditions, you don’t have the data you need to make that evaluation.
Inline CDP architecture changes the timing of the request itself, not just the quality of the downstream analytics. Two milliseconds of overhead. Synchronous profile updates. Failure that surfaces in the metrics you’re already watching.
To understand the broader stack context in which this request trace sits, see Inside the Stack: Where Ecommerce AI Lives.
See how Agentic Commerce OS works: webscale.com/agentic-commerce-os/
