Haha, more than one node. That's pretty non-trivial for the way hubski is currently built: https://news.ycombinator.com/item?id=5032739 (Notice that pg corrected my more general comment, but making the changes he suggests to hubski is still non-trivial.) Update: you'll probably want to read the original story first, the programmer types among you: http://davidkendal.net/articles/2011/11/a-man-a-plan
So the issue is that the fnid links reference a function's closure, which is stored in a hashmap? So the more fnid links get served up, the more memory gets used? And then when it expires, you get the unknown or expired link sort of thing? Sounds like this wouldn't translate very well into multiple machines, unless figured out a way to store closures externally.
It also makes it sound like running behind a CDN (or any kind of proxy) won't work too well. That really sucks. I don't care too much for programming language pissing contests, but if that's really a limitation, well...that's a pretty severe one to say the least.
I'm not sure it is a programming language limitation. The link in the link above points out the Paul Gram pretty much pioneered lisp on the Web, and that most thing just emulate his ideas. That means that change could come, but that right now the "standard" implementation has limits. This is good, but requires a lot of work to make happen.