{
  "id": "apache-kafka-vs-rabbitmq",
  "ids": [
    "apache-kafka",
    "rabbitmq"
  ],
  "title": "Apache Kafka vs RabbitMQ: replay, routing and message delivery",
  "heading": "Apache Kafka vs RabbitMQ",
  "kicker": "Data engineering software comparison",
  "deck": "Compare Apache Kafka and RabbitMQ for retained events, work queues, routing, consumer progress, acknowledgement semantics and the cost of operating the chosen design.",
  "description": "Compare Apache Kafka and RabbitMQ for retained events, work queues, routing, consumer progress, acknowledgement semantics and the cost of operating the chosen design.",
  "answerHeading": "Which pipeline approach fits?",
  "answer": "Consider Kafka when retained event topics and independently progressing consumers fit the application. Consider RabbitMQ when its routing and selected queue or stream type fit the delivery requirement. RabbitMQ Streams also support retained, replay-oriented consumption, so queues versus replay is not a complete product comparison. Define retention, ordering, acknowledgement and application side effects before selecting a broker; no universal throughput winner is established here.",
  "checkedAt": "2026-10-15",
  "researchTag": "Pipeline scope, recovery and cost comparison",
  "researchLimit": "Official product and pricing documentation checked. The exercises below are proposed evaluation briefs, not completed tests, pipeline measurements or performance benchmarks.",
  "datasetDescription": "Seven architecture and buying differences, four pipeline evaluation briefs and four acceptance checks for Apache Kafka vs RabbitMQ.",
  "type": "workflow-buying",
  "rows": [
    [
      "Core choices",
      "Partitioned event topics with configurable retention",
      "Exchanges, queues and streams with distinct semantics"
    ],
    [
      "Consumer progress",
      "Offsets and consumer arrangements for topic processing",
      "Acknowledgements for queues; offsets and retention for streams"
    ],
    [
      "Replay",
      "Read retained topic events again with the required consumer design",
      "Use an appropriate stream when retained replay is required"
    ],
    [
      "Routing",
      "Topic and partition design with application/connector choices",
      "Exchange and binding routing for applicable queue workflows"
    ],
    [
      "Ordering",
      "Specify partition, key and actual consumer behaviour",
      "Specify queue/stream type, consumers and actual processing behaviour"
    ],
    [
      "Delivery safety",
      "Review producer, consumer and destination behaviour together",
      "Publisher confirms and consumer acknowledgements cover different stages"
    ],
    [
      "Operating cost",
      "Brokers, retained replicas, network, processing and operator work",
      "Nodes, selected destination types, retained replicas and operator work"
    ]
  ],
  "scenarios": [
    {
      "name": "Order work queue",
      "question": "Can workers handle one task without losing an uncompleted delivery?",
      "left": "Define the consumer arrangement, progress tracking and retry strategy.",
      "right": "Define the queue type, manual acknowledgement and retry handling.",
      "note": "Use synthetic work with an idempotency key; the business side effect must be safe to repeat."
    },
    {
      "name": "Second consumer",
      "question": "Can a new application read the retained event history?",
      "left": "Define the independent consumer and starting offsets within retention.",
      "right": "Use a supported stream and define its offset and retention policy.",
      "note": "Do not promise historical replay from a queue whose messages have already been acknowledged and removed."
    },
    {
      "name": "Failed acknowledgement",
      "question": "What happens if a worker commits output and then disconnects?",
      "left": "Review the offset commit and destination transaction boundary.",
      "right": "Review acknowledgement timing and expected redelivery.",
      "note": "A repeated message must not create an unintended second business action."
    },
    {
      "name": "Growing retention",
      "question": "Can the team retain the required history without exhausting capacity?",
      "left": "Estimate partitions, replication, retained data and transfer.",
      "right": "Estimate the selected queues or streams, replicas and retention.",
      "note": "Measure capacity in the actual design; this comparison contains no synthetic throughput ranking."
    }
  ],
  "exampleTable": {
    "caption": "Proposed evaluation checks; no measured product results are implied.",
    "headers": [
      "Requirement",
      "Proposed exercise",
      "Accept when"
    ],
    "rows": [
      [
        "Work completion",
        "Interrupt a permitted test worker around completion",
        "Uncompleted work and repeat side effects are accounted for"
      ],
      [
        "Replay",
        "Start an isolated consumer at an agreed historical position",
        "Required retained events can be read"
      ],
      [
        "Delivery boundary",
        "Trace publish, processing and acknowledgement separately",
        "Each confirmation’s meaning is documented"
      ],
      [
        "Capacity",
        "Model retained data and replicas over the required window",
        "Storage and operating responsibility are explicit"
      ]
    ]
  },
  "sections": [
    {
      "id": "semantics",
      "title": "Specify the destination type",
      "navLabel": "Specify the destination type",
      "paragraphs": [
        "Kafka’s retained topics and RabbitMQ’s queue and stream options make the real decision more specific than two product names. Acknowledged queue messages and retained stream events have different lifecycles. Pick the required behaviour for each destination rather than assuming one setting describes an entire broker.",
        "For ordering, describe the key or partition, consumer concurrency and the point when processing finishes. An ordered delivery path does not establish that parallel workers complete business actions in the same order. Put the expected application result into the evaluation contract."
      ]
    },
    {
      "id": "delivery",
      "title": "A broker acknowledgement is not the whole transaction",
      "navLabel": "A broker acknowledgement is not the whole transaction",
      "paragraphs": [
        "RabbitMQ distinguishes publisher confirms from consumer acknowledgements. One concerns the publisher’s interaction with the broker; the other concerns delivery to the consumer. Kafka also requires an explicit design for producer behaviour, consumer progress and destination writes. Inspect the full chain before describing a business operation as exactly once.",
        "Rehearse the difficult boundary: output is committed but consumer progress is not. Use an isolated synthetic workload and identify how the next delivery is handled. Budget retained data, replicas, network traffic and recovery ownership in addition to normal message volume, whether self-managed or purchased as a managed service."
      ]
    }
  ],
  "faqs": [
    {
      "question": "Is RabbitMQ limited to ordinary work queues?",
      "answer": "No. RabbitMQ also supports streams with retained, replay-oriented consumption. Compare the actual queue or stream type."
    },
    {
      "question": "Do publisher confirms prove the application processed a message?",
      "answer": "No. In RabbitMQ, publisher confirms and consumer acknowledgements cover different parts of the delivery chain."
    },
    {
      "question": "Which broker has higher throughput?",
      "answer": "No measured throughput conclusion is made here. Evaluate the same durability, retention, message size, client and failure requirements on the intended infrastructure."
    }
  ],
  "sources": [
    {
      "url": "https://kafka.apache.org/intro/",
      "facts": "Topics, partitions, retention and consumer model"
    },
    {
      "url": "https://www.rabbitmq.com/docs/confirms",
      "facts": "Publisher confirms and consumer acknowledgement boundaries"
    },
    {
      "url": "https://www.rabbitmq.com/docs/streams",
      "facts": "Streams, retention and replay"
    },
    {
      "url": "https://www.rabbitmq.com/docs/compare/kafka",
      "facts": "Current product semantics and comparison scope"
    }
  ],
  "relatedLinks": [
    {
      "path": "/categories/data-integration-engineering/",
      "title": "Explore data integration and engineering software"
    },
    {
      "path": "/compare/apache-spark-vs-google-cloud-dataflow/",
      "title": "Compare processing options for streaming pipelines"
    },
    {
      "path": "/guides/data-ingestion-transformation-orchestration/",
      "title": "Understand ingestion, transformation and orchestration"
    }
  ],
  "downloads": [
    {
      "path": "/downloads/apache-kafka-vs-rabbitmq-evaluation.csv",
      "title": "Download the pipeline checklist (CSV)",
      "description": "Four proposed checks with blank evidence and owner columns. Record the actual deployment, package, data volume and recovery requirements in your evaluation."
    }
  ]
}