MCP Catalog Feed Orchestration: Idempotent Updates Without Regression

A Marketing Cloud Personalization catalog is a living object. New products arrive, prices change, inventory turns over, descriptions get edited. The orchestration layer that pushes those changes into MCP is the single most fragile part of the implementation, and the place where catalogs silently regress over months without anyone noticing until recommendation quality has visibly degraded.

Five orchestration patterns separate catalogs that stay healthy from catalogs that decay.

1. One source of truth per attribute

Every attribute on every catalog item should have exactly one upstream system that owns it. Not "primarily" one. Exactly one.

The failure mode looks like this. The PIM owns product titles, descriptions, and category. The e-commerce platform owns price and inventory. Both push to MCP via separate jobs. The PIM job runs at 02:00. The e-commerce job runs every 15 minutes for inventory updates. At 02:14, both jobs are touching the same catalog rows. The e-commerce job sets price to $19.99. The PIM job has stale price data and overwrites it with $24.99. The actual price on the storefront is still $19.99 but MCP recommends with $24.99. Filters on price ranges break. Faceted experiences misfire.

The discipline is to inventory every attribute and assign exactly one owner. Whichever system owns an attribute is the only system that pushes that attribute to MCP. Other systems either omit the attribute from their feed or are excluded from the catalog feed entirely.

A spreadsheet with three columns (attribute, owner system, update frequency) prevents most of these bugs. Sapota produces this artifact in the first week of every catalog engagement.

2. Idempotent feeds, always

A feed is idempotent if running it twice produces the same end state as running it once. Real production feeds run twice constantly: retries on partial failure, manual reprocess after a bad data load, recovery from upstream outage.

A feed that is not idempotent does subtle damage on retry. Fields get reverted. Attributes get duplicated. Items get unintentionally re-introduced after a soft delete. By the time the recommendation degradation is noticed, the actual cause is buried under three weeks of subsequent feed runs.

The test for idempotency is simple. In a staging environment, run the feed three times in a row with the same input data. Compare the catalog state after each run. If anything differs across runs, the feed is not idempotent and will misbehave in production.

For most teams, the practical fixes are:

• Use full-snapshot feeds where possible. Each run sets the entire catalog state from scratch.
• For delta feeds, derive the delta from a stable diff against the upstream snapshot, not from event streams that may replay.
• Avoid timestamp-driven incremental updates that depend on "modified since." Clock skew between systems eventually causes drift.

3. Stop using the API for what the feed should do

A common pattern: the e-commerce platform fires a real-time API call to MCP every time a product is updated. The intent is "push everything in real time." The result, for catalogs above a few thousand items, is rate-limit errors, partial updates, and a catalog that drifts out of sync with the e-commerce truth state.

The right pattern, for catalog data, is a scheduled feed. Twice daily, or hourly for fast-moving inventory, but bounded. Real-time API push is reserved for the few attributes that genuinely change quickly enough to matter for the visitor seeing the page right now: stock status, dynamic price.

For everything else (descriptions, images, categories, brand), nightly feed is more than enough. Trying to push every edit in real time guarantees the system drifts.

The corollary: when both feed and API push exist, the feed wins on the attributes it owns. The API push is allowed only for the explicitly defined real-time set.

4. Schema migrations need a freeze window

Adding an item type, restructuring a related catalog, splitting one attribute into two, all of these are schema migrations. They require coordinated changes in the upstream system, the feed transformer, and MCP itself.

Running a schema migration while the regular feed is still running invariably produces split-brain catalogs: half the items in the new schema, half in the old, recommendations that span both. Affinity learning gets confused. Recipe filters partially apply.

The pattern that works is a freeze window. Stop the regular feed. Run the migration. Verify the catalog state in MCP is consistent. Restart the feed against the new schema. The freeze can be 30 minutes for small migrations or several hours for restructures, but it is always shorter than the time spent untangling a split-brain catalog after the fact.

For high-traffic sites that cannot tolerate a freeze on inventory updates, the workaround is to run the schema migration in a parallel staging catalog, validate, then swap. More effort, but no production drift.

5. Monitor the catalog like production data

Most teams monitor the feed job itself. Did it run? Did it complete without errors? Those are necessary but not sufficient. The feed can run cleanly and still corrupt the catalog if upstream data is bad.

The monitoring that catches real problems is on the catalog state itself:

• Item count. A 5 percent drop in catalog size between runs warrants a check. The cause is usually an upstream filter that excluded items the catalog needs.
• Attribute coverage. Every required attribute should be populated on every item. A drop from 100 to 90 percent coverage on the category field means something upstream stopped emitting it.
• Price ranges. The min and max price should not change by orders of magnitude run to run. A sudden $0.00 minimum usually means decimal-handling broke somewhere upstream.
• Stock-status distribution. The fraction of in-stock items should not swing wildly between runs.

Set thresholds on these. Alert when they breach. Fix the upstream issue before the bad data trains the recommendation model on noise.

A practical orchestration sequence

The order that produces healthy catalogs over time:

1. Document attribute ownership (one owner per attribute). Lock in writing.
2. Build the feed transformer with idempotency tests in CI.
3. Schedule full-snapshot feeds for non-urgent data, restrict API push to the real-time set.
4. Define the freeze window protocol for schema migrations and write it into the runbook.
5. Add catalog state monitoring with explicit thresholds and alert routing.

Catalog orchestration is the part of MCP implementation that gets the least attention during scoping and consumes the most operational time after go-live. Treating it as a real engineering surface, with idempotency tests and monitoring, separates programs that stay sharp from programs that quietly decay. Sapota's Salesforce team builds catalog orchestration as an explicit deliverable on every Personalization engagement, because it is invariably where the avoidable damage happens.

---

Auditing or building catalog orchestration for Marketing Cloud Personalization? Sapota's Salesforce team handles feed design, attribute ownership mapping, and catalog monitoring on production engagements. Get in touch ->

See our full platform services for the stack we cover.