With Elon Musk’s acquisition of Twitter closing today, there’s been a massive wave of users migrating to Mastodon, the open-source, decentralized social network. Mastodon has reportedly gained over 200,000 new users in the past week alone, and the numbers keep climbing. As both a long-time open-source advocate and someone who runs infrastructure for a living, this moment is fascinating — and raises some serious technical questions.
The ActivityPub Architecture Under Pressure#
Mastodon is built on ActivityPub, a W3C standard for decentralized social networking. Instead of a single company running all the servers, anyone can run a Mastodon instance (server) that federates — shares content — with other instances across the network.
This is elegant in theory, but the current surge is stress-testing the architecture in ways it hasn’t experienced before. Each Mastodon instance is essentially an independent Ruby on Rails application backed by PostgreSQL, with Redis for caching and Sidekiq for background job processing. When a post federates, it needs to be delivered to every instance that has followers of that user. For popular accounts, that means thousands of HTTP POST requests per message.
I’ve been watching the infrastructure metrics from several large instances, and the bottleneck is consistently in the Sidekiq job queues. Federation delivery jobs pile up faster than they can be processed, creating delays of minutes to hours for posts to appear on remote instances. The architecture wasn’t designed for this kind of throughput, and it shows.
The Instance Admin Challenge#
What makes this migration unique is that Mastodon’s infrastructure is run by volunteers. The largest instances — mastodon.social, mastodon.online, mstdn.social — are operated by individuals or small teams, often funded by Patreon or donations. When you go from 10,000 active users to 100,000 in a week, your infrastructure costs don’t increase linearly. They spike dramatically.
Instance administrators are scrambling to scale their PostgreSQL databases, add Sidekiq workers, and increase their Redis memory allocations. Some have set up GoFundMe campaigns to cover unexpected hosting bills. Others have temporarily closed registrations to prevent their instances from becoming unusable.
This is the uncomfortable truth about decentralization: it distributes the technical and financial burden to people who may not have the resources or expertise to handle it. Running a social media server for a few hundred friends is very different from running one for tens of thousands of strangers.
What Mastodon Gets Right#
Despite the scaling challenges, there are aspects of Mastodon’s architecture that are genuinely well-designed. The ActivityPub protocol means no single point of failure. If mastodon.social goes down, the rest of the network continues operating. Your identity isn’t tied to a company’s business model.
The content moderation model is also interesting. Each instance sets its own rules, and instances can block or silence other instances. This creates a layered moderation approach where communities can set their own standards while still participating in the broader network. After years of watching centralized platforms struggle with content moderation at scale, this federated approach has clear advantages.
From a developer perspective, the Mastodon API is clean and well-documented. It’s broadly compatible with the Twitter API v1 patterns, which has made it relatively easy for developers to build clients and tools. The ecosystem of third-party apps — Tusky, Ice Cubes, Ivory (in development) — is growing rapidly.
The Technical Improvements Needed#
For Mastodon to sustain this growth, several technical challenges need addressing. The federation delivery system needs to be more efficient — perhaps batching deliveries by instance rather than sending individual requests. The search functionality is intentionally limited (you can only search hashtags by default, not full text), which is a deliberate design choice but frustrates new users coming from Twitter.
The onboarding experience is also a significant barrier. Asking new users to choose an instance before they understand what instances are creates unnecessary friction. The joinmastodon.org site tries to help, but the concept of federation is inherently more complex than “sign up for Twitter.”
There’s also the question of long-term sustainability. The current funding model — donations and Patreon — works for small instances but doesn’t scale to the infrastructure demands of a platform serving millions. Someone needs to figure out how to fund decentralized infrastructure sustainably, and I don’t think anyone has cracked that yet.
My Take#
I set up my own Mastodon instance a couple of years ago, mostly out of curiosity. It’s been a quiet corner of the internet where I occasionally post about infrastructure topics. This week, it suddenly feels a lot less quiet.
I’m cautiously optimistic about this moment. The underlying technology — ActivityPub, federation, open-source social networking — is sound. The principles are right: users should own their social graph, moderation should be community-driven, and no single company should control public discourse.
But I’ve been in tech long enough to know that surviving a hype cycle is harder than starting one. The real test for Mastodon isn’t whether it can handle this week’s traffic spike — it’s whether the community can build the infrastructure, tooling, and funding models to sustain growth over years.
If you’re a developer thinking about joining Mastodon, I’d encourage it. Pick a smaller, well-moderated instance rather than piling onto mastodon.social. And if you have infrastructure experience, consider helping an instance admin — they could use it right now.
The fediverse is having its moment. Let’s see if it can make it last.