Middleware that keeps your systems reliably connected
In system landscapes with ERP, shop, PIM, CRM and accounting, a central middleware orchestrates every data flow — asynchronous, resilient and scalable. It replaces error-prone point-to-point connections with a maintainable architecture.
GoBD
compliant document handover
< 60 s
typical sync latency
6
connections instead of 15
50+
integration projects
Effort-based · net plus VAT
- Fixed-price package after analysis instead of an open estimate
- Message-queue core with retry and dead-letter queue
- Central routing, mapping and error handling
- Monitoring of your data flows well beyond go-live
Middleware is custom development: after a free system analysis we calculate your project as a binding fixed-price package based on the project day. Extensions and operation on a time basis at 119 € per hour net. License costs for message brokers or cloud infrastructure are shown transparently and separately. The project day is a package price for a reserved working day and therefore deliberately not a multiple of the hourly rate — the rationale is on the pricing overview.
When two systems communicate, a direct API connection often suffices. But as soon as three, four or more systems are involved, dedicated middleware becomes indispensable. Without central orchestration, point-to-point connections emerge that grow exponentially complex with each new integration. Our middleware solutions serve as central hubs: they receive data from source systems, transform it into target formats and reliably distribute it to all connected systems, even when individual recipients are temporarily unavailable.
Anatomy of the middleware: every data flow in one place
Why middleware is indispensable in e-commerce integrations
From point-to-point to hub-and-spoke
The typical system landscape of a mid-market retailer comprises at least four systems: shop, ERP, accounting and a PIM system. Without middleware, each system would need to communicate directly with every other, resulting in six bilateral connections for four systems and fifteen for six systems. Each connection must be developed, tested and maintained. Middleware reduces this complexity: each system communicates only with the central mediator. With six systems that means six connections instead of fifteen, and a new system requires only a single new connection.
- Complexity grows linearly instead of quadratically
- A new system needs only one connection
- Central routing, transformation and error handling
Core functions of our middleware solutions
Message Routing
Messages are rule-based routed to the correct target systems. Content-based routing enables distribution based on message content: product updates go to the shop, invoice data to DATEV, stock changes to warehouse management.
Data Transformation
Data formats are automatically converted between source and target systems. XML to JSON, different date formats, unit conversion, currency conversion and field-level mapping rules are centrally managed in the middleware.
Error Handling and Retry
Circuit breaker pattern for controlled interruption during system outages. Retry strategies with exponentially growing wait times. Dead-letter queues for messages that could not be delivered after defined attempts.
Persistent Message Queues
Messages are persistently stored before forwarding to target systems. Even during a complete system outage, no data is lost. After recovery, all pending messages are automatically delivered.
Monitoring and Dashboards
Real-time monitoring of all message flows: throughput, latency, error rate and queue depth. Configurable alerts notify on anomalies. Historical metrics enable capacity planning and trend analysis.
Horizontal Scaling
The middleware scales horizontally with growing data volume. Additional worker processes handle more messages in parallel. Clustering ensures availability even when individual nodes fail.
Architecture patterns for different integration scenarios
Depending on system landscape complexity and latency and data volume requirements, we employ different architecture patterns. The following three patterns cover the most common scenarios in our e-commerce integration projects.
Hub-and-Spoke
Classic integration pattern: all systems communicate via the central middleware. Ideal for landscapes with three to six systems where the middleware centrally manages routing, transformation and error handling.
Event-Driven Architecture
Systems publish events on data changes, processed by interested consumers. Publish-subscribe pattern for maximum decoupling. Ideal for highly dynamic scenarios with many parallel data flows.
Microservices Integration
For complex transformation logic, we use specialized microservices: one for SAP communication, one for pricing calculation, one for DATEV preparation. Orchestration via a central message queue.
Dead-letter handling: What happens when things go wrong
In distributed systems, errors are not the exception but the rule. Network interruptions, timeouts, malformed data and temporary system outages occur regularly in daily operations. The question is not whether errors occur, but how the system handles them. Our middleware handles every error case in a defined, traceable sequence.
Transient error
Network timeouts or brief unavailability are handled by automatic retries with exponentially growing wait times. Most errors resolve themselves this way.
Circuit breaker
When a target system is unreachable for longer, the circuit breaker activates and prevents the queue from being flooded with unsuccessful delivery attempts.
Dead-letter queue
After a configurable number of attempts, the message moves to the DLQ, including the original message, error descriptions, timestamps and target information.
Analysis and reprocessing
Via a management interface, administrators analyze failed messages, fix the root cause and release them for reprocessing. Reports escalate at critical thresholds.
Technology stack of our middleware solutions
RabbitMQ
Proven message broker with support for persistent messages, flexible routing topologies (Direct, Topic, Fanout), clustering and management API. Our preferred choice for most e-commerce integrations.
Redis Streams
For scenarios with extremely high throughput and low latency, we use Redis Streams as a lightweight alternative. Consumer groups enable parallel processing with at-least-once delivery.
Node.js Workers
Asynchronous event processing in Node.js for maximum throughput in I/O-intensive operations. Type-safe implementation with TypeScript, comprehensive test coverage and containerized deployment.
Modular architecture protects your investment
The middleware is the connecting piece between all integration components. It consumes the REST and GraphQL APIs of connected systems, orchestrates data flows and delivers normalized data to all target systems. In our projects, it works closely with the ERP connectors for SAP and Dynamics 365, the DATEV interface and the shop adapter.
Components stay replaceable
Observability: Complete insight into every data flow
In a middleware architecture, observability is not optional but a necessity. When data flows through multiple processing steps, it must be traceable at all times where a message is, how long processing took and whether errors occurred. We implement a three-level observability concept.
Metrics
Throughput, latency, error rate and queue depth at queue and endpoint level, visualized in real-time dashboards for the operations and business teams.
Logs
Every processing step is documented with context: message content, source and target system and all transformation steps.
Traces
End-to-end tracking of a single message through all processing stages, for fast error diagnosis and root cause analysis.
The operations team sees queue depth, processing time and error rate, while the business department sees the number of synchronized products, orders and invoices per period. Configurable alerts automatically notify when queue depth exceeds a threshold, the error rate increases or processing time exceeds a critical value.
What middleware development costs
Middleware is custom development and is calculated based on effort. After a free system analysis you receive a binding fixed price for your project. All prices net plus VAT.
System analysis
We review your system landscape and data flows.
- Capture of all source and target systems
- Assessment of data flows and criticality
- Recommended architecture pattern
- Binding fixed price for the project
Middleware development
Build-out of the middleware as a fixed-price package after the analysis.
- Message-queue core with retry and dead-letter queue
- Routing, mapping and transformation layer
- Monitoring, logs and traces
- Load test and go-live support
Operation & extension
New data flows and ongoing adjustments on a time basis.
- Additional systems and data flows
- Adjustment of mapping rules
- Support after go-live
- Project day 990 € net for larger expansion stages
Middleware projects are calculated as a fixed price based on the project day of 990 € net; individual extensions on a time basis at 119 € per hour. License costs for message brokers or cloud infrastructure are shown transparently and separately. The scope becomes binding after the free system analysis.
Does your system landscape need middleware?
We analyze your systems and data flows and identify whether and what type of middleware delivers the greatest benefit.
Migrating existing integrations without downtime
Many companies already have organically grown point-to-point integrations in use that work but are difficult to maintain and diagnose. Migration to a middleware architecture proceeds step by step: we start with the most critical data flow, implement it via middleware and deactivate the direct connection only once the new integration delivers identical results.
- 1
Inventory
We map all existing data flows, formats and dependencies and prioritize by business criticality.
- 2
Parallel operation
Old and new integrations run simultaneously. Results are compared so no data is lost at any point.
- 3
Gradual cutover
One data flow after another is migrated to the central architecture, ongoing operations remain uninterrupted.
- 4
Decommissioning legacy connections
Only once the new integration verifiably delivers identical results are the direct point-to-point connections deactivated.
Scaling, performance and security
B2B integrations frequently process large data volumes: thousands of product master records with prices and stock levels, hundreds of orders per hour during peak times, complex price configurations with customer-specific terms. Message-queue-based processing enables horizontal scaling, batch processing optimizes large datasets and caching reduces redundant API calls. This keeps the architecture stable even during seasonal order surges or ERP mass imports.
- Encryption in transit and at rest for all data movements
- Granular access controls and complete audit logs
- GDPR-compliant data processing and traceable audit trails
- Automated contract tests detect breaking changes before go-live
- Quarterly reviews of data quality, performance and error rates
- Security architecture adapted to individual compliance requirements
Every transaction is traceable, every error diagnosable, every change documented. That is the foundation for an integration that works not only at go-live but remains maintainable years later.
Frequently asked questions about middleware
Our technical articles show how middleware works in operation: REST API or Middleware delineates both approaches, Event-Driven Architecture and Message Queues describes asynchronous decoupling, and Idempotency and Retry Strategies explains why a message delivered twice must have no side effects.