Una memoria USB olvidada y una demostración en vídeo: la creación del motor de Dropbox

En mayo de 2007, Drew Houston constituyó Evenflow, Inc., sentando las bases de una plataforma de sincronización en la nube nacida de una frustración académica cotidiana. Mientras estudiaba en el Instituto Tecnológico de Massachusetts, Houston se cansó de olvidar repetidamente su memoria USB. Para resolver el problema de gestionar unidades de almacenamiento físico en distintas máquinas, comenzó a escribir el código de un servicio que mantuviera automáticamente archivos idénticos en múltiples ordenadores.

La memoria USB olvidada y una grabación de pantalla

Para mostrar cómo funcionaba el software inicial, Houston publicó un sencillo vídeo de demostración en formato screencast. La grabación llamó la atención de Arash Ferdowsi, quien quedó tan impresionado con el diseño del producto que se unió a Houston como cofundador. En su fase operativa inicial, varios litigios sobre marcas registradas obligaron al equipo a alojar el servicio en el dominio temporal getdropbox.com. La startup operó bajo esta dirección web hasta octubre de 2009, momento en que adquirió el dominio dropbox.com y cambió oficialmente el nombre de Evenflow, Inc. a Dropbox, Inc.

Sincronización delta y puertos locales

Crear un sistema de sincronización fluido requería superar importantes limitaciones de ancho de banda en la red. En lugar de volver a cargar un documento completo cada vez que se modificaba un archivo, Dropbox implementó un mecanismo de sincronización delta. Con este sistema, cuando se alteraba un archivo, el software detectaba las partes modificadas y subía únicamente esos fragmentos en lugar de retransmitir el archivo entero. Para acelerar las velocidades en redes locales compartidas, el ingeniero de Dropbox Paul Bohm creó en 2010 un protocolo de sincronización LAN. Mediante la emisión a través del puerto UDP 17500, este protocolo propietario permitía que los ordenadores de una misma red local se descubrieran entre sí y sincronizaran archivos directamente sin depender de servidores externos en la nube.

Reescribiendo el backend: de Python a Go

A medida que el registro de usuarios aumentaba rápidamente, el servicio se topó con cuellos de botella en el rendimiento de su código base. En sus inicios, tanto las aplicaciones cliente de escritorio como el backend del servidor estaban escritos íntegramente en Python, un lenguaje que permitió al equipo de ingeniería inicial construir e iterar con rapidez. Sin embargo, gestionar millones de conexiones activas sometió al modelo de ejecución de Python a una fuerte presión. En julio de 2014, Dropbox comenzó a migrar su infraestructura de backend crítica para el rendimiento al lenguaje Go. El cambio a Go permitió a los ingenieros gestionar un volumen masivo de tráfico concurrente con mucha mayor eficiencia, al tiempo que redujo el consumo de CPU y memoria.

La construcción de Magic Pocket

Junto con la reescritura de su software de backend, Dropbox abordó un cuello de botella crítico en su infraestructura. Desde sus comienzos, la plataforma había dependido por completo del almacenamiento Amazon S3 para albergar los archivos de los usuarios. Sin embargo, a medida que los datos guardados alcanzaban escalas gigantescas, alojar todo en servidores de terceros planteaba serias limitaciones técnicas y de costes a largo plazo. Entre 2014 y 2016, Dropbox migró sus datos principales desde Amazon S3 hacia una plataforma de hardware personalizada llamada Magic Pocket. Diseñar su propia arquitectura de almacenamiento otorgó a la empresa un control directo sobre el diseño de los servidores, la densidad de disco y la gestión de datos. Al independizarse de las infraestructuras en la nube de terceros mediante su hardware Magic Pocket entre 2014 y 2016, Dropbox consolidó su capacidad para escalar el almacenamiento de archivos de forma autónoma para cientos de millones de usuarios.

Imagen de portada: ilustración generada con IA; no es una fotografía documental.

Fuente: History of Dropbox