Hacker News Reader

Comment by assbuttbuttass | Hacker News Reader

Sounds like they need backpressure. Isn't that the usual solution to a queue growing without bound?

You mean you want to pause the games that are in progress? The events are created by people finishing their games and queuing for the next pair. You could limit total participants but only if you know the limit ahead of time. Nothing else makes sense.

Is there any requirement that all games start at the same time? If not I guess you could limit the amount of games that can be outstanding at any one time.

No, after the first game they don't start at the same time but the point of an arena is you get a new game as soon as the one you are playing finishes. The number of points you can earn is limited if you can't start another game right away so players would hate that system. It would be much better to limit total participants because at any given time nearly everyone should be playing.

I see, but in case I think this is less about finding an optimal solution and more about the general best practice of not having any unbounded queues in your application. Having to wait would have been annoying, definitely, but it would have surely been preferrable to the outage.

Load sheddding might also be a good solution

How would that work here?

"Load" is players finishing games and requiring new match pairings / rating updates for the tournament to continue. You can tell them to wait, sure. But as long as the rate of games finishing exceeds the rate at which they can process them I don't see how that would improve the situation, the tournament would be stuck anyway.

One option is to eg. limit the total number of players in the tournament up front but they explicitly said they didn't want to do that.

Depends upon of every event is strictly necessary for the proper functioning of the system, or if some are just nice-to-have.

This is where it helps to have domain knowledge before pontificating on someone else's architecture. It is an arena tournament. If you want people to join the tournament and get paired with games after finishing their current game you'll need those events. There are no "nice to haves".

> There are no 'nice to haves'

That's an assumption, there's a lot of assumptions flying around right now. The simple answer is we don't know.

Often there are a lot of design tradeoffs, bcrosby was likely questioning whether all events going into that specific queue were strictly necessary for matchmaking. We don't even know that this was actually the problem.

So far, no professional post-mortem, or root cause analysis has been released.

There are certainly ways one can setup these type of services so they dynamically scale correctly, but since the architecture they are using isn't fully disclosed its difficult to say anything with certainty and this type of guesswork is entirely unproductive.

lol are you all just repeating scaling buzzwords? back-pressure, load shedding, whats next horizontal scaling or maybe blockchain?

Web scale sharding.

Web 3 POINT OH blockchain though none of that 2.0 nonsense for me

This particular tournament was being played for bitcoin valued at almost 50k. It would be nice for everyone to have a fair shot at it without the system getting in the way.

Reply on news.ycombinator.com