Wow that stack gives a lot of power. I've opted for a simpler architecture and haven't run into a situation where the power of that stack you describe has become necssary. In gossip: Various things trigger the need for subscriptions to be created or updated, and each relay is handled by a different thread. So these subscriptions get passed to the thread to handle, possibly spinning up new threads for relays that aren't currently connected. Events returned from the relays are not coorelated to the subscription they came in on, they all just go down the same processing pipeline with no very little state about why it was requested. That pipeline stores them in the database, creates indexes as needed, and acts on them in other ways where appropriate. Feeds are then built periodically (every few seconds) by pulling matching events out of the local database, divorced from the relay fetching activity. I'm not doing any windowing yet, but that shouldn't be hard to add. I very well may be sending messages while an AUTH is happening, but again that shouldn't be hard to fix.