AEP Streaming Throughput: What Product Owners Need to Know
Most teams discover the 1,500 RPS guardrail too late. They find it during a load test, a flash sale, or when real-time personalisation stops working.
This post explains how streaming throughput works in Adobe Experience Platform (AEP) and what decisions you need to make about it.
What Is Streaming Throughput?
Every customer action that your website or app tracks generates an event. Examples: a page view, adding an item to a cart, a purchase, a loyalty scan.
Each event is sent to AEP as a request. Streaming throughput is how many of these requests AEP can process per second (RPS) and write into customer profiles.
The limit for the profile update path is 1,500 RPS.
Two Paths, Two Limits
AEP handles streaming data in two different ways, depending on whether a dataset is "profile-enabled":
| Path | What it does | Limit |
|---|---|---|
| Data lake only | Stores raw events for reporting and analysis (e.g. in CJA) | ~4,000-5,000 RPS |
| Profile-enabled | Updates live customer profiles and evaluates audience membership in real time | 1,500 RPS |
The profile-enabled path does more work. When an event arrives, AEP merges it into an existing customer profile, checks which audiences the customer now belongs to, and makes the updated profile available for activation. All of this happens in near real time, which is why the limit is lower.
The 1,500 RPS limit only applies to the profile-enabled path. A dataset that is only used for analysis does not need the profile toggle, and its traffic does not count against the limit.
What Counts Against the 1,500 RPS Limit
The limit applies at the organisation level. It is the combined total across all your profile-enabled sources, not per source individually.
Sources that count:
- Website (Web SDK) - page views, clicks, add-to-cart, checkout events. High-traffic events like a flash sale can push this up sharply.
- Mobile App (Mobile SDK) - app sessions, screen views, purchases, push notification opens. Mobile traffic often peaks at different times from web, especially for consumer apps in the evening.
- Streaming Connectors - server-to-server feeds from systems like Kafka, Azure Event Hubs, Kinesis, CRM, or point-of-sale (POS). Bulk exports from these systems at a scheduled time can create short, sharp spikes.
- Edge Network Server API - events sent directly from a back-end server, used when a browser or mobile SDK is not available.
Sources that do not count:
- Batch file imports (nightly files from cloud storage or SFTP)
- Data going into non-profile-enabled datasets
- Adobe Analytics data via the Analytics Source Connector (processed separately)
The Profile Toggle
The 1,500 RPS limit only applies because of one setting: enabling a dataset for Real-Time Customer Profile.
When this toggle is on, AEP treats every incoming event as an instruction to update a live customer profile. That is why it has a tighter limit.
For Product Owners: Not every dataset needs the profile toggle. If a dataset is only used for historical reporting in Customer Journey Analytics (CJA), leave it off. Turning it off on datasets that do not need real-time updates is one of the most practical ways to reduce throughput consumption without losing any data. This should be a deliberate decision in your implementation design, not the default.
What Happens When You Exceed the Limit
The 1,500 RPS limit is a soft guardrail, not a hard cutoff. AEP does not drop data, but performance will degrade:
| What happens | Business impact |
|---|---|
| Profile update latency | A purchase may not suppress a cart abandonment email fast enough |
| Audience evaluation delays | A customer who just qualified for an offer may miss the real-time trigger |
| Audience evaluation paused | In a sustained overload, AEP may temporarily stop evaluating real-time audiences |
| Activation impact | Website personalisation, email suppression, and ad audience updates may deliver the wrong experience |
Adobe's documentation states: "If you exceed your streaming throughput, you will experience performance latency in your ingestion and segmentation."
Adobe is not responsible for performance issues when a guardrail is exceeded. Customers who consistently go over the limit may need to purchase additional capacity.
Peaks Matter More Than Averages
The daily average RPS is rarely the problem. The risk comes from peaks, where events cluster in a short window and push the combined total over 1,500 RPS.
Common peak triggers for Australian businesses:
- After-work evening (7-9 pm AEST) - website and mobile traffic peak at the same time
- Lunch break (12-1 pm AEST) - engagement across both web and app
- Flash sales and product launches - traffic can spike 5-10x the daily average within minutes
- Scheduled connector exports - a CRM or POS system that sends a bulk of transactions at a fixed time creates an artificial spike
Plan for your worst-case peak hour, not your yearly average.
Practical Reference
These are rough estimates to give a sense of scale:
| Scenario | Estimated peak RPS | Risk level |
|---|---|---|
| Small online store (50k daily visitors, web only) | 20-80 RPS | Low |
| Mid-size retailer (web + mobile + POS connector) | 200-600 RPS | Low to medium |
| Large media platform (high engagement events) | 800-1,400 RPS | Approaching the limit |
| Large e-commerce site during a flash sale | 2,000-5,000 RPS | Exceeds limit without extra capacity |
| Enterprise telco or financial services (multiple feeds) | 1,000-8,000 RPS | Requires capacity planning |
Actual numbers depend on event volume, how many events fire per session, and how many datasets have the profile toggle on.
The Limit Can Be Increased
The 1,500 RPS baseline is not a fixed ceiling. Adobe offers additional streaming segmentation capacity of up to 13,500 RPS extra, which would bring the total to 15,000 RPS. This is a commercial discussion with your Adobe account team.
Estimate Your Peak Before You Go Live
It is worth modelling your expected peak RPS before your implementation goes live, using your known traffic patterns and source volumes. That way, you avoid finding out in production.
AEP Peak Streaming Throughput EstimatorKey Takeaways
- The 1,500 RPS limit is shared across all profile-enabled sources in your organisation. Plan for the combined peak, not each source on its own.
- The limit only applies to datasets with the profile toggle on. Datasets used only for analysis do not need it.
- Peak hours matter more than daily averages. Size for your worst case.
- Going over the limit delays personalisation and audience updates. Data is not lost, but timing is affected.
- Additional capacity is available if your workload needs it.