telendt / fmaze Goto Github PK

• It's not really said, that user ID is an int (although it looks like that from the given examples). Should I accept string of any characters except of "|" (event field separator) instead?
• What if an event with specific sequence number is missing? Should we move on? And if so, should this information be exposed somehow? (In that case user connection graph is potentially broken.)

Clients should send their ID within some finite (preferably small) timeframe, otherwise their connection should be closed (since the protocol does not define a way of communicating problems back to the clients).

This would not make sense in the real world scenario (real world connection graphs are too sparse) but benchmarks (tester) would benefit from it (true, unamortized O(1) lookups).

Also, document why connection graph build by provided tester script is unrealistic and how this information can be used to game the benchmark.

At the moment the test coverage is below 50%, it should be higher.

...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?)

• split code into packages (done in 140ed45)
• improve documentation
• provide godoc link

What are the limits (in/out throughput, memory, number of concurrent connections) and how to scale it to multiple machines.