[TYPE_FASTER]

Yup. Content that may be read-only from a user's perspective might get updated by internal services. When those updates don't need to be reflected immediately, a CDN or similar works fine for delivering the content to a user.

When changes to data are important, a library like Hollow can be pretty magical. Your internal data model is always up to date across all your compute instances, and scaling up horizontally doesn't require additional data/infrastructure work.

We were processing a lot of data with different requirements: big data processed by a pipeline - NoSQL, financial/audit/transactional - relational, changes every 24hrs or so but has to be delivered to the browse fast - CDN, low latency - Redis, no latency - Hollow.

Of course there are tradeoffs between keeping a centralized database in memory (Redis) and distributing the data in memory on each instance (Hollow). There could be cases where Hollow hasn't sync'd yet, so the data could be different across compute instances. In our case, it didn't matter for the data we kept in Hollow.

[motorest]

> When those updates don't need to be reflected immediately, a CDN or similar works fine for delivering the content to a user.

What leads you to believe a CDN is a solution to a problem of delivering personalized content to a specific user?

[TYPE_FASTER]

Personalization could include showing the same cached content to many people. The personalization here could refer to which content is served from the CDN to which users.

[motorest]

> Personalization could include showing the same cached content to many people.

That's not the problem.

The main requirement is to allow editors to preview their changes without having to wait multiple seconds due to caching refresh cycles.

[yandie]

I can’t imagine the number of editors is that large? Are we talking about hundreds or thousands? Taking a look at the site there can’t be that many users that need this low latency preview capability.