I think that's a slightly different set of things to what OP is complaining about though. They're much more reasonable, but also "outside" of the application. Having secret management or CI (pretty much mandatory!) does not dictate the architecture of the application at all.

(except the caching layer. Remember the three hard problems of computer science, of which cache invalidation is one.)

Still hoping for a good "steelman" demonstration of microservices for something that isn't FAANG-sized.

▲

9dev a day ago | parent | next [-]

> Having secret management or CI (pretty much mandatory!) does not dictate the architecture of the application at all.

Oh, it absolutely does. You need some way to get your secrets into the application, at build- or at runtime, for one, without compromising security. There's a lot of subtle catches here that can be avoided by picking standard tooling instead of making it yourself, but doing so definitely shapes your architecture.

	▲	zelphirkalt a day ago \| parent [-]
		It really shouldn't. Getting the secrets in place should be done by otherwise unrelated tooling. Your apps or services should rely on the secrets being in place at start time. Often it is a matter of rendering a file at deployment time and the jobs of putting the secrets there is the job of the CI, and CI invoked tools, not the job of the service itself.

▲

hinkley a day ago | parent | prev [-]

Cache invalidation is replacing one logical thing with a new version of the same logical thing. So technically that’s also naming things. Doubly so when you put them in a kv store.

▲

kragen a day ago | parent [-]

That angle seems potentially insightful, and I'm going to have to think about it, but to me, cache invalidation seems more like replacing one logical thing with nothing. It may or may not get replaced with a new version of the same logical thing later if that's required.

▲

cluckindan a day ago | parent [-]

To me, cache invalidation is not strictly about either replacing or removing cache entries.

Rather, cache invalidation is the process of determining which cache entries are stale and need to be replaced/removed.

It gets hairy when determining that depends on users, user group memberships AND per-user permissions, access TTL, multiple types of timestamps and/or revision numbering, and especially when the cache entries are composite as in contain data from multiple database entities, where some are e.g. representing a hierarchy and may not even have direct entity relationships with the cached data.

▲

kragen a day ago | parent [-]

Yes—and, in many cases, ensuring that you don't use entries which become outdated during your computation.

▲

cluckindan a day ago | parent [-]

A bit of TOCTOU sprinkled in the cache integration ensures a fun day at the races!

▲

kragen a day ago | parent [-]

TOCTOU bugs are a subset of cache invalidation bugs.

	▲	cluckindan 15 hours ago \| parent [-]
		Are they really? TOCTOU is a trigger for race conditions, but I guess the result of the check is a cached value. Then again, the issue in TOCTOU is that the ”cached value” is not invalidated at all, or inadequately. It doesn’t really have anything to do with the invalidation mechanism, it is downstream from it.