Open Source Middleware

Middleware is the plumbing nobody notices until a message is lost, stuck, or delivered twice, and because it sits in the critical path between every service, a vague mental model of how it handles ordering, retries, and backpressure turns into outages you cannot reproduce. The tools in this category broker messages, route requests, run durable workflows, and translate protocols - different jobs that make very different promises about what can be lost or replayed. Open source matters because you can read how delivery and durability actually work instead of inferring it from a datasheet, and run the system on your own hardware where you can instrument the queues and watch the failure modes for yourself before they reach production.

20 middleware toolsUpdated July 2026
Showing 1-9 of 20

Our picks

Middleware spans several jobs, so these picks cover streaming, queuing, edge routing, and durable workflows.

Replayable event streaming: Apache Kafka Kafka stores events as an ordered, append-only log, partitioned and replicated across brokers, so consumers can read in real time or replay from an earlier position. Kafka Streams adds stateful stream processing and Kafka Connect moves data in and out of external systems, which makes it a backbone for pipelines rather than a simple queue.

Multi-protocol message broker: RabbitMQ RabbitMQ speaks AMQP, MQTT, STOMP, and its own stream protocol, so producers and consumers can each use what suits them. Quorum queues give a replicated queue tuned for data safety, and streams add a persistent, replayable log with non-destructive reads. Built on Erlang/OTP, it clusters and ships a Kubernetes operator for self-hosted deployments.

Dynamic edge router: Traefik Traefik is a reverse proxy and load balancer that generates routes automatically by watching an orchestrator or service registry, so you rarely configure paths by hand. It updates configuration without restarts, issues Let's Encrypt certificates including wildcards, and handles WebSocket, HTTP/2, and gRPC, with metrics and access logs for visibility.

Durable workflow execution: Temporal Temporal lets you write a long-running process as ordinary code and keeps each execution moving through failures, retries, and restarts while preserving its state. Built-in timers, signals, and automatic retries handle coordination, and a web UI plus CLI let you inspect and operate running and historical executions.

Matching middleware to the interaction it carries

Interaction model matters more than brand here, because middleware that queues jobs, streams records, routes HTTP, or runs a workflow makes different promises about ordering, durability, and retries. Write down which interactions can be lost, delayed, duplicated, or replayed before you compare features. Kafka and Pulsar store events as a durable log you can replay from a position; RabbitMQ and NATS lean toward queue and pub/sub delivery; Temporal and Conductor keep the state of a long-running workflow so it survives crashes. A workflow that cannot tolerate duplicates needs idempotency and clear redelivery behavior, not just a faster broker.

The other half of the category never touches a message queue at all. API gateways and proxies - Traefik, Envoy, KrakenD, and Ocelot - sit at the edge routing, aggregating, and securing HTTP traffic, while Keycloak supplies the identity and tokens they check. Match the deployment shape to the failure modes you can operate: a central broker becomes a core dependency with its own storage and split-brain behavior, whereas a sidecar proxy or a stateless gateway spreads differently when it fails. Ask how nodes discover each other, how clients reconnect, and which metrics expose queue depth, lag, and dropped messages.

Treat integration contracts as part of the product, since middleware sits at the boundary between teams, languages, and release cycles. Prefer systems that make versioning, schema discipline, authentication context, and error payloads explicit, and confirm stable client libraries exist for the runtimes you already use - weak client support turns every integration into a custom reliability project. Plan the exit before adoption too: portable message formats and bridgeable protocols, like the AMQP and MQTT that RabbitMQ and Mosquitto speak, let you migrate without rewriting every producer and consumer at once.

Related categories

Frequently asked questions

What does middleware mean on this page?+

Here it is software that sits between applications and services to move requests, messages, events, or integration logic - not the business app itself and not the primary database. In practice that spans message brokers like Kafka and RabbitMQ, API gateways like Traefik and KrakenD, durable workflow engines like Temporal, integration frameworks like Apache Camel, and identity layers like Keycloak. They share a location in the architecture more than a single function.

When is a broker better than a direct service-to-service call?+

Direct calls are fine when a request needs an immediate answer and both services can fail together without much harm. A broker earns its complexity when producers and consumers run at different speeds, when work must survive a restart, when one event fans out to many systems, or when retries would otherwise cascade. NATS and RabbitMQ decouple that timing; reach for them to remove a specific coupling problem, not by default.

Which delivery guarantee can I actually rely on?+

Separate the marketing term from observable behavior. Check whether delivery is at most once, at least once, or exactly once only under narrow conditions, then test ordering scope, redelivery timing, dead-letter handling, and replay from a known position. Many reliable systems still deliver duplicates after a crash or timeout, so application idempotency and clear message keys are usually part of the design even with a durable log like Kafka's.

What is the difference between a message broker and a workflow engine?+

A broker like Pulsar or RabbitMQ moves messages between producers and consumers; what happens to each message is the application's job. A workflow engine like Temporal or Conductor owns the state of a multi-step process - branches, retries, timeouts, and compensation - and keeps it moving across failures. If you find yourself rebuilding retry and state-recovery logic on top of a queue, a durable workflow engine is probably the better fit.

How do I choose between an API gateway and a service proxy?+

They overlap, but the emphasis differs. A gateway like KrakenD, WSO2 API Manager, or Ocelot focuses on the API surface: aggregation, rate limiting, auth, and product management for the clients that call you. A proxy like Traefik or Envoy focuses on routing and load balancing traffic between services, often reconfiguring itself from an orchestrator. Envoy is common as a service mesh data plane; Traefik shines at dynamic edge routing in a container platform.

What security controls should middleware provide?+

Because middleware becomes a high-value path between systems, network isolation alone is not enough. Look for TLS or mTLS, strong service identity, fine-grained authorization, tenant or namespace separation, audit logs, and encryption for persisted messages. Keycloak is often the piece supplying identity and tokens to the gateways in front of your services. A compromised middleware layer can impersonate producers, feed bad data to consumers, or expose payloads in transit.

How much should client library support weigh in the choice?+

Heavily. The best broker is a liability if it has no stable client for the runtime your producers and consumers actually use. NATS ships more than 40 client implementations and RabbitMQ speaks several standard protocols, which lowers that risk. Check for a scriptable admin API, predictable behavior across versions, and support for schemas and tracing metadata, since weak client support turns every integration into its own reliability project.