3 ms·
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
by Arnt 3y ago
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.
- stephenr 3y agoThat'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.
- Arnt 3y agoArguably 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.
- gav 3y agoThe 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.