Skip to content
SAP, DATEV and Dynamics experts

APIs, middleware & architecture

Whether point-to-point connections or a central middleware — the architecture decides how expensive the tenth integration becomes. This category sets out the options: direct interfaces, queues and event-driven transfer, scheduled synchronisation, data mapping and transformation, interface versioning, and monitoring and retrying failed transfers. We explain when a dedicated integration layer pays off, which logging and traceability requirements are sensible and how to limit dependencies on individual providers. Documentation is part of it too: without described data flows, every later change becomes a risk — no matter how cleanly the first implementation was built. We also show which metrics describe the state of an integration — from the number of pending queue items to the duration of a full synchronisation.

Event-Driven Architecture with a Message QueueEvent SourcesShop: orderShop: paymentERP: stockMessage Broker / Queuedecouples source and target1234Order per partition (FIFO)ACK / CommitRetry + BackoffConsumersERP orderAccountingWarehouse syncpublishsubscribeDelivery ResilienceAt-least-onceIdempotency keyOrder preservedLoad bufferFailure PathDead Letter Queueafter retries exhaustedAlerting + replayno silent data lossMarket Dynamics17.6%queue market growth p.a.90%large firms real-time 202513%mature EDA adoption

Event-Driven Architecture and Message Queues

How events and message queues enable decoupled, resilient shop integrations: retry, partitioned ordering, idempotency and the dead letter queue explained.

14 min read
Idempotency and Retry StrategiesStoreOrder + KeyIdempotency StoreKey known?Dedup checkRetry EngineBackoff + Jittermax 5 attemptsERP / SAPTarget systemSafe retry with exponential backoffAttempt 1after 1sAttempt 2after 2s + jitterAttempt 3after 4s + jitterAttempt 4after 8s + jitterAttempt 5after 16s + jitterSuccess: key marked as processedlater duplicates are ignoredDead Letter Queueafter max attemptsmanual clarificationAt-least-once deliveryEvery message arrives at least once,possibly several times. Duplicates areallowed and removed by the receiver.Idempotency makes the receiverimmune to repetition.Deduplication in the storeThe idempotency key is stored beforethe order goes to the ERP. If the samekey arrives again, the result of thefirst call is returned.No duplicate orders in the ERP.

Idempotency and Retry Strategies for Robust Interfaces

Idempotency keys, exponential backoff with jitter and dead letter queues: how to make order and inventory syncs between store and ERP safely repeatable.

13 min read
Webhooks vs. Polling in the Shop-to-ERP Data FlowEvent-driven (Webhook)ShopEvent: order placedERP ReceiverHTTPS POST + HMACPush200 ACKRequest-based (Polling)ERP Clientasks on intervalShop APIGET since timestampGETdelta listSecuring DeliveryAcknowledgement (2xx)Retry + BackoffIdempotency KeyDead Letter QueueSecuring the Webhook RouteHMAC-SHA256 signatureTimestamp vs. replayIP allowlistmTLS optionalVerify signature in constant timeChoosing per Data FlowOrder shop to ERP: Webhook (seconds)Inventory ERP to shop: Webhook + delta syncMaster-data backfill: polling on intervalComparison at a GlanceLatencysec.Webhook near real-timeAPI Loadlowpush not constant pollPoll Interval1-5minutes as safety netRobusthybridpush plus reconcile

Webhooks vs. Polling: Event-Driven Shop Integration

Webhooks or polling for shop-to-ERP integration? A comparison of latency, delivery guarantees, HMAC security and resilience with practical recommendations.

13 min read