3 ms·
Interesting... I like the strategy of having each user be 1:1 with a DB. What would be done for data that needs to be aggregated across users though? If I'm s
by lukevp 3y ago
Interesting... I like the strategy of having each user be 1:1 with a DB. What would be done for data that needs to be aggregated across users though? If I'm subscribed to another user and they post, how does my DB get updated with that new post? Or is this meant just for durable data and not feed data (like profile data, which users are followed / not followed / etc.) and all the interactive stuff happens separately?
I like that "connection pooling" is just limiting the number of open handles in a LRU cache. It's also interesting because instead of having to manage concurrency at the connection level, it handles it at the tenancy level since each DB connection is single-threaded. You could build up per-DB rate limiting on top of this pretty easily to prevent abuse by a given user.
Is there a straightforward way to set up Litestream to handle any arbitrary number of DBs?
- wmf 3y agohttps://blueskyweb.xyz/blog/5-5-2023-federation-architecture https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
- Retr0id 3y agoTo summarise the relevant details, the "AppView" service is responsible for the sorts of queries that aggregate across users, and that has its own database setup - I think postgres but I'm not 100% sure on that.
- jakebsky 3y agoYou're right, as usual. AppView is on a Postgres cluster with read replicas doing timeline generation (and other things) on-demand. We're in the process of moving it toward a beefy ScyllaDB cluster designed around a fanout-on-write system. The v1 backend system was optimized for rapid development and served us well. The v2 backend will be somewhat less flexible (no joins!) but is designed for much higher scale.
- manmal 3y agoDoes the BGS pull all the tenant‘s individual SQLite data? Or do the PDS push new posts to the BGS?
- jakebsky 3y agoThe BGS (which is an atproto "relay" service) subscribes to all PDS event streams on the entire network, and aggregates and relays them. This way it's possible to get all network data from a single place (the BGS) rather than having to connect to every PDS, which is simpler for consumers and dramatically reduces the workload of PDS hosts. Some details about event streams here, although the APIs are still evolving: https://atproto.com/specs/event-stream https://atproto.com/specs/event-stream
- manmal 3y agoThank you!
- rapnie 3y ago> The BGS handles "big-world" networking. It crawls the network, gathering as much data as it can, and outputs it in one big stream for other services to use. It’s analogous to a firehose provider or a super-powered relay node. "Big-world" networking by Big Tech-to-be Bluesky with super-powers, I wonder? Is this BGS also going to be federated, or is that the big centralized beating heart of this platform managed exclusively by BS?
- wmf 3y agoThere can be multiple BGSes (like there are a few Web search engines) but it's expensive to run so there probably won't be many. Alternative designs are either more expensive or don't have the same features.