Escalar el almacenamiento para más de mil millones de usuarios de ChatGPT (parte II)

Todos los productos de OpenAI necesitan un acceso rápido y confiable a los datos, que proporciona nuestra plataforma de almacenamiento, Habitat. Debe responder en milisegundos a más de mil millones de usuarios en 40 regiones geográficas. Nuestra infraestructura enfrentaba un desafío extraordinario: sostener un crecimiento explosivo y nuevos casos de uso mientras seguíamos mejorando la confiabilidad, el rendimiento y la velocidad de trabajo de los desarrolladores de productos. Resolver ese desafío exigió replantear el diseño y la operación de nuestra plataforma de almacenamiento en línea. Evaluábamos constantemente las ventajas y desventajas, siguiendo este orden: primero, lograr la confiabilidad necesaria para el tráfico crítico de los productos; después, la velocidad necesaria para usuarios de todo el mundo; y, finalmente, operar con agilidad a escala masiva.

Esta serie de dos partes explica cómo transformamos Habitat de una simple biblioteca cliente y una base de datos en una plataforma de almacenamiento distribuida globalmente que sirve más de 500 petabytes de datos. La parte I se centró en la evolución de Habitat de un cliente de Python a un servicio. También abordó las técnicas que nos permitieron llevar un servicio basado en Python mucho más allá de lo que muchos considerarían viable.

En esta publicación, la parte II, explicamos cómo escalamos el componente de almacenamiento subyacente: Azure Cosmos DB. Gracias a una estrecha colaboración con el equipo de Azure, llegamos a un enfoque multiinquilino viable con contenedores administrados conjuntamente y un excelente rendimiento de lectura a escala masiva y global.

A medida que las empresas crecen, los equipos de infraestructura suelen pasar de operar sistemas de inquilino único a sistemas multiinquilino. En la arquitectura de inquilino único, cada equipo responsable de un área del producto mantiene su propio sistema. Esto reduce el alcance de las fallas, permite delimitar fácilmente las responsabilidades y aísla las cargas de trabajo. A medida que crecen los equipos y las áreas del producto, operar así se vuelve costoso. La arquitectura de inquilino único hace que cada equipo de producto sea responsable de planificar la capacidad y suele dar lugar a un sobreaprovisionamiento considerable.

Por el contrario, la arquitectura multiinquilino asigna el control a un equipo centralizado de bases de datos, con más conocimientos y experiencia para aprovisionar recursos. Pero esta arquitectura genera sus propios problemas, como los vecinos ruidosos: un inquilino consume una proporción inusualmente alta de los recursos en perjuicio de los demás.

En Habitat, tuvimos que sopesar todas estas ventajas y desventajas para diseñar un sistema de almacenamiento confiable y eficiente a gran escala. Hoy, Habitat es una capa de base de datos multiinquilino para muchos productos de OpenAI, pero recorrimos un camino circular: pasamos de usar un contenedor multiinquilino de Azure Cosmos DB a aprovisionar contenedores de almacenamiento de inquilino único, para luego volver a un contenedor multiinquilino de forma predeterminada. Aún estamos en las primeras etapas de la arquitectura multiinquilino de Habitat: admitimos una gran variedad de casos de uso, pero hemos podido postergar la inversión en esta área aprovechando las primitivas integradas de Azure Cosmos DB siempre que es posible.

Antes de repasar nuestro recorrido con Azure Cosmos DB, un poco de contexto básico:

• Una cuenta de Azure Cosmos DB define un conjunto de contenedores y una política de replicación

• Cada contenedor se aprovisiona para un determinado rendimiento en unidades de solicitud por segundo (RU/s)

• Los datos de cada contenedor se almacenan mediante la fragmentación habitual según una clave de partición lógica especificada, con límites documentados de almacenamiento y rendimiento por clave de partición lógica

• Azure Cosmos DB distribuye las claves de partición lógica entre una cantidad menor de particiones físicas subyacentes. Estas se dividen en varias particiones físicas cuando el almacenamiento supera un umbral o cuando el contenedor necesita más particiones físicas para sostener el rendimiento aprovisionado

Al principio, dejábamos pasar cualquier carga de los clientes y confiábamos en el límite indicado de 10 000 RU/s por clave de partición lógica para ejercer contrapresión. Al comenzar, también usábamos un solo contenedor predeterminado de Azure Cosmos DB en cada cuenta. Esto funcionó razonablemente bien, pero resultó problemático por varias razones:

Debido a decisiones tempranas sobre la API, permitimos que los clientes seleccionaran directamente la clave de partición lógica. Como resultado, tenemos colisiones frecuentes en claves de partición de uso común, como user_id o workspace_id, entre distintos casos de uso de productos. Como estos casos de uso compartían los límites de Azure Cosmos DB sobre las mismas claves de partición lógica, el diseño restringía el rendimiento total para un usuario determinado.

Un problema común al escalar Postgres, antes de migrar a Habitat y Azure Cosmos DB, era que muchas solicitudes de una organización o clave con actividad muy intensa, un inquilino que generaba una carga desproporcionadamente alta, podían provocar la caída de toda la base de datos. Dedicamos un esfuerzo colectivo considerable a almacenar esas claves en caché y a incorporar concesiones temporales de acceso ante fallos de caché, para que la carga resultante no saturara la base de datos subyacente.

Aunque los límites documentados de tamaño de datos y rendimiento se aplican a las claves de partición lógica, en realidad se hacen cumplir en la partición física. En la práctica, esto significa que las particiones lógicas no pueden alcanzar las 10 000 RU/s. En cambio, comparten los límites de la partición física con todas las demás claves de partición lógica alojadas en ella.

Esto permitía que los vecinos ruidosos afectaran a muchas claves de partición lógica sin relación entre sí: cargas de trabajo que operaban sobre datos de funciones de producto de nicho interrumpían los flujos básicos de inicio de sesión y registro.

El límite de rendimiento de una partición física también es variable y depende del rendimiento total asignado al contenedor de Azure Cosmos DB. El rendimiento aprovisionado del contenedor se distribuye de forma aproximadamente uniforme entre sus particiones físicas.

A medida que crece el volumen de datos, las particiones físicas se dividen y aumenta su cantidad total, mientras que el rendimiento total aprovisionado no cambia. Como resultado, el límite efectivo de rendimiento por partición disminuye a medida que crece el tamaño de los datos.

En nuestros casos de uso con mayor demanda de almacenamiento, similares a los de blobs, esto crea un modo de falla en el que el crecimiento del almacenamiento por sí solo reduce la capacidad de rendimiento de las cargas activas, incluso si las tasas de solicitudes y el uso se mantienen estables.

Usar contenedores separados ayuda a resolver parcialmente estos límites de las claves de partición y los problemas de vecinos ruidosos. Al usar contenedores separados, cada uno puede tener sus propias particiones físicas independientes. Así, solo las distintas cargas de ese mismo contenedor podrían actuar como vecinos ruidosos o superponerse en el espacio de claves de partición. La desventaja es que aprovisionar nuevos contenedores tiene un costo operativo: cada uno requiere una planificación de capacidad individual. Por eso, queremos crear contenedores solo cuando tenga sentido separar un servicio o caso de uso.

Comenzamos a usar contenedores de Azure Cosmos DB separados para los nuevos casos de uso más críticos que requerían un aislamiento sólido. Combinamos esto con un script para gestionar las particiones débiles, que sincronizaba el rendimiento total aprovisionado de cada contenedor con su cantidad de particiones físicas. Así logramos evitar casi todos los problemas que enfrentábamos.

Sin embargo, como habíamos comenzado con un contenedor predeterminado, lamentablemente muchos casos de uso críticos heredados quedaron atrapados allí hasta que se migraran sus datos. Para proteger los servicios críticos que aún dependían de los datos del contenedor compartido predeterminado, solíamos recomendar a los equipos que crearan contenedores separados para nuevos servicios o funciones importantes del producto. A medida que crecíamos, aumentaba la presión sobre el contenedor predeterminado y también los incidentes en producción. Comenzamos a aprovisionar contenedores para cualquier servicio nuevo o función importante del producto, solo para evitar que el contenedor predeterminado recibiera más carga.

Esto nos evitó muchas caídas de todo el sitio y limitó el impacto a interrupciones que degradaban funciones o servicios específicos. Sin embargo, con el tiempo, el costo operativo de aprovisionar nuevos contenedores empezó a pasarnos factura:

En el antiguo contenedor compartido predeterminado, era poco probable que un caso de uso nuevo que pasara de 0 QPS a 1 millón de QPS cambiara significativamente el uso total agregado. En cambio, en un contenedor aislado, un caso de uso nuevo que pasara de 0 a 1 millón de QPS podía representar una carga 1000 veces mayor que la base generada únicamente por las pruebas internas del producto.

Con contenedores dedicados, los equipos debían recordar aprovisionarlos con anticipación para el nivel de rendimiento esperado en sus lanzamientos. A menudo, los equipos de producto lanzaban sus funciones a producción y olvidaban ampliar la capacidad antes. El día del lanzamiento, terminábamos en salas de gestión de incidentes graves intentando ampliar los contenedores a último momento.

Combinar cargas de trabajo es una ventaja central de los sistemas multiinquilino que perdemos a cambio de un mejor aislamiento con esta estrategia de contenedores.

Con el tiempo, monitorear el uso de los contenedores dedicados también exigía un conocimiento profundo del producto para saber cuándo cambiaría o crecería el tráfico.

Podemos ofrecer un script básico del plano de control para aumentar el rendimiento aprovisionado de cada contenedor según las tendencias de crecimiento. Pero sin un crecimiento agregado estable, escalarlos correctamente implicaba que prácticamente todos los equipos de producto de OpenAI participaran en la planificación de capacidad.

Esto no logró escalar a nivel organizacional, ya que la atención que cada equipo responsable de un servicio prestaba al aprovisionamiento de Azure Cosmos DB variaba mucho.

A medida que la organización crecía, esos problemas operativos dificultaban el escalamiento. La ausencia de un único equipo central de planificación hizo que muchos equipos planificaran mal. Por eso, terminamos volviendo a una solución multiinquilino y colaboramos estrechamente con el equipo de Azure para resolver nuestros problemas originales mediante un diseño de uso compartido entre inquilinos:

Limitar primero las solicitudes de las claves con mayor actividad evita que los vecinos ruidosos consuman todo el rendimiento disponible de una partición física. Esto reduce el efecto de los vecinos ruidosos, por el cual una sola clave con alta actividad puede afectar a todo el sitio.

Del mismo modo, la QoS que clasifica las solicitudes por niveles impide que las cargas sin conexión, como las inserciones masivas o las extracciones de datos, consuman todo el rendimiento de una partición física. Al asignar una prioridad menor a las solicitudes de estas cargas, se limitan primero. Así se evita limitar las solicitudes interactivas de mayor prioridad que atienden a los usuarios finales.

Azure Cosmos DB ya tenía un modo sin servidor que habría resuelto nuestro problema de particiones débiles en el modo aprovisionado. Sin embargo, tenía una gran desventaja: escalaba solo según el uso de almacenamiento y limitaba el uso de RU a 5000 RU/s por partición física. Esto resolvería el problema de las particiones débiles, pero nos impediría escalar los casos de uso con alto consumo de RU.

El equipo de Azure Cosmos DB creó para nosotros un nuevo modo sin servidor mejorado, que permitía escalar cada partición física hasta 10 000 RU/s e incorporaba divisiones basadas en el uso de RU, además de las basadas en el uso de almacenamiento. Esto nos permitió dejar de monitorear y ampliar los contenedores manualmente.

Con estos cambios, pudimos volver a usar un solo contenedor compartido. Esto simplificó considerablemente la planificación de capacidad, tanto inicial como continua, para los equipos de producto, sin perder el aislamiento entre cargas de trabajo. En los meses transcurridos desde entonces, no hemos tenido incidentes de aprovisionamiento ni de vecinos ruidosos, a pesar de la aceleración del desarrollo de productos.

Cuando las empresas alcanzan la escala de OpenAI, los servicios administrados se vuelven menos "administrados". Muchas cargas de trabajo se convierten en casos atípicos dentro de la infraestructura del proveedor de nube. A medida que OpenAI se convirtió en uno de los mayores usuarios de Azure Cosmos DB, operarlo con éxito exigió un enfoque distinto: pruebas y paneles compartidos, canales directos entre equipos de ingeniería y responsabilidad conjunta sobre los modos de falla que solo aparecen a nuestra escala. Hoy, nuestra mayor cuenta de Azure Cosmos DB almacena decenas de petabytes de datos y atiende más de 20 millones de QPS. Hasta donde sabemos, somos la única empresa que ha implementado Azure Cosmos DB a esta escala.

A fines de 2024, una interrupción regional dejó claro por qué esta colaboración era necesaria. En ese momento, un corte de energía afectó la región principal de Azure de una de nuestras mayores cuentas de Azure Cosmos DB. Durante la conmutación por error que siguió, descubrimos que nuestras mayores cuentas tardarían varias horas en pasar a una región secundaria, algo que ni nuestro equipo ni el de Azure Cosmos DB habían probado a nuestra escala.

Aproximadamente un mes después, al devolver esas cuentas a la región original, provocamos otra interrupción grave. Una avalancha de conexiones hacia la región original saturó su puerta de enlace de Azure Cosmos DB. Una particularidad de cómo el cliente de Azure Cosmos DB en modo de puerta de enlace gestionaba las conmutaciones por error hizo que todos los clientes establecieran conexiones y enviaran solicitudes a la región original de inmediato, aunque solo una parte de las particiones físicas había regresado a esa región.

En cada interrupción, tanto OpenAI como Azure siguieron sus procesos de gestión de incidentes, identificaron varias causas raíz e implementaron correcciones. Pero estas interrupciones eran síntomas de un problema sistémico más amplio en la forma en que nuestro equipo y el de Azure Cosmos DB operaban y realizaban pruebas. Al principio, aprovechar los servicios administrados nos permitió avanzar rápido y enfocarnos en los objetivos del negocio. A gran escala, los servicios administrados dejan de serlo tanto y requieren una integración profunda con el proveedor en todos los niveles, desde el diseño hasta las operaciones.

Hoy, los equipos de ingeniería de Habitat y Azure monitorean conjuntamente cada capa de Habitat, desde nuestras capas de servicio hasta las capas de almacenamiento físico de Azure Cosmos DB. Operamos y probamos cambios en una cuenta de Azure Cosmos DB del tamaño de la de producción, pero fuera de producción. Probamos e iteramos sobre los SDK en conjunto y definimos las mejores prácticas para escalar y dimensionar nuestras cuentas de Azure Cosmos DB. Tenemos contacto directo entre los equipos de ingeniería a través de Teams e incluso habilitamos formas de alertarnos directamente, sin pasar por los distintos niveles de soporte.

Durante el último año, realizamos un importante trabajo conjunto para mejorar la escalabilidad del plano de control y la puerta de enlace de Azure Cosmos DB. Agregamos protección contra sobrecargas y almacenamiento en caché de diversos metadatos de Azure Cosmos DB en su puerta de enlace para proteger la partición de metadatos. Redujimos la presión de nuestra flota de procesos habitat-service de Python mediante la agrupación y una mayor reutilización de conexiones, ubicamos las cargas de trabajo en el mismo lugar cuando fue posible y aislamos las cargas críticas de las cargas sin conexión mediante distintas VPC.

Este nivel de ingeniería conjunta ha sido fundamental para la estabilidad de nuestro Azure Cosmos DB durante el último año. Cualquier sistema lo suficientemente grande o crítico requiere este tipo de trabajo en equipo: derribar las barreras entre responsables y trabajar más allá de los límites organizacionales.

Como mencionamos en la parte I, nuestra filosofía central es: hacer que funcione, que sea rápido y que sea económico. Primero la confiabilidad, luego el rendimiento y después la eficiencia. Habitat se había convertido en infraestructura crítica para OpenAI, por lo que la primera prioridad era hacerlo confiable. A medida que el sistema se estabilizó en 2025 y OpenAI se expandió globalmente, la latencia se convirtió en la siguiente limitación para los usuarios y los equipos de producto.

La capacidad de cómputo y la de almacenamiento solían estar en distintas regiones, lo que hacía inevitables las solicitudes entre regiones.

La latencia variaba mucho según dónde se almacenaban los datos y dónde se atendía la solicitud. Para que las solicitudes de Habitat tuvieran buen rendimiento, los desarrolladores de productos recurrían a más caché del lado del cliente, agrupaban solicitudes, minimizaban las lecturas y escrituras en la base de datos y sacaban tareas de la ruta crítica siempre que era posible. Si bien esto dio lugar a diseños de producto interesantes y más resistentes a los problemas de la base de datos, también aumentó la complejidad de los productos y ralentizó su iteración. Esto contradecía el objetivo de Habitat: facilitar el desarrollo rápido de productos sin necesidad de entender la base de datos.

Este ha sido uno de nuestros principales focos en 2026. Desarrollamos una estrategia por capas para optimizar el rendimiento de las lecturas, que representan más del 90 % de las solicitudes de Habitat:

Tenemos varias cuentas de Azure Cosmos DB en distintas regiones de Azure en todo el mundo para usuarios con requisitos de residencia de datos. Incluso para los usuarios sin requisitos estrictos de residencia de datos, ubicar los datos cerca de ellos mejora su experiencia al reducir la latencia.

En la práctica, no podemos hacerlo de forma generalizada fuera de los casos de uso de residencia de datos, porque la ubicación está limitada por la capacidad física de la nube. Debido al tamaño de nuestros conjuntos de datos, muchas regiones no pueden alojar el enorme volumen de almacenamiento necesario para la proporción de tráfico de usuarios que les corresponde.

En regiones con capacidad limitada de centros de datos, energía o refrigeración, a veces debemos elegir entre reservar capacidad para almacenamiento en la misma ubicación y reducir la latencia de Habitat, o usarla para cómputo adicional que atienda solicitudes y dirigir las solicitudes de almacenamiento a lugares más lejanos.

Por eso, las decisiones de ubicación suelen exigir un equilibrio a nivel de producto entre: a) optimizar la latencia para distintos productos y grupos de usuarios, y b) la capacidad bruta de almacenamiento y cómputo.

Para las cargas de trabajo donde la latencia es más crítica, como los metadatos de autenticación necesarios en cada solicitud, reducimos el tiempo de ida y vuelta (RTT) entre los recursos de cómputo y Habitat mediante cuentas de Azure Cosmos DB con alta replicación en muchas regiones secundarias. Algunas cuentas se replican en las 40 regiones de Azure donde atendemos tráfico; otras, en al menos una región por continente.

Tuvimos que incorporar a Habitat una capa transparente de movimiento y enrutamiento de datos antes de lo previsto para poder mover conjuntos de datos entre cuentas con distintas topologías de replicación.

Sin embargo, este enfoque también está limitado por la capacidad y, por lo tanto, se aplica solo a unos pocos conjuntos de datos seleccionados cuidadosamente.

Las cargas de Habitat son predominantemente de lectura: las aplicaciones consultan constantemente configuraciones, estados y otras propiedades. Una proporción desmedida del tráfico corresponde a un conjunto de trabajo relativamente pequeño de tipos de datos consultados con frecuencia. Esto hace que el sistema sea especialmente adecuado para el almacenamiento en caché distribuido. Si bien la caché mejora el rendimiento en una infraestructura de una sola región, los beneficios se multiplican al trabajar entre regiones, donde puede usarse para "ocultar" la latencia entre ellas.

Integramos en Habitat una capa de caché distribuida de consulta lateral (lookaside). Almacena una copia de los objetos y las aristas consultados recientemente en servidores Valkey de nuestra infraestructura, cerca de donde se procesan las solicitudes de los usuarios. Por lo general, estas cachés usan un tiempo de vida (TTL) que busca equilibrar la tasa de aciertos y la desactualización. Los TTL cortos reducen la desactualización, pero limitan el beneficio de la caché, porque los elementos vencen rápidamente y deben recuperarse con más frecuencia. Los TTL más largos mejoran las tasas de aciertos, pero devuelven datos desactualizados durante más tiempo, lo que perjudica la experiencia del usuario y genera comportamientos impredecibles en el producto.

Otro enfoque consiste en ejecutar invalidaciones explícitas cuando la aplicación realiza operaciones de escritura sobre los mismos datos subyacentes. Esto mantiene los datos en caché mucho más actualizados, pero puede ser difícil de implementar correctamente. También sigue expuesto a varios casos extremos, como fallas parciales, que dejan la caché desactualizada. Las implementaciones multirregión agravan estos problemas: las redes entre regiones son menos confiables y se generan condiciones de carrera entre la caché y la replicación del almacenamiento subyacente. Complementar esto con TTL limita la desactualización máxima, pero mantiene el mismo dilema de los TTL descrito antes.

Adoptamos un enfoque más avanzado de invalidación, siguiendo los pasos de sistemas como TAO de Meta. La caché integrada de Habitat usa la captura de datos de cambios (CDC) mediante la fuente de cambios de Azure Cosmos DB para propagar invalidaciones globalmente en segundos. Así logra altas tasas de aciertos con poca desactualización. Un servicio de nuestra infraestructura consume esta fuente de cambios y ejecuta invalidaciones en las cachés locales cuando se actualizan los datos subyacentes. Esto provoca un fallo de caché en la siguiente lectura, y la caché se llena con la versión más reciente de los datos.

También redujimos significativamente la latencia al eliminar sobrecarga del propio servicio de Habitat mediante la reescritura del código en Rust, que ofrece mayor rendimiento que el Python original.

En conjunto, estos cambios redujeron nuestro p50 general de lectura a nivel global de unos 120 ms a unos 10 ms: una mejora de 12 veces desde que comenzamos a enfocarnos en el rendimiento a principios de este año.

Aunque la caché redujo drásticamente la mediana de latencia, las solicitudes más lentas aún requieren recuperar datos no almacenados en caché desde el almacenamiento subyacente, a menudo en regiones lejanas. A medida que se habilite más capacidad y mejoremos la eficiencia del almacenamiento, planeamos abordar un desafío más fundamental: ubicar los datos desde el inicio cerca de donde se consultarán.

Una CDC confiable y escalable, que propaga los cambios de la base de datos a los sistemas posteriores, es fundamental no solo para la estrategia de caché de Habitat. Millones de cambios capturados por segundo, en miles de contenedores y millones de particiones, pasan por más de cien temas de Kafka. También alimentan índices secundarios con consistencia eventual, canalizaciones de movimiento de datos, análisis sin conexión y otras funciones de producto en tiempo real. A medida que nuestra infraestructura subyacente se expandió globalmente, escuchar los cambios en las filas se volvió cada vez más complejo. Si un cliente quiere registrar una función de devolución de llamada que se ejecute cada vez que cambien filas de su tipo, primero debe determinar, entre otras cosas, qué cuentas y contenedores de Cosmos contienen sus datos, qué implementación del servicio CDC escucha esos contenedores en las regiones correspondientes y cómo escalar correctamente la flota de trabajadores de CDC, Kafka y su consumidor. Nuestra plataforma CDC busca ocultar toda esta complejidad a los desarrolladores de productos y ofrecer una interfaz simple donde los clientes registren una función que se invoque cuando cambien sus filas. Nosotros nos encargamos de toda la infraestructura y el escalamiento.

Un plano de control interno verifica continuamente que se capturen los cambios de todos los contenedores necesarios, selecciona las regiones de Cosmos desde las que leer y distribuye el trabajo eficientemente entre miles de trabajadores en varias regiones geográficas. Usar regiones de réplica y lecturas de la fuente de cambios con menor prioridad protege el tráfico de Habitat sensible a la latencia frente a las cargas de captura en segundo plano. En una flota tan grande, se producen continuamente caídas de trabajadores, problemas de contenedores, errores del almacén de concesiones, configuraciones inválidas y fallas de destino. Reforzamos el ciclo de vida de los trabajadores de CDC y la gestión de concesiones, aislamos las fallas entre flujos e incorporamos protecciones para los cambios de configuración y los despliegues. Usamos colas de mensajes no entregados para evitar que las fallas permanentes de entrega bloqueen el inicio de la cola. Toleramos interrupciones regionales al cambiar los lectores a regiones alternativas de Cosmos. A nuestra escala, incluso tuvimos que modificar el SDK de CDC de Azure para hacer más eficiente su implementación de puntos de control: los agrupamos en memoria y los guardamos de forma persistente solo periódicamente.

Aunque el uso interno de Azure Cosmos DB en Habitat es complejo, su propuesta de valor siempre ha sido ocultar los detalles de infraestructura a los desarrolladores de productos para acelerar su trabajo. Nuestra plataforma CDC sigue el mismo principio.

Un equipo pequeño pudo sostener una plataforma de almacenamiento en rápido crecimiento al mantener deliberadamente acotada la API de almacenamiento, seguir escalando el servicio de Python y priorizar los desafíos de ingeniería más urgentes. Nos enfocamos primero en la confiabilidad para el tráfico crítico de los productos, luego en el rendimiento de lectura para usuarios de todo el mundo y, por último, en la eficiencia operativa a gran escala. Este enfoque permitió un crecimiento rápido y nuevos casos de uso, al tiempo que mejoró la confiabilidad, el rendimiento y la velocidad de desarrollo de productos.

Para escalar Habitat y el almacenamiento de conversaciones para los próximos mil millones de usuarios, debemos resolver la dificultad de replicar nuestros datos en toda nuestra infraestructura a una escala aún mayor. Para anticiparnos, estamos desarrollando internamente un sistema propio de almacenamiento en línea a escala de exabytes, optimizado para los tipos de datos voluminosos de Habitat. Este sistema en desarrollo combina el núcleo RocksDB Cloud de Rockset con replicación basada en Raft. Implementa el mismo modelo de documentos que Azure Cosmos DB, pero usa almacenamiento desagregado y replicación física para reducir la capacidad flash necesaria, a cambio de un menor pico de QPS.

Si te interesa trabajar en este tipo de iniciativas de infraestructura de datos a una escala de vanguardia, consulta nuestras vacantes⁠.