A company wants warehouse data pushed back into operational systems. What are the design considerations, and what should not go through this path?

The legitimate use

Pushing derived, aggregate or enriched data into operational tools — a customer's lifetime value into the CRM, a computed segment into the marketing platform, a supplier reliability score into the procurement system.

The warehouse is where the computation is easy and the operational system is where the data is used, and copying is simpler than reimplementing the computation.

The design considerations

• Freshness expectations must be explicit. The data is as fresh as the warehouse pipeline, which is typically hours. A consumer treating it as current makes decisions on stale information, and the staleness must be visible in the destination rather than assumed.
• Idempotency, since the sync will run twice and the destination must not double-apply.
• Per-destination isolation: rate limits, retry policy and error handling per target, since a CRM and a marketing platform have nothing in common operationally.
• A record of what was pushed and when, because the destination will diverge and reconciliation is the only way to detect it.
• Change-only pushes, since pushing everything on every run exhausts the destination's API quota and is the most common cause of these integrations failing.

What should not go through this path

• Anything on a transactional decision path. A credit limit, an authorisation decision, an inventory reservation — these need a system of record with transactional guarantees, not a copy that is hours old and eventually consistent.
• Anything where the warehouse is not authoritative. Pushing a value back that the operational system also computes creates two authorities for one fact and produces permanent reconciliation work.
• High-frequency operational events, which belong in a stream rather than in a batch push.

The architectural smell to watch for

Reverse ETL used to work around a missing service. If an operational system needs a computed value in real time, the answer is a service that computes it, not a nightly copy — and the copy is chosen because it is faster to build.

That shortcut is acceptable as an interim step and becomes load-bearing quickly, so the decision should be recorded with a trigger for revisiting it rather than being made implicitly.