Habitat, el almacenamiento de OpenAI: 70 millones de peticiones por segundo

OpenAI ha contado cómo escala el almacenamiento que sostiene sus productos. Habitat, su plataforma de almacenamiento online, atiende más de 70 millones de peticiones por segundo para más de 1.000 millones de personas cada semana, guarda más de 500 petabytes y corre en casi 40 regiones geográficas. Nació a mediados de 2024 como una librería de Python y hoy es un servicio distribuido con entidad propia.

De librería a servicio

La idea inicial era sencilla: quien desarrolla producto no debería pensar en gestión de bases de datos. Habitat empezó como una librería de Python que hablaba directamente con Azure Cosmos DB, la base de datos que hay debajo. Se ocupaba del esquema, el enrutado, la autorización, el cifrado, la serialización, la conformación de peticiones y el pooling de conexiones, y ocultaba también de dónde venían los datos: Cosmos DB, cachés u otros almacenamientos. Los equipos podían incluso añadir soporte para caché en cliente, compresión o cifrado a la librería compartida sin montar nada aparte.

El problema llegó con el tamaño. A mediados de 2025 la implementación en cliente había tocado techo: los cambios de protocolo compatibles hacia atrás dejaron de ser viables y cada modificación obligaba a coordinarse con decenas de servicios. OpenAI cuenta un caso concreto. Para repartir datos críticos entre varias cuentas de Cosmos DB distribuidas por regiones había que meter lógica de enrutado en el cliente detrás de un feature flag, desplegarla en todos los clientes, añadir shadowing para comprobar que el sharding estaba bien, corregir después un fallo detectado... días en cada paso. Cuando por fin iban a activar la bandera, un equipo hizo rollback de su servicio por motivos ajenos a una versión antigua del cliente con el bug, y provocaron justo la caída que llevaban semanas intentando evitar.

La salida fue sacar Habitat del cliente y convertirlo en un servicio independiente. Con la lógica de almacenamiento aislada, OpenAI se queda con un único punto de control para despliegues, observabilidad y mejoras de plataforma: en vez de perseguir actualizaciones fragmentadas por toda la casa, aplica los cambios en un sitio y los hereda cada producto.

Queda el detalle incómodo: el servicio está escrito en Python, un lenguaje poco habitual para servir cargas de este tipo, y el crecimiento ha sido de más de 10x interanual durante tres años seguidos. El propio texto lo enmarca como una sucesión de decisiones tácticas, exprimiendo cada componente para esquivar los cuellos de botella de capacidad mientras se preparaba la inversión de fondo.

Esta es la primera de dos entregas. La segunda promete entrar en la fiabilidad multi-tenant a escala, en la estrategia por capas para optimizar lecturas y en cómo han escalado el uso de Azure Cosmos DB. Para quien opera almacenamiento distribuido, el interés de esta primera parte no está en las cifras sino en el patrón: una librería compartida se convierte en una trampa operativa cuando el número de consumidores crece, y el momento de partirlo en un servicio llega antes de lo que parece.