Hacker News Reader

Comment by Arnt | Hacker News Reader

A place where I contracted used them to solve timing issues with the database.

Actions would be written to a database and a web page sent to the user, then the user would click something and a request would reach a web server, occasionally arriving before that server's database shard had seen the database write.

JWT passed the information via the user's browser, eliminating the race.

View on HN

That's certainly not a use case I'd have ever imagined. With that scenario I'd have thought sessions (essentially binding a user to the same backend for a period of time) in the load balancer(s) would be a simpler solution, but that's just me.

Arguably that was done, if I remember the architecture well… the company had a rule against SPoFs, so there were ① several load balancers at different sites, with ② several clusters of servers behind them, and ③ several backends supplying data to the servers.

I think the JWT usage was in 2, but moving it to 1 would have presented the same problem, because in that case the mapping from user to backend would have to be coordinated for geographically dispersed load balancers, with the same timing constraints.

It would also be possible to use various techniques that add a delay to the user, such as avoiding anycast and having the client occasionally slow down while searching for a usable cluster.

The last time I ran into a similar thing I solved this race condition by not erroring out on an invalid lookup until a reasonable number of seconds to allow the backend to catch up.

Reply on news.ycombinator.com