El problema fundamental que Quicksilver resuelve es la distribución global y consistente de datos de configuración críticos con latencias de lectura extremadamente bajas. En arquitecturas distribuidas a escala de hyperscaler, la configuración (flags de características, tablas de ruteo, ajustes de agentes) debe estar disponible instantáneamente en cada punto de presencia (PoP) para evitar latencias en la ruta crítica de la solicitud. La necesidad de este tipo de almacén ha crecido exponencialmente con la proliferación de arquitecturas serverless y edge computing, donde la lógica de negocio se ejecuta lo más cerca posible del usuario final.
Históricamente, la distribución de configuración se ha manejado con sistemas como ZooKeeper o etcd, que ofrecen consistencia fuerte pero a menudo con latencias más altas o complejidad operativa en despliegues globales. Alternativas como la replicación de bases de datos relacionales o NoSQL a menudo sacrifican la latencia de lectura global o la consistencia inmediata. Quicksilver aborda este nicho específico, priorizando la latencia de lectura en el edge y la consistencia eventual rápida para escrituras, asumiendo un patrón de acceso de lectura intensiva y escritura esporádica.
Arquitectura del Sistema
Quicksilver, la base de KV Instant, es un almacén de clave-valor distribuido globalmente, diseñado para servir configuraciones a través de la red de edge de Cloudflare. Su arquitectura se centra en la replicación de escrituras a cientos de ubicaciones de edge y la minimización de la latencia de lectura desde el PoP más cercano. Aunque los detalles internos de Quicksilver no se revelan completamente, el comportamiento observado sugiere un modelo de consistencia eventual con una fuerte optimización para la propagación de escrituras.
Las escrituras a Quicksilver (y por extensión, a KV Instant) son replicadas globalmente. La latencia de replicación p99 de 256 ms indica un sistema que prioriza la disponibilidad y la baja latencia de lectura sobre la consistencia fuerte inmediata a nivel global para las escrituras. Esto implica el uso de mecanismos de replicación asíncronos y posiblemente CRDTs (Conflict-free Replicated Data Types) o variantes de Paxos/Raft optimizadas para la propagación rápida de actualizaciones a través de una WAN. Las lecturas se sirven desde la réplica local en el PoP, lo que explica las latencias de microsegundos a milisegundos. La restricción de una escritura por namespace por segundo sugiere un punto de serialización global para las escrituras, simplificando la lógica de ordenación de actualizaciones y facilitando la replicación consistente en un entorno distribuido masivo.
Flujo de Escritura en KV Instant
- 1 Cliente Realiza una operación de escritura (PUT/DELETE) a KV Instant.
- 2 Cloudflare Edge Recibe la escritura y la enruta a un punto de serialización global.
- 3 Sistema de Registro (Quicksilver) Procesa la escritura, asegura el orden y la persistencia.
- 4 Replicación Global Propaga la actualización a cientos de PoPs de Cloudflare.
- 5 Cloudflare Edge (Todos los PoPs) Actualiza la réplica local del valor clave.
- 6 Cliente La escritura se considera replicada globalmente (eventualmente consistente).
Flujo de Lectura en KV Instant
- 1 Cliente Realiza una operación de lectura (GET) a KV Instant.
- 2 Cloudflare Edge (PoP Cercano) La solicitud es enrutada al PoP más cercano al cliente.
- 3 Almacén Local (Quicksilver) El PoP sirve la lectura desde su réplica local del valor clave.
- 4 Cliente Recibe el valor con latencia de microsegundos/milisegundos.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Quicksilver (Cloudflare Internal KV Store) | Almacén de clave-valor distribuido globalmente, optimizado para lecturas de baja latencia en el edge y replicación rápida de escrituras. Sirve como el backend para KV Instant. vs Workers KV (Classic Mode), Vercel Global Config, etcd, ZooKeeper Modo 'instant' en la creación del namespace, sin soporte para metadatos, límite de 10,000 pares clave-valor y 1MB total por namespace, claves de hasta 300 bytes. |
Trade-offs
Ganancias
- ▲▲ Latencia de lectura p99
- ▲ Costo de lectura por millón
- ▲▲ Velocidad de replicación de escritura
Costes
- ▲▲ Costo de escritura por operación
- ▲▲ Costo de almacenamiento por MB
- ▲ Límite de tamaño de namespace (1MB)
- ▲ Límite de tasa de escritura (1/seg por namespace)
- △ Soporte de metadatos
- △ Paginación en listado de claves
Fundamentos Teóricos
El diseño de Quicksilver se alinea con los principios de los sistemas distribuidos que operan bajo el teorema CAP, priorizando la disponibilidad y la tolerancia a particiones sobre la consistencia fuerte global para las escrituras, mientras que ofrece una consistencia fuerte local para las lecturas una vez que la actualización se ha propagado. Este patrón es común en sistemas de configuración distribuida a gran escala, donde la disponibilidad de la configuración es más crítica que la consistencia inmediata de una escritura recién realizada.
Conceptos como la consistencia eventual y los CRDTs, explorados en trabajos como 'A comprehensive study of Convergent and Commutative Replicated Data Types' por Shapiro et al. (2011), son relevantes para entender cómo un sistema puede lograr una replicación rápida y una eventual convergencia de estados en un entorno distribuido. La optimización para lecturas locales rápidas se relaciona con la investigación en caching distribuido y la minimización de la latencia de red, un tema recurrente en la literatura de sistemas distribuidos desde los primeros trabajos sobre bases de datos distribuidas y sistemas de archivos distribuidos.