About 15 years ago I implemented "cache namespacing" for memcached, where you build a final cache key for a stored item (e.g. "profile_page") by doing an initial multiget cache query for all the "namespace" version values (e.g "user_123", "team_456" might be needed for "profile_page"), which you combine together as a prefix for the final cache key.
You can then invalidate any final cache key that uses one of the namespaces by incrementing the namespace key.
I haven't come across this technique mentioned elsewhere since, but it's very useful.
I guess nosql, edge caching and materialised views make it less applicable than it used to be (when inelastically scaling single/replicated SQL instances were the only game in town and taking load off them was vital).
Or is this technique now a first class feature of various cache client SDKs?
You can exfiltrate secrets that aren't in the state, but are in accessible resources during a plan using an http data source with the secret encoded into the url
In the long run, I wonder if all video will be signed via blockchain-or-other-trusted-3rd-party. You'd need everything from the camera to the the editing software to support it though.
The title is correct, but the article misses the most important thing. The reason you should not divide them is that delivery of a non trivial feature requires change at each layer of the stack.