Peak-Load Activation Test Plan for a Customer Data Platform

To load test a customer data platform (CDP) for peak traffic, drive synthetic events and profiles at an open-model arrival rate, then measure four things separately: ingest throughput, segmentation lag, activation fan-out, and behaviour when destinations rate-limit you. Pass criteria are latency percentiles and backlog-drain times at a margin over your forecast peak (we suggest 2x), not average throughput. This plan gives the workload model, scenarios, metrics, pass criteria and tooling.

Who this is for: engineers and operations leads preparing a customer data platform for a sales event, launch or seasonal peak. It belongs to the high-load commerce and telecom hub.

What you are proving

A peak test is not a benchmark. It answers business questions:

1. Do we accept every event without loss, and can we prove it?
2. Does segment membership update fast enough for the campaign to be relevant?
3. Do activations reach destinations within the promised time, without duplicates?
4. When a destination slows or rejects traffic, do the other destinations stay healthy?
5. After a spike, how long does the backlog take to drain?
6. Can we replay or backfill during live traffic without breaking either?
7. Is consent honoured under load?

Each question becomes a scenario and a pass criterion below.

Build the workload model first

Derive the model from your last real peak, not from a vendor datasheet. Take events per second, new profiles per second, segment count, destination count and the ratio of anonymous to identified traffic from logs. Then project forward.

A worked example, with assumptions stated (illustrative, not benchmarks):

Test at 1x, 2x and 3x of the burst figure. The cost side of the same traffic is in why per-profile pricing breaks at scale.

Synthetic generators

Events

Real traffic is not uniform, and uniform tests flatter systems. Your event generator should reproduce:

• A skewed distribution of events per user, where a small share of users produce most events.
• A realistic event mix (page views, product views, add-to-cart, checkout, purchase, identify).
• Anonymous-to-known stitching at your observed rate, including a person arriving on a second device.
• Late, duplicate and out-of-order events, and a small share of malformed payloads.
• Bot-like bursts from few identifiers.
• Seeded randomness, so a failing run can be repeated exactly.

Profiles

Performance depends on store size, so pre-load profiles before the test: the full production count, or at least 10 times the active set. Include merged identities, a range of consent states (including opt-outs) and segments that overlap. Use synthetic personal data only; never copy production personal data into a test environment. Where you need realistic structure, generate it. The synthetic-data proof of concept guide covers generators in more depth.

Open, not closed, load

Choose an open model: arrivals at a fixed rate regardless of how fast the system answers. k6's documentation explains that in a closed model new iterations begin only when previous ones finish, so when the system slows, the arrival rate tapers off and the test under-loads exactly when it should push hardest, the problem known as coordinated omission. Its arrival-rate executors (constant-arrival-rate and ramping-arrival-rate) implement the open model 1.

Scenarios

Destination limits are real constraints

A related point from practitioners: stateless pipelines without replay lose data when a destination is down, which is one reason teams look for platforms that retain events and can replay them 3.

Metrics and pass criteria

Thresholds below are examples to adapt from your business objectives; they are not industry standards.

Record percentiles, not averages, and keep the raw histograms. Messaging benchmark tools report latency in windows (the OpenMessaging framework, for example, reports average, 50th, 99th and 99.9th percentiles per 10-second window plus a final aggregate) 4.

Tooling

Environment and hygiene

Checklist

1. Derive peak events per second, burst factor, profile count and destination list from real logs.
2. Define pass criteria in business terms before testing.
3. Build seeded generators with realistic skew, stitching and noise.
4. Pre-load profiles at production scale with synthetic personal data.
5. Use open-model arrival rates.
6. Mock every destination with its documented limits.
7. Run S1 to S8, at 1x, 2x and 3x where relevant.
8. Reconcile produced, stored and delivered counts after every run.
9. Record percentiles and keep raw histograms.
10. Run each scenario three times and compare.
11. Fix, then re-run; keep a regression suite.
12. Schedule the full plan before each peak and after major releases.

For the architecture being tested, see customer data platform architecture and real-time decisioning; for suppression design, see consent withdrawal across channels. Reference deployments are in CDP on AWS, Azure and GCP.

---