<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>RocketMQ on timerring</title><link>https://blogs.timerring.com/tags/rocketmq/</link><description>Recent content in RocketMQ on timerring</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 05 Nov 2026 00:07:50 +0800</lastBuildDate><atom:link href="https://blogs.timerring.com/tags/rocketmq/index.xml" rel="self" type="application/rss+xml"/><item><title>Sent Is Not Done: How Message Queues Really Work</title><link>https://blogs.timerring.com/posts/sent-is-not-done/</link><pubDate>Thu, 05 Nov 2026 00:07:50 +0800</pubDate><guid>https://blogs.timerring.com/posts/sent-is-not-done/</guid><description>&lt;p>Message queues can be used for decoupling, asynchronous processing, and absorbing traffic spikes, but introducing them also means handling duplicate consumption, message loss, out-of-order processing, and backlogs. Knowing how to call the send and consume APIs is not enough to understand their role in a system.&lt;/p>
&lt;p>This article starts with why to use MQ, then covers high availability, idempotency, reliable delivery, ordering, and backlog handling in sequence, before bringing these mechanisms together to examine message queue architecture design.&lt;/p></description></item></channel></rss>