Tumblr Architecture and one oddity

Going through the StorageMojo website I came across a tweet that pointed to this High Scalability article: http://highscalability.com/blog/2013/5/20/the-tumblr-architecture-yahoo-bought-for-a-cool-billion-doll.html

It is fascinating to learn about the technologies that Tumblr uses to operate at a mind boggling scale. It is not a joke that Yahoo! paid $1.1 billion for it. With all due respect to the amazing technologies that Tumblr has accomplished there is but one piece that strikes me as odd:

“…Example, for a new ID generator they needed A JVM process to generate service responses in less the 1ms at a rate at 10K requests per second with a 500 MB RAM limit with High Availability. They found the serial collector gave the lowest latency for this particular work load. Spent a lot of time on JVM tuning…”

Especially the part “…Spent a lot of time on JVM tuning…”. This is clearly a niche low-latency use case. For such things why not just drop to native code and maybe a slab allocator and be done with it? Why spend “lots of time” fighting with Garbage Collector and related effects? What about using the right tool for the job?

Maybe there is something else that I am missing completely.


One thought on “Tumblr Architecture and one oddity

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s