Disclaimer: I’m the CTO at Jut and have been with the company since it’s inception.
Actually Jut didn't shut down last week. We figured out a much better way to package up our tech and ended up making some big changes to execute on this strategy. Unfortunately @PurpleQuark and a number of other really great people are no longer with us.
As Dave pointed out in the blog, we’ve definitely run into our fair share of challenges with the inherent limits of node.js. But on the whole, we’ve found it to strike a good balance between speed of development and performance. In addition to some of the techniques talked about in the post, we’ve also dropped down to C++ add-ons where we have really critical performance sections, and we do coarse-grained load balancing between multiple node processes to distribute computation on multiple cores.
We also have a good bit of shared code between the browser and server (including the Juttle language compiler and runtime) that has been hugely beneficial for us.
That was confusing to me as well in the article. However they also wrote:
> If however, a key is already present in the cache, Set would update the key immediately. This is to avoid a cached key holding a stale value.
So it sounds like inserts to the cache might not immediately apply, but overwrites are guaranteed to invalidate stale data in cache.