Targeting and batching
Create operations at the lowest level of change
If only one field changes on a variant, use an operation that targets that single field, rather than overwriting the entire product. Updating large objects is more expensive than updating small, precise paths.
If you only need to update one field on one variant, patch at /<productId>/variants/<variantId>/fields/<field> to minimize data overhead.
Avoid over-deleting
If you only need to change a single field (for example, updating availability), don't remove the entire product or variant. Overly broad changes inflate processing time and can impact latency.
Combine multiple field updates into a single operation
If you need to change many fields on the same record (for example, add/update 20 fields on one product), it's more efficient to perform one upsert (or add) containing all 20 new/updated fields rather than 20 separate operations. Fewer operations in the patch can reduce processing time.
Batch multiple small changes into a single patch
Rather than sending a patch for each individual change in real time, group changes over a small window (for example, 1-5 seconds) into one patch. This reduces your HTTP overhead and async job processing overhead, resulting in faster overall throughput.
Update strategies
Use full updates sparingly
In many catalogs, a once-a-day full replacement is typical (if needed at all). More frequent full updates can cause large ingestion loads and possible latency spikes.
When performing a full replacement, stick to op: "add" for each product record as it's usually the most efficient approach. Always keep a "full feed" flow ready in case you need to quickly re-sync from scratch.
Keep backup logic for full resync
If your source system gets out of sync with Bloomreach, you can safely resubmit a full update (remove everything, then re-add). This ensures a clean, consistent state.
Use delta updates for incremental changes
For day-to-day incremental changes, do smaller patches with upsert or remove. This is faster than re-sending everything.
Data consistency and monitoring
Ensure consistency if using on_success_trigger
If you set update-items or update-destination-items in your Update Records call, ensure each patch leaves the data in a stable, consistent state. Otherwise, the automatically triggered Items Update could run at a moment that doesn't align with your intended final data state.
Job monitoring
Always capture the job ID from the response. If you suspect problems, retrieving the job details can show error info.
Data size considerations
If your patch is small (under 10 MB), send it inline in the API request body. If it's large (10 MB to 100 MB), consider JSONLines. If larger than 100 MB, upload your patch file via Bloomreach's Get Upload URLs approach.
Performance and latency considerations
Standard usage pattern
A typical, acceptable approach is one full replacement per day (if you need it) plus incremental (delta) changes at the field or variant level throughout the day. The total daily volume of changes should be reasonable relative to your total record size (for example, not exceeding daily volumes on the order of "(number of records) × (updates per record)" at an extreme).
Operation complexity varies
The time to process an operation depends on the amount of data being replaced or removed. For example, deleting a product with hundreds of variants is heavier than removing a single field on a single variant.
No guaranteed latency
Bloomreach can't provide a hard latency guarantee (the time it takes to process your patch). Processing times depend on:
-
The size/complexity of your patch, which varies based on the types of operations used, as well as the number of fields and child records present.
-
The frequency of your updates (bursty vs. steady).
-
Parallel load from your environment.
However, once you establish a consistent integration pattern and measure your baseline processing times, Bloomreach will maintain a stable service level with minimal variation.
Focus on efficient updates
If latency is a concern, first ensure you aren't performing expensive "replace entire product" operations when you only need to upsert or remove a single field. If your approach is already as efficient as possible and you still see higher latency, contact Bloomreach Support for further guidance.