Most data plane discussions stop at architecture diagrams. They don’t show what actually happens when live traffic hits the system.
This walkthrough follows real request flows through the data plane: how session signals are captured, how classifications are generated, and how recommendations are produced within the request cycle. For a deeper architectural breakdown of where these components sit, see Inside the Stack: Where the AI Lives.
Everything shown here reflects production behavior. Not a staged demo, not synthetic traffic. The same processing path that handles live shopper sessions.
The setup
We’re watching traffic to a live Adobe Commerce storefront running on Webscale. The merchant is an athletic apparel retailer, mid-market, roughly $50M GMV. Peak traffic is around 3,000 concurrent sessions during sales events. Normal traffic is 200–400 concurrent sessions.
The storefront uses standard Adobe Commerce architecture: Varnish cache, Elasticsearch, Redis sessions, MySQL backend. Nothing custom. The only addition is Webscale’s application delivery layer sitting in front of the origin.
From the merchant’s perspective, requests work exactly as they did before. From a technical perspective, every request now passes through the inline CDP and AI layers. If you want to see how an individual request moves through each layer in detail, including timing and system interactions, see the ecommerce request trace walkthrough.
All performance figures in this walkthrough come from aggregate Webscale production telemetry. Numbers reflect mid-market Adobe Commerce deployments at typical traffic loads. Results vary by merchant configuration.
This walkthrough simplifies some aspects of production behavior for clarity. Real-world traffic patterns, edge cases, and concurrency effects introduce additional variability that isn’t fully represented in a linear walkthrough.
Request 1: New visitor, product browsing
11:23 AM: A new session from Seattle hits the homepage. No existing profile. Session token is generated. The CDN cache serves the homepage instantly.
11:23:15 AM: Same session requests /mens-running-shoes. This is a dynamic category page, so it goes to the origin. The CDP creates an initial profile: new visitor, direct traffic source, browsing men’s running category.
11:23:22 AM: Product view: /mens-running-shoes/trail-runner-pro. The AI Segmentation layer reads the session history (homepage, category, product view) and the product data (trail running, premium price point, technical specs prominent).
Classification: “research-oriented browser, outdoor activity focus, price-insensitive signals.” This classification is generated inline as part of the request processing cycle that serves the product page.
The AI Shopping Assistant has access to this classification when it generates the “you might also like” section. Instead of generic cross-sells, it surfaces technical trail running products and premium outdoor gear. The recommendations are constrained to actual inventory and real product relationships.
Request 2: Same session, add to cart
11:24:15 AM: Same session adds the trail runner to cart. The CDP updates the profile synchronously: browsing behavior + purchase intent signal. The cart total ($180) and product category (technical trail gear) refine the segmentation.
AI Segmentation reclassifies: “high-intent technical buyer, outdoor segment, premium tolerance.” This classification is available to subsequent requests within the session as part of the evolving profile state. These classifications are probabilistic and may evolve as additional session behavior is observed. Early-session signals can produce different classifications than later, more complete interaction patterns.
The cart page loads with personalized upsell recommendations: technical running socks, hydration pack, GPS watch. These recommendations are generated based on the updated behavioral profile and product affinity signals. They’re generated by the AI Shopping Assistant using the updated behavioral profile and product affinity models.
Request 3: Different session, similar pattern
11:25 AM: Different visitor, different geographic location, hits the same product page (/mens-running-shoes/trail-runner-pro).
This session has different behavioral signals: came from Google organic search for “best trail running shoes 2026”, bounced from two other product pages quickly, spent 45 seconds reading reviews on this product.
AI Segmentation classification: “comparison shopper, review-driven, price-conscious signals.” Same product, different behavioral profile, different classification.
The AI Shopping Assistant generates different recommendations: value-tier trail runners, customer review highlights, price comparison charts. Same product page, personalized for a different buying pattern.
Request 4: Returning customer, session continuity
11:26 AM: Returning customer from the first session comes back via email click. The CDP recognizes the session token and loads the existing profile: research-oriented browser, technical trail running interest, $180 item in cart.
The AI layers have access to the complete session history, including the cart contents and previous classifications. The homepage now shows technical outdoor gear prominently, running gear sales, and trail running content.
This isn’t a separate personalization API call. The profile data is accessed inline as part of request processing, making the personalized homepage response available in the same time window as a standard cached page.
What the monitoring dashboard shows
Source: Webscale production telemetry, aggregate across managed merchant accounts. Figures are representative of mid-market Adobe Commerce deployments at standard traffic loads. Your environment will vary.
The engineering interface shows real-time metrics for all of this processing. Representative telemetry from Webscale-managed Adobe Commerce environments shows:
- Request latency remains within normal dynamic request ranges, with incremental overhead introduced by CDP and AI layers measured in single-digit milliseconds.
- Profile update latency is typically within the same request processing window, allowing updated classifications to be available during the session.
- AI recommendation generation operates within low-millisecond response times, including catalog lookups and affinity calculations.
- Error rates are low and generally tied to transient latency conditions during traffic spikes, with fallback mechanisms maintaining response continuity.
The failure mode test
We can simulate failure modes in real time. Let’s introduce artificial latency in the AI Segmentation layer and watch what happens.
11:28 AM: AI Segmentation layer latency artificially increased to 200ms (from normal 2–8ms).
Effect on requests: Total request time increases proportionally. Every dynamic request now shows ~200ms additional latency. This appears immediately in our request latency dashboards.
The failure is loud and obvious. Response time alerts fire within 60 seconds. The on-call engineer can identify the degraded layer from the same dashboards used for all infrastructure monitoring.
Recovery: AI Segmentation latency restored to normal. Request times return to baseline within the next request cycle. No persistent data loss is observed, and profile state remains consistent after recovery.
What this tells you about inline architecture
This behavior is a direct result of architectural placement. Because the CDP and AI layers operate within the data plane, they observe and act on session signals as they occur, rather than relying on downstream processing pipelines. The system minimizes reliance on asynchronous processing and batch reconciliation for session-level personalization decisions. The behavioral data is read, processed, and applied in real time.
The personalization quality reflects current session state, not historical snapshots. A customer showing high-intent behavior today gets high-intent treatment today, not after the next data pipeline runs.
The failure modes are visible immediately and resolve quickly. There’s no silent degradation where personalization quality drops but nobody notices for hours.
The integration footprint at the application layer is minimal, as Adobe Commerce continues to serve requests without requiring direct modification to its core logic. Adobe Commerce serves requests exactly as it did before. The personalization layer operates transparently at the delivery level.
This is what data-path architecture looks like in production. Real requests, real performance, real failure modes, all visible and measurable.
FAQ
How does a data plane work in real time?
A data plane sits between incoming requests and your application origin, processing every request inline. In Webscale’s architecture, the CDP captures behavioral signals, AI Segmentation classifies the session, and the AI Shopping Assistant surfaces recommendations. All of this happens within the same request path, without relying on delayed batch reconciliation for session-level decisions. Personalization reflects current session state, not a historical snapshot.
What does a live data plane demo look like?
A live data plane demo shows request-level processing in real time: session creation, behavioral classification, and AI-driven recommendations all visible in the same monitoring dashboard your engineers use in production. The walkthrough above traces four sessions across new visitor, add-to-cart event, comparison shopper, and returning customer scenarios, showing how the CDP and AI layers handle each one inline.
How do you monitor data plane performance?
Data plane performance monitoring tracks request latency at the 50th and 95th percentiles, profile update latency, AI layer response times, and per-component error rates. Webscale’s engineering dashboard shows these in real time, with automated alerts that fire when any layer degrades. Failure is loud, visible, and fast to isolate without relying on lagging reports or silent degradation.
What are data plane failure modes?
One common failure mode is increased latency within an inline layer: if an inline layer slows down, total request time increases proportionally and the degradation appears immediately in monitoring dashboards. Webscale’s data plane falls back gracefully. If AI Segmentation or the AI Shopping Assistant exceeds latency thresholds, requests fall back to cached recommendations with no data loss and no profile corruption.
See how Webscale’s data plane operates in your Adobe Commerce environment → webscale.com/agentic-commerce-os/
