[Joe8Bit]

Reading the article I got the impression the big challenge is doing "personalzation" of the content at scale.

If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering".

To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!

[ericmcer]

Whats the point of building & caching static pages if every single user gets their own static page... The number of users who will request each page is 1?

[nchmy]

I dont think that's what they're doing. They seemingly cache some common templates and then fill in the dynamic placeholders per-request. So, their new architecture that has some sort of distributed in-memory cache allows for doing so much more efficiently than, presumably, doing the same queries over the network. The way I understand it, its essentially just a fancy SSR.

[JamesSwift]

> cache some common templates and then fill in the dynamic placeholders per-request

Otherwise known as server-side includes (SSI)

[nchmy]

Not necessarily - SSI/ESI do http requests for each placeholder and fill it with an HTML fragment. They may just be doing some templating of whatever sort, from the kv store.

[miyuru]

> >300m users scale Netflix operates at

They are not talking about the Netflix steaming service.

https://www.netflix.com/tudum

This is a site they are talking about which is very similar to a WordPress powered PR blog.

[giancarlostoro]

So, is this a read-only candidate? Or is there something very nuanced about it? I've never even used this site.

[chatmasta]

It’s basically a company blog.

[giancarlostoro]

So it could have just been a SSG'd website...

[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.