iliketoworkhard

Same with my old bose SoundSports

I really need to pick up Solaris.

I felt like Sapiens rewired my brain in a way. Homo Deus only drove in the message that we are nothing but algorithms

And why weren’t all headers considered in the cache key to begin with? The key computation will never not be O(1).

Only thing I can think of is too many cache entries with the same cache values for the case where requests with different headers produce the same API response.

Which could lead to a large cache.

What is CGI in this context? I’ve only heard of it in a movie special effects context.

In general caching systems are volatile and not meant to be used to store data that cannot be afforded to be lost. Of course that doesn't stop clients from storing critical data on there in return for the simple GET/PUT APIs and low latencies.

You can go for more complex caches such as Hazelcast which offers hot restarts by persisting data to disk.

Thank you! Sounds like a case where a consumer was updated but producer wasn't.. more room for error for the dev

Interesting point about things getting caught on prod, no amount of stress testing can sometimes reproduce these finicky bugs :)

Splunk aggregation is a life saver. If you assign a unique id to each request, you can trace its path thru it's entire lifecycle, including asynchronous post-tasks. This can also help see average delay latencies between a sync task and its associated asynchronous post task/s.

Great points! Would you mind elaborating to a relatively inexperienced engineer how the following scenarios can end up happening?

> queue sending to dead endpoints

> circular queue problem