Handle price explosion and ERP-owned pricing in B2B

A decision-oriented guideline for large-volume, ERP-owned B2B pricing

How to use this guide

Large-volume B2B pricing projects usually fail for one reason: teams begin technical optimization — index tuning, cache sizing, import batching — before they answer the strategic questions. Answer these first: who owns pricing, where prices come from, how fresh they must be, and whether the ERP can meet the required sync and performance expectations.

Read this guide in order:

1. Understand the problem — learn why price volume explodes (see The problem).
2. Recognize the challenges — learn which effects appear only at unusual scale (see Typical challenges).
3. Run discovery — answer the questions before you choose anything (see Discovery questions).
4. Choose an architecture — apply the decision framework and matrix (see The decision framework).
5. Apply a strategy pattern — compare freshness, performance, failure modes, and when to choose or avoid each one (see Recommended strategy patterns).

1. The problem: why price volume explodes

B2B pricing is rarely one price per product. The total number of price records is a product of independent dimensions, and each dimension multiplies the others.

The scale math

Consider a conservative mid-size IGM example:

1,000 customers × 25,000 products × 2 (abstract + concrete) = 50,000,000 theoretical records

Even at only 20% contract coverage, this produces approximately 20,000,000 price records. This is the documented threshold where the Spryker out-of-the-box sync pipeline begins to degrade seriously.

The problem has three independent dimensions, and you must solve each one separately:

• Storage — Can the database and search index physically hold the data?
• Sync performance — Can you import and propagate prices fast enough?
• Retrieval performance — Can a single storefront request resolve the correct price in under 100 ms?

A strategy that fixes storage may do nothing for sync, and a strategy that fixes sync may not help retrieval. Keep all three dimensions in view.

2. Typical challenges at scale

Spryker’s standard pricing pipeline runs typical B2B catalogs — including sizeable contract-pricing assortments — without any of the work described below. The effects in this section appear only as you approach unusual scale (contract-price counts climbing toward the millions), and even then you address them selectively. Think of this section as a map of what can matter at the far end of the volume curve, not a list of problems every project faces. Discovery (see Discovery questions) tells you which of these are actually relevant to your project — for many, the answer is none.

The effects are grouped by the dimension each one touches.

Storage

• Search index explosion — When you embed customer-specific prices into search documents, the documents inflate to several MB each, and the index can exceed 1 TB. This slows both indexing and search.
• In-memory (Redis) footprint — Resolved prices held in cache grow to tens of GB at 20M+ records.
• Abstract/concrete duplication — In 1:1 projects, Spryker stores every price twice for no business value.

Sync performance

• Publish and Sync bottleneck — A nightly import that touches 20M rows fires 20M events. At realistic throughput, this takes hours to process, during which storefront prices are stale and non-deterministic.
• Data import performance — A naive row-by-row import of 20M rows is not viable.
• ERP sync lag or unavailability — Nightly-batch ERPs leave a multi-hour stale window, and some ERPs cannot produce a delta or even a full export at the required volume.

Retrieval performance

• Price resolution at checkout — Large carts that re-resolve customer-specific prices add latency.
• Cache as single source of truth — When you bypass the standard pipeline and write prices directly to the cache, you create a data-loss risk if the cache is lost. See the mitigation in Recommended strategy patterns.

3. Discovery questions — answer these before you choose a strategy

This section is the heart of the guideline. Do not select an architecture until you answer these questions. The answers, not the technology, determine the right path.

3.1 Volume and cardinality

• How many prices do you expect, of what types, and why? Break the number down by dimension: customers, SKUs, price types, currencies, stores, volume tiers, and offers. A single “20M” figure hides which dimension actually drives the total, and that dimension is where you intervene.
• Is the high cardinality a real business need, or an import artifact? For example, you might mirror every price on both abstract and concrete, or import thousands of offers per SKU that no buyer will ever compare.

3.2 Ownership and source of truth

• Which systems own pricing? The ERP, a pricing engine, a PIM, a contract-management system, or Spryker itself?
• Is that system the long-term source of truth, or is the customer transitioning? For example, a SAP ECC to S/4HANA migration where two systems are partially authoritative at once. See the guidance for asynchronous ERPs.

3.3 Integration shape

• Do you expect direct integration, or is middleware involved (for example, MuleSoft, Boomi, or Azure Integration Services)?
• Is the preferred exchange file-based (SFTP/S3), event-driven, or API/REST?

3.4 Freshness and verification

• How often do prices update — nightly, intraday, per contract change, or continuously?
• When does the price need verification? At browse time, cart time, or only at checkout? In most B2B flows, you place the order at the price the customer confirmed, and you handle disputes commercially. See Checkout price revalidation.
• How stale is acceptably stale? This is a business decision, not a technical limit.

3.5 Other systems that affect the final price

• Do external systems apply discounts, taxes, surcharges, or other fees — for example, a tax engine or a rebate service? These compose with base pricing and can change the effective load and the latency budget.

3.6 Load, latency, and ERP capability

• What load do you expect — peak concurrent buyers, and request rates for the catalog, PDP, cart, and checkout?
• Can the ERP or pricing engine handle that load at the target latency and availability, if you intend to call it live? Get real numbers from the ERP team rather than assumptions. This single answer decides whether live pricing is even on the table. See Performance guidelines: External HTTP requests, which explains why Spryker reads from fast storage and what to check before you deviate.

3.7 Phasing and the 1/2/5-year view

• What is the right phasing? You rarely need to solve for peak volume on day one.
• Slice the data volume for the first go-live, but design for what the business expects in one, two, and five years — more customers, more contracts, and marketplace expansion. The cheapest architecture today can become the most expensive rework later.

4. The decision framework

After you complete discovery, choose where prices live and when you resolve them. There are four base architectures. They are not mutually exclusive — the hybrid model deliberately combines them.

4.1 The four base architectures

4.2 Quick selection guide

4.3 What to do when the ERP cannot provide data as synchronously as you need

This is the most common real-world constraint, so it has its own decision path. Apply this path when the ERP cannot sync in bulk, cannot produce a delta, is mid-migration, or is periodically unavailable:

1. Decouple storefront availability from ERP reliability. Never let a slow or unavailable ERP take down the storefront. Serve from a local base or the last-known cache instead.
2. Cache with a business-agreed TTL (architecture 2). For browse and cart, stale-but-available beats fresh-but-unavailable.
3. Make staleness visible (strategy S7). Show “Price as of HH:MM” and a “confirmed at order placement” badge so that buyers trust what they see.
4. Confirm the real price at order placement (see the hybrid pattern), not at every page view.
5. During an ERP migration (for example, ECC to S/4HANA with two partial sources), use a dual-source resolver: try the new ERP, then fall back to the legacy cache, then fall back to the last-known local price, and finally show “Price on Request” and trigger the Quote Request flow.
6. If you cannot resolve any price, treat “Price on Request” plus Request-a-Quote as the correct B2B business process for high-value or uncatalogued items, not as an error state.

5. Recommended strategy patterns

Each pattern below uses the same structure, so that you can compare the patterns directly, in this order: Choose it when, Operational complexity, Freshness, Failure modes, Performance assumptions, and When to avoid.

Choose the pattern that matches your discovery answers. Most IGM projects land on the Spryker-managed read model plus the hybrid pattern — a synced read model plus checkout confirmation — and add cached pricing during an ERP transition.

5.1 Spryker-managed read model for high-volume prices

In this pattern, Spryker owns the resolved, storefront-ready price representation. The ERP — or any other source — feeds prices into Spryker, and from that point the storefront reads them locally and never calls the ERP at request time. This is how a standard Spryker shop already works: prices are imported, published to the storefront cache and search index, and served from there. It is therefore the natural starting point for most projects, and you add the scale levers below only if your actual volume or refresh needs call for them. For the underlying price types, dimensions, and resolution order, see Prices feature overview.

• Choose it when the ERP can export prices reliably (a daily or delta feed) and freshness needs are measured in hours rather than seconds. This fits the large majority of B2B contract-pricing catalogs.
• Operational complexity: Low. This is the closest pattern to standard Spryker, and the tooling — import, Publish and Sync, storefront resolution — already exists out of the box. The write-path levers below are optional extras for very high record counts; most projects go live without them.
• Freshness: As fresh as the last import and publish, typically hours. It is not aimed at prices that must be current to the second — use cached pricing or the hybrid pattern for that.
• Failure modes: Sync lag shows prices from the previous publish within a known, bounded window — rarely a concern for stable contract pricing. If you deliberately make the cache the sole source of truth, plan for cache loss with persistence (AOF/RDB), enough memory to avoid eviction, and a warm-up re-publish on restart.
• Performance assumptions: All reads are served locally from the cache, index, or database, so they are fast, predictable, and independent of the ERP. Out of the box this scales comfortably for typical catalogs. Only at extreme volume (contract prices in the millions) might you optionally tune the write path — batched imports (S4), delta-only updates, an optimized Publish and Sync (S5), and trimming price data out of the search index (S1); S2, S3, and S8 further reduce the record count at the source.
• When to avoid: Skip this pattern only when prices genuinely must reflect ERP changes within seconds, or when the ERP cannot export at all — then use live pricing, cached pricing, or the hybrid pattern.

5.2 ERP-owned pricing with batch/import synchronization

Here the ERP stays the definitive source of truth and pushes prices into Spryker on a schedule — a nightly full export, or, better, a delta feed of only what changed. Spryker imports the feed and publishes it to the storefront. It is essentially the read-model pattern (5.1) with an explicit contract that the ERP owns the data and Spryker holds a served copy, and it is the most common integration for stable contract pricing.

• Choose it when pricing is stable contract pricing without intraday urgency and the ERP owns it long-term. A daily or delta feed keeps the storefront correct with very few moving parts.
• Operational complexity: Low to medium. You monitor the import and the sync queue as you would any scheduled integration. A delta feed keeps daily volumes small, so most projects run this comfortably without special tuning.
• Freshness: Up to one cycle stale — for example, around 22 hours with a single nightly 02:00 import. A delta or event-triggered feed narrows this to minutes.
• Failure modes: A price change is not visible until the next cycle; a failed import simply leaves the previous prices in place (safe, if not fresh); and a very large full re-import can queue for a while. Delta feeds and basic monitoring remove most of this.
• Performance assumptions: Comfortable for typical daily volumes out of the box. The optional import and Publish-and-Sync levers matter only when a single load approaches millions of rows — bulk writes, delta-only filtering, pre-loaded lookups, and streaming (S4, S5). At that scale, prefer a delta or API feed (S10, the Data Exchange API) over a full nightly file; a 20M-row flat file is an integration smell, not a Spryker limit.
• When to avoid: Avoid a batch-only approach when buyers must see intraday price changes immediately, or when the ERP cannot produce any usable export — move to cached pricing or the hybrid pattern.

5.3 Cached pricing via middleware or pricing service

In this demand-driven pattern, Spryker asks the ERP or a pricing service for a price the first time it is needed — often through middleware — and caches the answer for a configurable time (the TTL). Later requests are served from the cache until the TTL expires, then refreshed on the next request. It keeps prices close to real time without requiring the ERP to push bulk syncs, which suits sources that can answer on demand but cannot export everything.

• Choose it when the ERP can answer per-SKU on demand but cannot sync in bulk, or the customer is mid-migration between systems. You get near-live prices without a heavy sync pipeline.
• Operational complexity: Medium. You add a source connector, pick a TTL, and add a circuit breaker so a slow source never blocks the storefront. These are standard integration building blocks, and the TTL is a simple business dial.
• Freshness: Near real time, bounded by the TTL — a business choice such as 15 minutes or 1 hour.
• Failure modes: If the source is slow or unavailable, a circuit breaker serves the last-known price and a staleness badge (S7) keeps buyers informed; without one, request latency would rise. Because the cache holds prices between fetches, apply the same persistence and warm-up care as in the read-model pattern.
• Performance assumptions: The first request for a SKU and customer pays one source round-trip; everything after is cache-fast until the TTL expires. Batch the misses on a page into a single source call (S6) to keep it responsive, and pair with S7 for transparency.
• When to avoid: Avoid this when the source cannot meet even on-demand latency and availability under load — in that case, fall back to a synced base (see the read-model pattern).

5.4 Live pricing from ERP / pricing engine

This pattern resolves every price directly from the ERP or pricing engine on every request, with no local price store. It offers the strongest possible freshness guarantee, and in exchange it places the ERP on the critical path of every storefront page. It is the right choice only in the specific cases where prices must always be live and the ERP has been proven able to carry that load.

• Choose it when prices genuinely must be live on every page and the ERP or pricing engine is proven — through the load and latency discovery in section 3.6 — to sustain that traffic at the required latency and availability.
• Operational complexity: High. The ERP and the storefront must be capacity-planned, scaled, and monitored together, because they now share one critical path. Choose this deliberately, not by default.
• Freshness: Always current — the strongest guarantee available.
• Failure modes: The ERP’s latency, availability, and rate limits become the storefront’s. An ERP incident becomes a storefront incident, and there is no local fallback by design — which is exactly why the hybrid pattern (5.5) exists.
• Performance assumptions: Every catalog, PDP, cart, and checkout request depends on the ERP responding inside the storefront’s latency budget at peak concurrency. This is viable only when section 3.6 discovery proved that headroom, and with aggressive request batching.
• When to avoid: Avoid this whenever there is any doubt about ERP capacity, which is the common case. Prefer cached pricing or the hybrid pattern, which deliver most of the freshness with none of the single-point-of-failure risk.

5.5 Hybrid: local browse/cart prices + checkout revalidation

The hybrid pattern is the realistic default for most enterprises. Spryker serves prices locally for browsing and the cart, so those high-traffic pages stay fast and always available, and then confirms the authoritative price once, at order placement. You get the responsiveness of a local read model together with the correctness of a final live check — and Spryker performs that checkout re-resolution out of the box.

• Choose it when you build almost any large IGM B2B shop, especially for customers in ERP transition or with imperfect exports. A local base serves everyday traffic, and a live top-up fills the gaps (new customers, missing prices).
• Operational complexity: Medium. You run a local read model plus a revalidation path, but each is simpler than full-live, and the checkout re-resolution is standard Spryker behavior rather than custom code.
• Freshness: Browse and cart prices are as fresh as the local base (see patterns 5.1, 5.2, and 5.3), and Spryker confirms the final order price at placement, so the committed price is always correct and current.
• Failure modes: The browse price may differ slightly from the confirmed price at order. You handle this commercially, not technically: Spryker places the order at the confirmed price, and B2B buyers can cancel through normal order management if they disagree. A staleness indicator (S7) keeps this transparent.
• Performance assumptions: High-traffic pages get fast local reads, and the single authoritative resolution happens once, at checkout. The Spryker calculator stack re-resolves prices at order placement out of the box, so you need no custom blocking logic.
• When to avoid: Avoid this only when the displayed browse price must itself be contractually binding in real time — rare in B2B, where the order confirmation is the point of commitment.

5.6 Marketplace addendum — offers as an orthogonal dimension

This addendum is relevant only if the same product is sold by multiple sellers through product offers. Offers multiply the record count and change the storage shape — Spryker rewrites a per-concrete aggregate wholesale on any change. The same freshness, performance, and failure thinking applies, plus these offer-specific patterns:

• Split the per-concrete aggregate keys so that one offer change is an O(1) write instead of an O(all offers) write (O1, O2).
• Deduplicate and apply incremental offer Publish and Sync (O4).
• Pre-resolve the buy-box (winning offer) at publish time. Buyers see one winner, so do not sort thousands of offers at read time (O5).
• Paginate and lazy-load offers. There is no offer pagination out of the box on either the API or the storefront, so you must build it (O6).
• Use live/TTL offer fetch for external seller systems (O7), and direct/synchronous sync for latency-sensitive interactive edits (O9).

Recommended offer stack for high-offer-count marketplaces: O1 + O2 + O4 + O5 + O6.

6. Putting it together

Your starting point is standard Spryker. A default installation already imports prices, publishes them, resolves customer-specific and contract pricing, and revalidates at checkout — no strategies from this guide required. For a typical IGM mid-market customer, that out-of-the-box behavior is the baseline you build on, and often it is enough on its own.

The strategies in this guide are a menu, not a bundle. You turn one on only when a specific condition in your project makes it worthwhile — and many projects turn on few or none. Use the table below to match a condition to the optional refinement that addresses it.

None of these are prerequisites for going live. Treat each row as a lever you reach for when — and only when — its condition applies. If your project is a straightforward contract-pricing catalog with a reliable ERP feed, you may never open this menu at all.

One thing worth deciding early, though, is direction rather than effort: frame your architecture against the 1/2/5-year view (see Phasing and the 1/2/5-year view). Sizing the first go-live to a sliced data volume is fine, but choose an architecture the business will not outgrow in year two.

Appendix — strategy index

The What to do column summarizes the approach for each lever. Treat it as a starting point for a technical design, not as a step-by-step implementation guide: the exact plugins, keys, and configuration depend on your project setup and Spryker version.