Nolan, here: the guy that wrote the post about the recent layoffs.
As stated in the post, I honestly believe that Flickr-the-site, in the long run, will be fine. Do these layoffs hurt? Of course! But Flickr has had bigger bumps in the past and has pushed through them all. The engineers there are an incredible crew of guys and Markus's post at the first of the year on blog.flickr.net shows that they've got some exciting stuff on the way.
I also have been (in a small way) helping Aaron with parallel-flickr and I think he as much as anyone would say that he's not building a replacement Flickr but more of being a good archivist and leaving nothing important up to chance, even if the odds are 1-in-some-big-number of Something Bad happening.
Obviously, I don't know the whims of major corporations like Yahoo, but Flickr-the-site, which is its content and its devotion to preserve that content, hasn't wavered in how it treats your data.
At Flickr, we recently added some real-time features to our API, so I built a little page that simply streams every single of our photos that is tagged with #occupywallstreet.
I used node.js -- mainly socket.io (what a great little module) and flickr-conduit (link: https://github.com/mncaudill/flickr-conduit) that I wrote to make using the real-time stuff easier.
I work at Flickr and I see they mentioned Flickr's ticket server idea, (ab)using MySQL's autoincrement and "REPLACE INTO" trick and mentioned that a con was the write bottleneck.
We're generating more GUIDs than ever with this system and those boxes are more or less idle on every metric. They're right in that we don't meet their time-ordered requirement, but I just wanted to say that writing (or reading) is not a bottleneck.
I like that you guys are using your database's stock features to accomplish this. Most of the time you don't need complicated systems to get things done. Reducing that mental overload of YET another system is huge.
