Findory: ¿Hasta donde debemos optimizar?

Parece que Findory, una startup creada en el 2004 y cuyo objetivo era el agregar información desde diferentes fuentes y personalizarla en base a los gustos de los usuarios ha anunciado que cerrará sus puertas el 1 de Noviembre.

Hasta aquí nada extraño, ya que lo de cerrar y crear compañías y productos está a la orden del día. Sin embargo lo que me ha llevado a escribir una entrada en este blog es un post de hace un par de días de su creador Greg Linden en el que explica los problemas que plantea el escalar un sitio web que pretende proporcionar contenido personalizado para cada uno de sus usuarios.

En el post, Greg explica como Findory consiguió obtener un espectacular rendimiento en estos últimos años, llegando a renderizar páginas únicas para cada usuario en menos de 100 ms. Para ello los datos de sólo lectura se replicaban en los servidores web y se almacenaban en BerkeleyDB, mientras que los de lectura/escritura utilizaban MySQL. En fin, que con esto consiguió crear un motor espectacularmente rápido e incrementar la escalabilidad de su sitio web, al tiempo que mejoraba la experiencia de sus usuarios.

Pero hubo un problema. La experiencia de sus usuarios se mejoró en cuanto a rapidez de acceso, pero no en cuanto a funcionalidades. Greg se pregunta en una muy valiente entrada hasta dónde tiene sentido optimizar.

Even so, I wonder if I have been too focused on scaling and performance. For example, there have been some features in the crawl, search engine, history, API, and Findory Favorites that were not implemented because of the concern about how they might scale. That may have been foolish.

Creo que se pueden aprender muchas lecciones de esta historia, pero me quedo sobre todo con que al final ser el más rápido no implica ser el que se lleva el gato al agua, sino que a veces es importante sacrificar algo de rendimiento y escalabilidad a costa de ofrecer más funcionalidades.