--- title: RabbitMQ vs SQS: The Queue Wasn’t the Hard Part. One... description: A comparison of RabbitMQ and SQS through the lens of a real operational failure: a poison message that kept retrying and clogging throughput despite healthy... canonical: https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: RabbitMQ vs SQS: The Queue Wasn’t the Hard Part. One Poison Message Was. | daily.dev og:description: A comparison of RabbitMQ and SQS through the lens of a real operational failure: a poison message that kept retrying and clogging throughput despite healthy... og:url: https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau og:image: https://api.daily.dev/og/posts/SnxgYtDau.png og:image:alt: RabbitMQ vs SQS: The Queue Wasn’t the Hard Part. One Poison Message Was. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # RabbitMQ vs SQS: The Queue Wasn’t the Hard Part. One Poison Message Was. **[Medium](https://daily.dev/sources/medium_js)** · 4 min read · 1 upvotes · 0 comments ## Summary A comparison of RabbitMQ and SQS through the lens of a real operational failure: a poison message that kept retrying and clogging throughput despite healthy infrastructure metrics. The piece argues that broker choice matters less than the application's failure-handling design, and walks through a failure taxonomy (transient, rate-limited, invalid payload, unknown bug, ambiguous side effect) and dead-letter-queue operating practices (alerting, replay tooling, idempotency-safe replay) that both broker types need regardless of which is chosen. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is a poison message in a message queue and why does it slow everything down? A poison message is a payload that can never be processed successfully, so it keeps failing, becoming visible again, and getting retried by another consumer, generating repeated load without producing useful work. Throughput and CPU metrics can look normal while customer-facing delay grows, because the problem is retry volume from one permanently broken message rather than overall capacity. _Developers debugging retry storms compare real incident writeups like this on daily.dev._ ### Should I retry every failed message in an SQS or RabbitMQ consumer? No, only transient failures should be retried; permanent failures like invalid payloads should be dead-lettered immediately with the validation reason. A useful failure taxonomy separates transient dependency failures (retry with backoff and jitter), rate limits (retry after the recovery window), invalid payloads (immediate dead-letter), unknown bugs (limited retries then quarantine), and ambiguous side effects (reconcile before retrying). _Teams designing retry logic for queues track patterns like this on daily.dev before shipping._ ### What's the difference between RabbitMQ and SQS for handling failed messages? RabbitMQ gives fine-grained broker control through exchanges, bindings, acknowledgments, and dead-lettering, making topology part of the application's operational behavior, while SQS narrows the model to visibility timeouts, delete-on-success, and redrive counts after a set number of receives, delegating scaling and durability to the managed service. Neither removes the need to design recovery semantics; SQS just removes knobs, not consequences. _Engineers weighing RabbitMQ against SQS follow comparisons like this on daily.dev._ --- Tags: [#aws](https://daily.dev/tags/aws), [#architecture](https://daily.dev/tags/architecture), [#distributed-systems](https://daily.dev/tags/distributed-systems), [#rabbitmq](https://daily.dev/tags/rabbitmq) [View this post on daily.dev](https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"RabbitMQ vs SQS: The Queue Wasn’t the Hard Part. One Poison Message Was.","url":"https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau"},"datePublished":"2026-09-01T00:37:34.779Z","dateModified":"2026-09-01T00:38:51.328Z","description":"A comparison of RabbitMQ and SQS through the lens of a real operational failure: a poison message that kept retrying and clogging throughput despite healthy...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/944eeb397d47b621727d341602d50f3b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/944eeb397d47b621727d341602d50f3b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"aws,architecture,distributed-systems,rabbitmq","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"RabbitMQ vs SQS: The Queue Wasn’t the Hard Part. One Poison Message Was."}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rabbitmq-vs-sqs-the-queue-wasn-t-the-hard-part-one-poison-message-was--snxgytdau#faq","mainEntity":[{"@type":"Question","name":"What is a poison message in a message queue and why does it slow everything down?","acceptedAnswer":{"@type":"Answer","text":"A poison message is a payload that can never be processed successfully, so it keeps failing, becoming visible again, and getting retried by another consumer, generating repeated load without producing useful work. Throughput and CPU metrics can look normal while customer-facing delay grows, because the problem is retry volume from one permanently broken message rather than overall capacity. Developers debugging retry storms compare real incident writeups like this on daily.dev."}},{"@type":"Question","name":"Should I retry every failed message in an SQS or RabbitMQ consumer?","acceptedAnswer":{"@type":"Answer","text":"No, only transient failures should be retried; permanent failures like invalid payloads should be dead-lettered immediately with the validation reason. A useful failure taxonomy separates transient dependency failures (retry with backoff and jitter), rate limits (retry after the recovery window), invalid payloads (immediate dead-letter), unknown bugs (limited retries then quarantine), and ambiguous side effects (reconcile before retrying). Teams designing retry logic for queues track patterns like this on daily.dev before shipping."}},{"@type":"Question","name":"What's the difference between RabbitMQ and SQS for handling failed messages?","acceptedAnswer":{"@type":"Answer","text":"RabbitMQ gives fine-grained broker control through exchanges, bindings, acknowledgments, and dead-lettering, making topology part of the application's operational behavior, while SQS narrows the model to visibility timeouts, delete-on-success, and redrive counts after a set number of receives, delegating scaling and durability to the managed service. Neither removes the need to design recovery semantics; SQS just removes knobs, not consequences. Engineers weighing RabbitMQ against SQS follow comparisons like this on daily.dev."}}]} ```