Redis
Is like a big hash map, so you can really only get 1 value per transaction. If you want to get multiple values, you can use Redis Pipelines, which will allow you to sort of use a batch. You send a batch of keys and it grabs all values and sends them back in a batch. Under the hood, this is all individual transactions, but doesn’t incur the network overhead.
Latency < 1 ms
Supports sharding and replication
Has complex data types
High availability (replication and failover)
Can have persistence turned on (off by default)
Memcached
In memory key value store.
Doesn’t have sharding or replication
Doesn’t do well with complex data types.
Doesn’t have persistence (can’t be configured)
Redis vs Memcached
Memcached
- A bit more performant for the limited use case it can handle (because it stores almost no extra data and does almost nothing)
- just key value data
- no complex datatypes
- no sharding
- no replication
- no failover
- no persistence
- only does LRU eviction (or no eviction)
Redis:
- much more productionizable (does all the things listed memcached doesn’t do)
- many eviction policies
What is the biggest reason CDNs improve performance?
Because there are more servers serving the content.
Yes, being located closer helps, but it really only cuts down a bit on the latency of the initial request + handshake + whatever. Once the content data starts flowing, the speed is primarily determined by the bandwidth. CDNs primarily just prevent a bottleneck on multiple parallel requests accessing the same data.
CDN Pre warming
Some component makes the CDN fetch some content before any users actually request it, in anticipation of one or more users requesting it, so it has low latency right away.
It is not typical to prewarm the CDN in the scenario where there is only a small number of consumers of the content, like in a 1:1 message including a video.
CDNs for live streaming
Edge servers are often optimized for serving content, and don’t have room to store the whole stream.
The act of storing the stream on the edge server would slow down the serving of the content, so it only keeps a short time cached (2 - 10 seconds).
Most users are just watching the new content anyway, so the usual use case doesn’t require storing the whole stream, like you would in an on-demand video scenario.
Nobody wants to pay for the extra storage per edge host, because there’s so many of them. Would be paying for duplicated data. (chat gpt basically said this, but im not sure if this really makes much of a difference in terms of cost)
CDNs support Adaptive Bitrate streaming (multiple video qualities), so the nodes would have to store multiple copies of the same video at different qualities, further increasing storage)
Other content may also be on the servers too (different streams) so storage capacity could end up being exceeded if we store everything.
If the user requests old stream content the CDN will fetch it from the server and will likely cache it, although it will likely be evicted in 2-10 minutes because nobody else is using it. It might not even cache it though, depending on the configuration.
