...other that satisfying provided tester script.
Tester performs really dummy test (many edge cases are not covered) and benchmark test (measures maximum throughput). In the real system I would rather expect incoming events to come at some finite and almost fixed rate. Clients connections on the other hand are unreliable -- there might be some really slow readers (on purpose or not). Temporary client read slowness should be solved by with a help of message queues (buffered channel) but longer read stalls should not be back propagated to the event source. I would expect event source to emit events at the rate that real actions happen (follows, unfollows, PM sends, etc.). In that case slowing its send transmission rate does not make sense (How should it even be done otherwise? By disabling related action UI controls?)
...other that satisfying provided tester script.
Tester performs really dummy test (many edge cases are not covered) and benchmark test (measures maximum throughput). In the real system I would rather expect incoming events to come at some finite and almost fixed rate. Clients connections on the other hand are unreliable -- there might be some really slow readers (on purpose or not). Temporary client read slowness should be solved by with a help of message queues (buffered channel) but longer read stalls should not be back propagated to the event source. I would expect event source to emit events at the rate that real actions happen (follows, unfollows, PM sends, etc.). In that case slowing its send transmission rate does not make sense (How should it even be done otherwise? By disabling related action UI controls?)