<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Got an interesting question today about #Fedify&#x27;s outgoing #queue design!]]></title><description><![CDATA[<p dir="auto">Got an interesting question today about #Fedify's outgoing #queue design!</p>
<p dir="auto">Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.</p>
<p dir="auto">In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.</p>
<p dir="auto">By creating individual queue items for each recipient:</p>
<ul>
<li>Fast servers get messages delivered promptly</li>
<li>Slow servers don't delay delivery to others</li>
<li>Failed deliveries can be retried independently</li>
<li>Your UI remains responsive while deliveries happen in the background</li>
</ul>
<p dir="auto">It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.</p>
<p dir="auto">This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!</p>
<p dir="auto">What other aspects of Fedify's design would you like to hear about? Let us know!</p>
<p dir="auto">#ActivityPub #fedidev</p>
]]></description><link>https://forum.pierobosio.it/topic/6ec3dfe6-d06f-4c82-b631-bdef8bdb32c5/got-an-interesting-question-today-about-fedify-s-outgoing-queue-design</link><generator>RSS for Node</generator><lastBuildDate>Fri, 12 Jun 2026 02:05:56 GMT</lastBuildDate><atom:link href="https://forum.pierobosio.it/topic/6ec3dfe6-d06f-4c82-b631-bdef8bdb32c5.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 10 Mar 2025 13:07:50 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Got an interesting question today about #Fedify&#x27;s outgoing #queue design! on Thu, 20 Mar 2025 07:06:01 GMT]]></title><description><![CDATA[<p dir="auto">Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!</p>
<p dir="auto">After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.</p>
<p dir="auto">As we discussed in <a href="https://hollo.social/@fedify/0195802b-35d0-7a9b-a8f8-92e3035415d8" target="_blank" rel="noopener noreferrer">our previous post</a>, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.</p>
<p dir="auto">Our solution? A new two-stage “fan-out” approach:</p>
<ol>
<li>When you call <code>Context.sendActivity()</code>, we'll now enqueue just <em>one</em> consolidated message containing your activity payload and recipient list</li>
<li>A background worker then processes this message and re-enqueues individual delivery tasks</li>
</ol>
<p dir="auto">The benefits are substantial:</p>
<ul>
<li><code>Context.sendActivity()</code> returns almost instantly, even for massive follower counts</li>
<li>Memory usage is dramatically reduced by avoiding payload duplication</li>
<li>UI responsiveness improves since web requests complete quickly</li>
<li>The same reliability for individual deliveries is maintained</li>
</ul>
<p dir="auto">For developers with specific needs, we're adding a <a href="https://unstable.fedify.dev/manual/send#when-to-use-each-option" target="_blank" rel="noopener noreferrer"><code>fanout</code> option</a> with three settings:</p>
<ul>
<li><code>"auto"</code> (default): Uses fanout for large recipient lists, direct delivery for small ones</li>
<li><code>"skip"</code>: Bypasses fanout when you need different payload per recipient</li>
<li><code>"force"</code>: Always uses fanout even with few recipients</li>
</ul>
<pre><code>// Example with custom fanout setting
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "skip" }  // Directly enqueues individual messages
);
</code></pre>
<p dir="auto">This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!</p>
<p dir="auto">For more details, check out our <a href="https://unstable.fedify.dev/manual/send#optimizing-activity-delivery-for-large-audiences" target="_blank" rel="noopener noreferrer">docs</a>.</p>
<p dir="auto">What other #performance optimizations would you like to see in future Fedify releases?</p>
<p dir="auto">#ActivityPub #fedidev</p>
]]></description><link>https://forum.pierobosio.it/post/https://hollo.social/@fedify/0195b25f-86db-7615-a98a-349e9ba5ee4f</link><guid isPermaLink="true">https://forum.pierobosio.it/post/https://hollo.social/@fedify/0195b25f-86db-7615-a98a-349e9ba5ee4f</guid><dc:creator><![CDATA[fedify@hollo.social]]></dc:creator><pubDate>Thu, 20 Mar 2025 07:06:01 GMT</pubDate></item></channel></rss>