3 ms·

If one HTTP request is split into many serial database queries (E.g 1:10, request:db-queries), it doesn’t make sense to have the request hit the low latency edg

If one HTTP request is split into many serial database queries (E.g 1:10, request:db-queries), it doesn’t make sense to have the request hit the low latency edge worker, and then send 10x the queries to a faraway database server as you are incurring the cost of latency for each db query. In this case you may as well run an HTTP server next to your database and incur the high http request latency once, and have < 1ms latency for each of the 10 queries. Is this correct?

technobabbler 5y ago
If this works like a regular worker, the first request can then cache the response for subsequent users. Might be helpful for read-often, write-rarely use cases where the first user (per expiry period) acts as a sacrificial lamb to speed up subsequent requests for following users. Regardless of whether the Worker hits the 10 DB queries itself or goes through a database-adjacent HTTP proxy first, subsequent requests don't have to hit either one, but can get served directly from the Cloudflare edges using a cached response. You can get similar caching by making a bunch of distributed read-only database shards and/or caching your HTTP proxy output, but in this case Cloudflare manages all that for you. You do have to set up a tunnel and apparently some sort of daemon, though, so I guess you're just running Cloudflare's proxy to their edge. It's not as clean as an edge-native key-value store (like their Durable Objects or Workers KV), but if your existing code requires a relational DB at scale, this might be one way to tackle it rather than dealing with DB sharding and clustering yourself -- which can get real ugly, real fast.