Cursor cambia el almacenamiento de Git: un WAL en S3 en lugar de coordinar réplicas
La compañía publica Continuity, una arquitectura que convierte S3 en la fuente de verdad durable de los repositorios y deja el NVMe local como caché. Reporta más de 300 pushes por segundo.
Cursor ha publicado Continuity, una arquitectura de almacenamiento Git en la que un write-ahead log (WAL) alojado en S3 es la fuente de verdad durable, en lugar de usar la coordinación entre réplicas como mecanismo de consistencia. En sus pruebas sintéticas la compañía reporta escalado lineal de lecturas con hasta 100 réplicas y más de 300 pushes por segundo sobre S3 Express One Zone.
El modelo de referencia hasta ahora era otro. GitHub, con su arquitectura Spokes, mantiene varias réplicas en NVMe y usa commit en tres fases para actualizar referencias: las réplicas se mantienen sincronizadas y cualquier nodo puede servir lecturas, pero el coste de coordinación crece con cada réplica que se añade. Continuity ataca justo ese punto.
Cómo funciona
Cuando llega un push, los datos van a S3 y la actualización de referencia correspondiente se anota en el WAL. El push solo se da por confirmado después de que lo necesario esté persistido, así que la durabilidad precede al acuse de recibo. Para que la latencia de los PUT de S3 no se coma el rendimiento, las operaciones se agrupan en lotes.
El ingeniero de Cursor Vicent Martí describe los repositorios locales en NVMe como cachés calientes, no como copias autoritativas. El enrutado se resuelve con rendezvous hashing para elegir nodos preferidos, y las operaciones atómicas de compare and swap sobre S3 permiten que cualquier servidor acepte un push. Si no hay copia local, el repositorio se puede materializar desde el WAL. Las actualizaciones del WAL se propagan por gossip sobre UDP y las lecturas condicionales contra S3 verifican el estado de las réplicas; según la compañía, esas lecturas tardan menos de 10 milisegundos de media, y perder un mensaje de gossip no rompe la corrección porque S3 sigue siendo la fuente de verdad.
El enfoque ha generado comparaciones con el mundo de las bases de datos. Maksim Al Dandan, ingeniero sénior, lo describió como tratar el almacenamiento de Git como una base de datos, y señaló la consistencia de los push, las transacciones de force-push y la recuperación a un punto en el tiempo como las preguntas que abre el modelo. Casey Lee, CTO de Liatrio y ex ingeniero de AWS, subrayó el cambio arquitectónico y avisó de que las cifras de rendimiento publicadas no han sido verificadas por terceros. Son datos de Cursor, no de un medidor independiente.
Qué cambia al operar
Solo el primario ejecuta la compactación de Git; las réplicas se descargan los packs resultantes desde S3, un intercambio de CPU por ancho de banda. Según Cursor, los monorepos pueden sostener cientos de réplicas para CI, mientras que los repositorios inactivos se materializan bajo demanda. En las pruebas con su monorepo everysphere, la compañía mide hasta 120 pushes por segundo con S3 Standard y más de 300 con S3 Express One Zone; a ese ritmo el cuello de botella pasa a ser la compactación.
La consecuencia de fondo es que la frontera de consistencia se mueve de la capa de réplicas al almacenamiento de objetos durable. En vez de sincronizar sincrónicamente más nodos, los repositorios locales convergen por su cuenta hacia el estado que vive en S3. Se gana escalado de lecturas y de réplicas, y se paga con validaciones contra el object storage, propagación asíncrona y más tráfico de red. Queda por ver si el modelo aguanta cargas reales fuera del banco de pruebas de quien lo diseñó.
