Supplier Integration Platform Low-Level Design: EDI/API Connector, Order Sync, and Catalog Feed

What Is a Supplier Integration Platform?

A supplier integration platform connects an e-commerce or manufacturing system to external supplier systems via EDI or REST/SOAP APIs. It handles outbound purchase orders, inbound order acknowledgements and shipment notifications, catalog feed ingestion, and error recovery — presenting a uniform internal interface regardless of each supplier protocol.

Requirements

Functional Requirements

Send purchase orders to suppliers over EDI X12 850 or REST API, based on per-supplier configuration.
Receive order acknowledgements (EDI 855), advance ship notices (EDI 856), and invoices (EDI 810).
Ingest supplier catalog feeds (CSV, XML, or JSON) to update product data and pricing.
Sync order status back to the purchase order service in near real-time.
Handle transient supplier failures with configurable retry and dead-letter escalation.

Non-Functional Requirements

Each supplier connection must be isolated so a failure in one does not affect others.
Message delivery must be at-least-once with idempotent processing on the receiving end.
Catalog ingestion must process files of up to 500,000 rows within one hour.

Data Model

supplier: supplier_id, name, integration_type (EDI, REST, SFTP), endpoint_config (JSON), auth_config (encrypted JSON), active.
outbound_message: message_id, supplier_id, message_type (PO, CANCEL), payload (raw EDI or JSON), status (PENDING, SENT, ACKED, FAILED), attempts, last_error, created_at, sent_at.
inbound_message: message_id, supplier_id, message_type (ACK, ASN, INVOICE), raw_payload, parsed_payload (JSON), processed, received_at.
catalog_feed_run: run_id, supplier_id, file_url, status (QUEUED, PROCESSING, DONE, FAILED), rows_total, rows_processed, errors, started_at, finished_at.

Core Algorithms

Connector Abstraction

Each supplier has a connector class that implements a common interface: send(message), poll(), and parse(raw) -> InternalEvent. The platform resolves the correct connector at runtime using the supplier record integration_type. Adding a new supplier requires only a new connector implementation and a config row — no platform code changes.

Outbound Retry with Exponential Backoff

Failed outbound messages are re-queued with a delay of min(2^attempt * base_delay, max_delay). After a configurable maximum attempts (default five) the message moves to a dead-letter queue and an alert fires. An operator can inspect the raw payload, correct the issue, and requeue. Each retry checks whether the supplier has already acknowledged the message (idempotency check using the internal message_id sent as a reference field).

Catalog Feed Ingestion Pipeline

The pipeline uses a streaming parser to avoid loading large files into memory. Each row is validated against a supplier-specific schema (required fields, data types, price range sanity checks). Valid rows are batched into groups of 500 and upserted into the product catalog. Invalid rows are written to an error log. At completion a summary is posted to the catalog_feed_run record and a webhook notifies the catalog team.

Inbound Message Deduplication

Suppliers sometimes resend the same EDI document. The platform hashes the raw payload and checks a recent-message bloom filter before full processing. On a bloom filter hit it performs an exact lookup in inbound_message by supplier_id and payload hash. If a match is found the message is acknowledged but not reprocessed, preventing duplicate stock receipts or invoice payments.

API Design

POST /suppliers/{supplier_id}/purchase-orders — enqueues an outbound PO message; returns message_id.
GET /suppliers/{supplier_id}/messages?type=ACK&since=timestamp — lists inbound messages for status sync.
POST /catalog-feeds — triggers ingestion of a file URL for a given supplier.
GET /catalog-feeds/{run_id} — returns feed run status and error summary.
POST /dead-letter/{message_id}/requeue — operator action to requeue a failed message.

Scalability and Reliability

Per-Supplier Queues

Each supplier has a dedicated outbound queue and a dedicated worker pool. This provides isolation: a slow or unresponsive supplier only backs up its own queue. Queue depth metrics per supplier trigger autoscaling of worker instances and alert on abnormal growth.

EDI Translation Layer

Raw EDI X12 is parsed into a canonical internal JSON format by a stateless translation service. This decouples the rest of the platform from EDI specifics. Updates to EDI segment handling (new trading partner requirements) are confined to the translator with no downstream changes needed.

Catalog Feed Parallelism

Large catalog files are split into chunks (by byte range for CSV) and processed in parallel across worker nodes. A coordinator tracks chunk completion and merges error logs. This achieves horizontal scalability and allows partial restarts — only failed chunks are reprocessed on a retry.

Trade-offs and Interview Discussion Points

EDI versus REST: EDI is still the standard for large retail suppliers (especially grocery and wholesale). REST connectors are simpler but many established suppliers only offer EDI. The abstraction layer means the platform supports both without compromising the internal API.
Push versus poll for inbound messages: REST suppliers can push webhooks for low latency; EDI suppliers are typically polled on a schedule. The platform handles both models in the connector interface.
Synchronous PO submission versus async queue: synchronous submission gives immediate confirmation but couples the platform to supplier uptime. The async queue with retry is more resilient but adds latency before the supplier receives the order.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How do you abstract EDI and REST into a single supplier connector interface?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Define a SupplierConnector interface with methods like sendOrder(), getOrderStatus(), and streamCatalog(). Implement an EDIConnector that wraps AS2/SFTP file exchange and an RestConnector that calls HTTP endpoints. A ConnectorFactory selects the implementation based on supplier configuration, so the rest of the system is transport-agnostic.”
}
},
{
“@type”: “Question”,
“name”: “How do you keep order status in sync between your system and a supplier?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Use a dual approach: the supplier pushes status webhooks or EDI 855/856 messages that are ingested into an event stream, and a reconciliation job polls supplier order status APIs on a schedule for any orders that haven't received an update within an SLA window. Both paths write to the same order-status table with an idempotency key to prevent double-updates.”
}
},
{
“@type”: “Question”,
“name”: “How do you ingest a streaming catalog feed from a supplier?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Consume the feed (SFTP batch file, Kafka topic, or chunked HTTP stream) via the connector abstraction and write records to a staging table. A pipeline then diffs staged records against the live catalog using SKU as the natural key, upserts changed rows, and publishes a catalog-updated event so downstream services like search indexing can react without polling.”
}
},
{
“@type”: “Question”,
“name”: “How should a supplier integration service handle errors and use a dead-letter queue?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Transient errors (network timeouts, 5xx) trigger exponential-backoff retries up to a configured limit. Permanent errors (malformed EDI, 4xx validation failures) are not retried; the message is moved to a dead-letter queue with the original payload and error metadata. An alerting rule fires when DLQ depth exceeds a threshold, and an ops runbook describes how to inspect, correct, and replay messages.”
}
}
]
}