Between the backbone and the systems it connects sits the glue: translators, connectors, schedulers, orchestrators. This page maps the open-source toolbox by job, because the failure mode in this space is picking a tool and then finding jobs for it. Licensing is annotated throughout — this category is where "open source" claims most often have asterisks.
Apache Camel (Apache-2.0) is the integration pattern vocabulary as a library: routes declared in Java/YAML DSLs, 300+ endpoint components (SFTP, AMQP, Kafka, HTTP, files…), with content-based routing, splitters, aggregators, and translators as first-class constructs. It is the strongest answer where integration logic is genuinely complex and deserves to be code — tested, versioned, deployed like any service (standalone, Spring Boot, or Quarkus/Kubernetes via Camel K). A JVM commitment, and easy to over-adopt for jobs a plain consumer service would do — but for the EDI-file-to-canonical-order translation service in ThirdPartyLogisticsIntegration, it is precisely the right shape.
Heavier stateful stream processing (windowed aggregations, joins) is a different job class — see StreamProcessingEngines.
Apache Airflow (Apache-2.0) owns scheduled DAGs: the nightly reconciliations, ERP batch postings, marketplace feed submissions, EDI pickup schedules. Right tool when the unit of work is "run this pipeline at 02:00 and alert if step 3 fails"; wrong tool for event-driven or per-order flows (its scheduler granularity and operational weight fight you). Lighter alternatives for smaller stacks: Prefect and Dagster (both open-core Python schedulers, lighter local stories), or honestly — at garage tier — cron plus a script that reports failures somewhere a human looks. The graduation trigger is dependency complexity between jobs, not job count.
Covered in depth in OrderOrchestrationAndSagas: Temporal (MIT) for long-running, stateful, compensating business flows — the order saga, the returns flow, supplier onboarding. The boundary against Airflow is worth stating: Airflow schedules data pipelines on clocks; Temporal executes business processes on events, durably, per entity. Stacks that conflate them end up running order logic in a batch scheduler, which works right up until someone asks about one specific stuck order.
Low-code flow builders have a real niche — the long tail of small automations (Slack alerts on big orders, sheet exports for ops, webhook glue for tools that don't matter architecturally):
The standing rule for this whole layer: nothing load-bearing lives in a visual flow tool. The moment a flow touches order state, money, or inventory truth, it graduates into owned code (Camel route, consumer service, Temporal workflow) with tests and version control.
| Tier | Kit |
|---|---|
| Garage | cron + scripts; maybe Node-RED/Bento for glue; everything else is your application |
| Growth | Bento/Camel for translation services; Debezium where CDC is needed; a scheduler when cron dependencies tangle |
| Enterprise | Camel translation services + Kafka Connect/Debezium fabric + Airflow batch estate + Temporal for the order saga |
The meta-rule across tiers: every tool here is a host for integration logic — the logic itself (canonical models, translation rules, routing policy) is yours, versioned, and portable between hosts. Choose tools you can walk away from.