Commerce Integration Hub
A platform for collecting orders from different systems and following their processing, even when requests repeat or a service temporarily stops responding.
The problem
Marketplaces, ERPs and partner systems send orders in different formats. If a response does not arrive, the sending system may submit an order again even though it was already received; the same identifier may also be associated with different data. Integration operators need to know which orders arrived, which had problems and which can be sent again.
What I built
I built a Node.js and TypeScript gateway that receives signed webhooks and collects orders from an API, converting them into a common format. A service written in Kotlin with Quarkus stores orders in PostgreSQL and processes them asynchronously by consuming events published to Kafka.
The React console lets operators search for orders, follow their history and inspect gateway delivery attempts. When a delivery has exhausted its automatic attempts, an authorized administrator can request another attempt if the connector is active and the required data is still available. The request and its outcome are recorded.
An interactive architecture map lets visitors explore the components, their connections and the related technical documentation.
The path of an order
Design decisions
Separate external protocols from the order model
The gateway verifies signatures, converts data and retrieves orders from external APIs. The core service checks orders for consistency, identifies duplicates and conflicts, and manages their state during processing. The two services communicate through an HTTP API and use separate databases.
Handle duplicate requests
The system identifies a previously received order by its source system and external ID. If the data matches, it treats the request as a duplicate; if the data differs, it reports a conflict without overwriting the existing order. The order and the event to be published are saved in the same transaction, so every newly accepted order has an event ready to be sent to Kafka.
Follow processing and investigate failures
Order history, delivery attempts, metrics and tracing help show how processing is progressing and where failures occur, including when work resumes after an interruption.
Keep the search index rebuildable
PostgreSQL stores the authoritative order data. OpenSearch holds a projection used for operational search, which can be rebuilt from the data in PostgreSQL.
Status and limitations
The project can be run locally with simulated external systems and synthetic data. OpenTelemetry tracing is optional, and traces can be viewed in Jaeger. Performance under load has not been measured.