Integration Master Data Management (External)

Reference Data Consumption Flow (Inbound):

1. External System Request: An external application or partner system sends a request (e.g., HTTPS GET/POST) to read or update a reference data entity.
2. Edge Protection (WAF): At the public-facing cloud edge, a Web Application Firewall (WAF) checks for malicious signatures and applies preliminary rate limits.
3. API Gateway: The API Gateway authenticates the external caller (e.g., OAuth 2.0, mTLS), terminates TLS, applies traffic policies (rate limiting, throttling) and routes the request to the MDM integration layer in a Private Subnet (Workloads).
4. MDM Integration Layer: An integration microservice or MDM API endpoint validates the data, applies MDM business rules (e.g., survivorship) and calls the core MDM platform.
5. MDM Core Platform: The Master Data Management system stores, updates or returns the authoritative reference data and enforces its quality and consistency.

Reference Data Distribution Flow (Outbound):

1. MDM Event/Update: The MDM Core Platform detects a change to a critical reference data entity (e.g., new customer, updated product category), or an internal workload requests a data export.
2. Event Streaming Platform / MDM Publisher: For real-time distribution, the MDM platform publishes the change event to a managed Event Streaming Platform (e.g., Kafka-compatible service). For batch or scheduled exports, an MDM publisher service prepares the data.
3. Egress Gateway / Managed NAT: Event streams and API calls to external systems leave through a Managed NAT/Egress Gateway, which enforces outbound FQDN allow-listing, performs network address translation, and applies an egress Web Application Firewall (WAF) to calls to external APIs.
4. External Target System: The external system (e.g., partner application, data warehouse, analytics platform) takes in the updates through its ingestion endpoint (e.g., webhook, API, SFTP via secure gateway).

• Single authoritative source with enforced data quality vs the cost of running and governing a dedicated MDM platform and its stewardship workflows.
• Strong security via mediated APIs and event streams vs added latency and infrastructure from WAF, API Gateway and egress NAT layers on every exchange.
• Real-time distribution through event streaming vs the complexity of idempotency, dead-letter queues and schema versioning across asynchronous consumers.
• Decoupled bidirectional integration vs maintaining versioned OpenAPI/AsyncAPI contracts and survivorship logic as entities change.
• End-to-end observability of the sync lifecycle vs the effort to instrument tracing and metrics across gateway, integration services and streaming tiers.

In this hypothetical scenario, an automotive parts supplier network keeps its authoritative part numbers, supersession chains and supplier locations in a central MDM platform. Distributor and repair-shop portals call an OAuth 2.0-secured API Gateway to check part fitment and enrich SKU records. Their traffic passes a WAF first, then reaches the MDM integration microservice, which applies survivorship rules across competing catalogue sources.

When a manufacturer updates a supersession chain, the MDM core publishes the change to a Kafka-compatible stream. A warehouse inventory system and a tier-one supplier consume it through a webhook and secure ingestion endpoints. Outbound calls to partner ERPs go through a Managed NAT that enforces FQDN allow-listing. Dead-letter queues and idempotency keys mean a duplicated price or supersession update is never applied twice. Distributed tracing across the gateway, integration services and streaming tier covers the whole synchronisation lifecycle, so a stalled update can be traced to the hop where it stopped.

• MDM Style & Interfaces: The MDM style (e.g., Registry, Consolidation, Coexistence, Centralised) decides which integration patterns apply. Expose every interface, for querying, pushing or synchronising data, as a secure, versioned API or event stream.
• Data Quality & Governance: Keep data quality rules, stewardship workflows and survivorship logic in the MDM platform to resolve conflicts and protect data integrity.
• Error Handling & Idempotency: Give every integration point retries, dead-letter queues for asynchronous messages, and idempotency so no update is processed twice.
• Protocol & Format: Use REST/HTTPS for synchronous calls and event streams with structured formats (e.g., JSON, Avro) for asynchronous distribution. Standardise schema definitions (e.g., OpenAPI Specification, AsyncAPI) for every exchanged information object.
• Observability: Collect centralised logs, metrics (latency, throughput, error rates) and distributed traces (e.g., OpenTelemetry) across the API Gateway, MDM integration services and Event Streaming Platform to follow each synchronisation end to end.
• Security by Design: No direct database connections for external access; all data exposure goes through controlled API endpoints or secure event streams.