Cloudflare ha rediseñado el plano de control de D1 para gestionar millones de bases de datos sin convertir su infraestructura central en un cuello de botella. La arquitectura separa las operaciones de gestión —como crear bases de datos, mantener sus metadatos y controlar límites— de la ruta que procesa las consultas, que sigue ejecutándose cerca de las aplicaciones en la red de Cloudflare.
El cambio responde a un aumento de escala significativo: según lo publicado sobre el rediseño, el número de bases de datos D1 activas a diario creció 18 veces durante el último año. En lugar de concentrar cada operación en una base de datos central, Cloudflare distribuye funciones entre PostgreSQL, ClickHouse, Workers KV y distintos componentes de Workers, con tareas asíncronas y datos que pueden actualizarse de forma eventual.
Gestión centralizada, consultas en el borde
D1 es una base de datos SQL sin servidor construida sobre SQLite y diseñada para ejecutarse cerca de las aplicaciones en la red global de Cloudflare. En esta arquitectura, el plano de control administra y coordina recursos; el plano de datos es el que atiende las consultas. Mantener separados ambos recorridos evita que cada consulta tenga que depender de la base de datos central de metadatos.
Las peticiones pasan por un Edge API Worker, que se ocupa de la autenticación, la autorización, la limitación de solicitudes y la validación. Después, un Eyeball Worker las dirige al Durable Object correspondiente a la base de datos D1. Según la descripción del diseño, este componente confía en la autorización específica de la base de datos incluida en los D1 Bindings, en vez de repetir las comprobaciones en la ruta de consulta.
Así, PostgreSQL no tiene que intervenir en cada lectura o escritura de las aplicaciones. Su función principal en el control de D1 es conservar metadatos transaccionales y actuar como fuente de verdad sobre la existencia de las bases de datos y los límites de las cuentas. ClickHouse se utiliza para analítica, mientras que Workers KV guarda información de enrutamiento replicada globalmente.
Reconciliación para recuperarse de operaciones fallidas
Una operación de creación o eliminación puede quedar a medio completar si falla una parte del proceso. Para corregir esas inconsistencias, los Durable Objects envían señales periódicas —heartbeats— a PostgreSQL cada 30 segundos, con variaciones de tiempo por base de datos para repartir las comprobaciones. El proceso contrasta el estado del objeto con la fuente de verdad.
Si queda un objeto huérfano después de eliminar una base de datos, puede marcarse como eliminado. Si una actualización de los datos de enrutamiento de Workers KV no llega a completarse, el mecanismo permite reparar esa información. La reconciliación no exige que cada paso distribuido termine al mismo tiempo: admite que algunos datos estén temporalmente desactualizados y los corrige en comprobaciones posteriores.
Para estas lecturas, Cloudflare puede apoyarse en varias capas de caché de Hyperdrive o en una réplica de lectura de PostgreSQL. La tolerancia a cierta antigüedad de los datos resulta útil en tareas de control como esta, siempre que el estado se vuelva a contrastar y converja con la fuente de verdad. No es el mismo requisito que atender una consulta de usuario con datos plenamente actualizados.
Por qué Workers KV no es solo otra caché
Workers KV almacena las rutas necesarias para localizar las bases de datos. Aunque Hyperdrive también ofrece caché, la descripción del diseño distingue ambos papeles: KV es un almacén duradero, no únicamente una capa de aceleración. Si un dato sale de la caché de borde, la lectura puede servirse desde el almacenamiento de KV sin recurrir a PostgreSQL.
Esta diferencia importa ante una pérdida amplia de caché. Si millones de bases de datos tuvieran que pedir a la vez sus datos de enrutamiento directamente a PostgreSQL, el pico podría sobrecargar el componente central y agravar el fallo. Mantener una fuente duradera distribuida reduce esa dependencia en la ruta de recuperación, aunque no elimina la necesidad de sincronizar y reparar los metadatos.
Límites de almacenamiento sin concentrar las escrituras
El control de cuotas también se ha adaptado al volumen. D1 actualiza el uso de almacenamiento de forma asíncrona: agrupa las actualizaciones antes de escribirlas en PostgreSQL, con el objetivo de evitar picos de escrituras. Además, mantiene totales agregados por cuenta mediante incrementos y reducciones del almacenamiento, en vez de recorrer todas las bases de datos para calcularlos cada vez.
Los Durable Objects consultan esos totales mediante una caché de corta duración en Hyperdrive y bloquean escrituras que superarían el límite de la cuenta. El enfoque evita que una cuenta con muchas bases de datos obligue a realizar cálculos costosos o genere contención de escrituras en PostgreSQL. Al mismo tiempo, combina actualizaciones diferidas con decisiones de control sobre las escrituras, una distinción necesaria para operar a escala sin trasladar todo el trabajo de recuento al sistema central.
Qué cambia para quienes construyen sobre D1
El rediseño se centra en la capacidad operativa de la plataforma: distribuir metadatos, aislar las consultas de las tareas administrativas y recuperarse de fallos parciales. No implica por sí solo que cada aplicación obtenga consultas más rápidas; el beneficio descrito es que el plano de control puede administrar más bases de datos sin que cada petición dependa de PostgreSQL.
La arquitectura también muestra el coste de operar un servicio con muchos recursos pequeños: el reto no consiste solo en ejecutar consultas, sino en mantener inventarios, rutas, límites y estados coherentes entre sistemas distribuidos. Cloudflare anunció D1 en 2022, y este rediseño aborda precisamente esa capa de coordinación a medida que crece su uso. Los detalles técnicos fueron difundidos por InfoQ en su cobertura del rediseño del plano de control de D1.
