ActivityPub based platforms (Mastodon, Pixelfed) are monolithic services. You have to run the entire instance (account hosting, feed generation, moderation etc.) all in one place on one machine.
While you can do work with loads balancing to manage high traffic moments, this approach is still brittle to spikes in load.
ATP separates each of these services and handles how’s these services communicate and operate. I can’t really explain it better than their documentation, but one easy example to point to is how you can self-hodt your own PDS (Personal Data Server) which stores your account data and posts, meaning you can keep it stored entirely on your own hardware separate from whoever provides your feed building and presentation service.
I’d highly recommend reading both the ATP and ActivityPub documentation as both are very well written and communicated these differences more effectively.
If I have to explain why separation of concerns in the way that ATP approaches things is more scalable, I might suggest doing some reading on web application architecture patterns and the pros, cons, and practical applications of each.
The TL;DR version is that if the different components of your application run independently of each other, it’s easier to have redundancy and extra resources in place for the specific components that require it.
This is also helpful for federation, as the end goal of ATP is to be able to host your personal data where you want, use the feed builder that you want, the labeller that you want, the app view that you want, regardless of who runs each service.
ActivityPub based platforms (Mastodon, Pixelfed) are monolithic services. You have to run the entire instance (account hosting, feed generation, moderation etc.) all in one place on one machine.
While you can do work with loads balancing to manage high traffic moments, this approach is still brittle to spikes in load.
ATP separates each of these services and handles how’s these services communicate and operate. I can’t really explain it better than their documentation, but one easy example to point to is how you can self-hodt your own PDS (Personal Data Server) which stores your account data and posts, meaning you can keep it stored entirely on your own hardware separate from whoever provides your feed building and presentation service.
I’d highly recommend reading both the ATP and ActivityPub documentation as both are very well written and communicated these differences more effectively.
If I have to explain why separation of concerns in the way that ATP approaches things is more scalable, I might suggest doing some reading on web application architecture patterns and the pros, cons, and practical applications of each.
The TL;DR version is that if the different components of your application run independently of each other, it’s easier to have redundancy and extra resources in place for the specific components that require it.
This is also helpful for federation, as the end goal of ATP is to be able to host your personal data where you want, use the feed builder that you want, the labeller that you want, the app view that you want, regardless of who runs each service.