Hacker News Reader

Comment by SahAssar | Hacker News Reader

> In this event, an SRE on the traffic and load balancing team was alerted that some GFEs (Google front ends) in Google's edge network, which statelessly cache frequently accessed content, were producing an abnormally high number of errors

What does "statelessly cache" mean? Stateless means it has no state, and cache means it saves frequently requested operations. How can it save anything without state?

View on HN

Presumably it caches copies of frequently-requested content on nodes closer to the end-user, rather than always fetching that content from an origin node which might be quite far away (especially on a P2P network). It's "stateless" because stateful requests are always sent directly to the origin node, rather than being intercepted and reproduced from the closer cache.

I don't get how these two can be true at the same time?

> Presumably it caches copies of frequently-requested content on nodes closer to the end-user, rather than always fetching that content from an origin node

> It's "stateless" because stateful requests are always sent directly to the origin node

What is a stateful request versus a stateless one? Every request has some sort of state.

My understanding is it's about application state - cookies, mutations, etc...

If the request is "give me the profile photo of the logged-in user" - the response depends on the stateful question of who is the logged-in user.

If the request is "give me the gmail logo" - the response is identical no matter who's making the request. These can be cached on an edge node without regard to application state.

Okay, I understand. I have never heard that being called a stateless cache though, in my experience that is called a public cache. That is also what it is called in the http cache-control standard.

I get what you mean, but calling a cache "stateless" seems like a contradiction in terms to me.

The cache has state, but it's caching stateless requests.

You're talking about HTTP cache control headers, which is a use case that typically avoids storing stateful data in server-side caches. Caches are also used outside of HTTP however, and sometimes those caches can have state (such as expensive database queries). Taking down a cache with state can have a more severe impact on service performance or data consistency.

The blog post mentioned it this way to convey that the cache operation should be relatively simple and generally not return many errors, and that disabling the servers would be low risk (no data loss or severe performance impact).

Typically it means that immutable data is being looked up by hash key. The mapping between the hash key and the data never changes, so the cache is never stale. When there is new data, it's given a different hash key.

Whether or not data is in the cache can change, but if the data is there, the result is always the same.

An example of stateless data would be a video on YouTube or a particular version of a file in git.

If the data cannot change and is not gated by AuthZ/AuthN then it is usually called a public cache.

If the data cannot change but is controlled by AuthZ/AuthN then it is pretty clearly not stateless.

I get what you mean, but calling a cache "stateless" seems like a contradiction in terms to me.

Well it isn't "public", since its only available if you're on Google's internal production network, and in that sense, nothing on the network is public.

It's poorly worded. Obviously the content storage itself is state by definition, but it means non-dynamic (or at least cacheable / "stateless") resources.

My guess is that “stateless” means no durable storage. There’s still state, but in-memory (or maybe transiently stored on disk?) and no guarantee about it being there, perhaps?

It's stateless in the sense that it isn't persisted to storage and isn't an issue if lost.

Any cache should have this property

Reply on news.ycombinator.com