ActivityPub hot take: Implementations shouldn't use inbox queues for anything up to and including authentication, validation and authorisation, but instead apply backpressure across the network.
GoToSocial has the right idea here: https://docs.gotosocial.org/en/latest/federation/ratelimiting/
This reduces cost traps for smaller instances and, given decent core budgeting, ensures the instance won't "brown out" or build up a delay due to queue length.
It also means you can return much better federation diagnostics to the sender in case of error (or sometimes warnings when you succeed).
Sending instances usually retry delivery, more or less intelligently, up to a point. You should monitor to ensure you're below capacity most of the time and send appropriate response headers when you do have to time out requests.
Once committed to your local model (where applicable), fanning out into notifications/websocket/potentially feeds if you have a huge sharded system can and should all be done as deferred jobs.
=> More informations about this toot | View the thread | More toots from Qazm@tiggi.es
text/geminiThis content has been proxied by September (3851b).