I think it depends a lot on the federated service.
For mastodon, you follow individual users, so if there’s a million users or ten million or a hundred million, their instances will only be contacting other intances they’re federating with so it’s quite scalable.
For Lemmy, you follow communities, so every server pulls all the posts and comments the common community. This means that for an instance like lemmy.world hosting lots of different big communities, every new server hammers the one central instance.
A strategy for improving the situation I think would be to spread the load. Instead of everyone piling into megacommunities, if people spread out into smaller more tight knit communities over many different instances. Of course, this isn’t really compatible with the purpose of having communities like that.
It does seem to suggest that ActivityPub isn’t necessarily the most appropriate protocol for this purpose, even though it’s what was used because it’s the de facto standard on the fediverse.
A big issue with Lemmy right now is how picture storage works. All photos are cached as they enter the instance and there isn’t much to do to turn it off. It’s ridiculous, especially for server scaling. The database in of itself is small, it’s really the pictures that are an issue and grow rapidly.
Right now federation traffics only have minimal impacts to Lemmy. They mostly consume network resource (to send out activitypub messages already waiting in the queue), unlike actual user traffics that consume a lot more CPU resources and database access.
When federation traffics finally become large enough to cause issues on popular instances, I think it should be easy enough for the devs to address (e.g. offloading activitypub subscription to relay servers). Actual user traffics are much harder to scale.
Federation traffic killed most servers just about a month ago. The problem is not some type of traffic, the problem is that Lemmy software is very bad.