3 ms·

CDN: no trade offs. Faster everywhere. More reliable overall Cockroach DB: trade some performance for geographic redundancy. The trade off may work in your fav

CDN: no trade offs. Faster everywhere. More reliable overall Cockroach DB: trade some performance for geographic redundancy. The trade off may work in your favor - e.g. read heavy workloads (or not). I plugged in CDB I place of Postgres for some testing this week, was surprised it worked so well.

icebraining 9y ago
no trade offs This is almost never the case, and CDNs are no exception. A CDN like Cloudflare that reuses your domain(s) means that they become just a useless point that your dynamic requests have to travel to and from the main server. A CDN that uses its own domains requires extra DNS queries, extra TCP & SSL connection setup, etc, plus it only starts loading when the browser has started processing the HTML.
- dstroot 9y ago
  Excellent points. I definitely oversimplified.
- ec109685 9y ago
  CDN’s can terminate a user’s ssl connection close to the user (and keep a persistent one open to the origin), so it is more than a useless hop. There are also http headers that can instruct the browser to fetch cdn resource before the html is delivered.
dasil003 9y ago
At my previous company we built our own CDN because we were streaming video to a long tail of global users for a limited library. The problem with off-the-shelf CDNs was they couldn't keep our content cached for the long tail, but for the same price we could replicate our limited library to bare metal. Traditional caching could then go on top of that. This was a huge win for QoS on cache misses, which were a significant portion of our traffic. There are tons of tradeoffs to make this happen which is why we couldn't find an off-the-shelf solution to deliver the same results.
zzzcpan 9y ago
Unless you build your own DNS routed CDN, it actually reduces reliability. And to make it faster everywhere you trade immediate consistency for eventual consistency.
- joshribakoff 9y ago
  I think what you're trying to say is the CDN becomes another point of failure, that is, unless you have DNS failover which updates the DNS of cdn.example.com to point to your origin server's IP instead of the CDN in the event the CDN goes down. You should have monitoring & fail saves in place for your CDN, and if that's in place a CDN has higher redundancy vs just a single server is what the OP was trying to say, I bet.

icebraining 9y ago

no trade offs This is almost never the case, and CDNs are no exception. A CDN like Cloudflare that reuses your domain(s) means that they become just a useless point that your dynamic requests have to travel to and from the main server. A CDN that uses its own domains requires extra DNS queries, extra TCP & SSL connection setup, etc, plus it only starts loading when the browser has started processing the HTML.

dstroot 9y ago
Excellent points. I definitely oversimplified.
ec109685 9y ago
CDN’s can terminate a user’s ssl connection close to the user (and keep a persistent one open to the origin), so it is more than a useless hop. There are also http headers that can instruct the browser to fetch cdn resource before the html is delivered.

dasil003 9y ago

At my previous company we built our own CDN because we were streaming video to a long tail of global users for a limited library. The problem with off-the-shelf CDNs was they couldn't keep our content cached for the long tail, but for the same price we could replicate our limited library to bare metal. Traditional caching could then go on top of that. This was a huge win for QoS on cache misses, which were a significant portion of our traffic. There are tons of tradeoffs to make this happen which is why we couldn't find an off-the-shelf solution to deliver the same results.

zzzcpan 9y ago

Unless you build your own DNS routed CDN, it actually reduces reliability. And to make it faster everywhere you trade immediate consistency for eventual consistency.

joshribakoff 9y ago
I think what you're trying to say is the CDN becomes another point of failure, that is, unless you have DNS failover which updates the DNS of cdn.example.com to point to your origin server's IP instead of the CDN in the event the CDN goes down. You should have monitoring & fail saves in place for your CDN, and if that's in place a CDN has higher redundancy vs just a single server is what the OP was trying to say, I bet.