4 ms·
> Reading values from Workers KV is designed to have the same reliability as reading static files, making it much less likely to become unavailable than a tradi
by sephware 8y ago
> Reading values from Workers KV is designed to have the same reliability as reading static files, making it much less likely to become unavailable than a traditional database. It’s designed to have the same performance as reading a file cached within our network, close to your users, giving it the speed of serving a static file as well.
I wonder how this kind of speed is achieved with an API that has to go over the network? Even if the round trip is short such as between two AWS services, there's always at least some latency.
- manigandham 8y agoReading cached files goes over the network too. CDN servers share the cache load and have just 1 or a few copies per datacenter that are served by every machine there. It's likely that this KV store is built on top of the existing cache storage layer, which would also explain the eventual consistency and high-reads with low-writes.
- alaties 8y agoThe trick likely has to do with their write semantics. The post states that writes in WorkerKV are ratelimited to 1 a second per key. From there, we can interpret a likely scenario: if at each data center requests for a given client usually route to the same server nodes, and that information is discoverable on write, then it is likely possible for commands to those nodes to be issued during the write. The commands could be as simple as "pull latest value from upstream store". All commands could easily be issued in under a second. Given that the blog states global consistency is reached in around 10 seconds, it seems reasonable to me that all nodes operating on behalf of a client would have finished pulling the updated value by then. That said, the scenario above is just speculation on my part.