[throwaway122kk]

Arghh the biggest issue in current place (I be leaving before year end) is the amount of "engineers" who are pathologically afraid of relational database.

You have dozens microservices per teams, split between k8s, meso, aws, azure, physical servers each on using everything under the moon to store data up to storing files in s3

Needless to say the amount of issues due to data inconsistencies is incredible. And of course the amount of actual users of the overall product is tiny being an enterprise products, maybe few thousand concurrent users at peak.

They now want regional replication and screwed due to so many sources of data. Where postgres alone would have done

[hinkley]

I currently have a bunch of clowns who are indistinguishable from most of the clowns in my profession. Application slow? We’ll just add caches instead of trying to create an architecture.

“But we have an architecture.” No, you don’t. You have a set of idioms that you arrange like dominoes until an answer you like comes out the other end. That’s only an architecture in the way suffering is a personality.

You don’t need more caches. You need an architecture and dynamic programming. Someone save me from promise caches. First couple times they were so cool, now they’re a golden hammer for lack of even the most rudimentary of data flow analysis.

[wpietri]

I've long thought that caching is to software architecture what ketchup is to diner food. Something's not right with your meal? Just apply more ketchup.

[TeMPOraL]

I'd think that was the salt of software architecture, but there are limits to which you can fix up a dish by adding salt, beyond which the dish becomes inedible. So I'd guess "upgrade hardware" would be the salt of software architecture.

[raverbashing]

That sounds like needless idealism

Do you really think your front page needs all the queries reran for every single user that visits? Even though things won't change for, let's say, even 30s?

Even the front page of HN is cached. Their system is pretty snappy but not caching what's trivial just doesn't work in the real world.

[wpietri]

That suggests that I believe the right amount of ketchup on food is zero. That's incorrect. I'm not saying you shouldn't ever cache anything. I'm saying that caching is used to cover up a lot of architectural flaws, when sometimes we would be better off if we fixed the flaws.

And I'd add that you notion that the only two options are "cache X" and "rerun all queries" is a part of the problem here. There are more things, Horatio.

[SigmundA]

"There are only two hard things in Computer Science: cache invalidation and naming things."

Seriously don't build a cache until you have exhausted all other performance improving avenues. I am not against caches but throwing a new cache in the code every time a performance issue is found or worse preemptively making a cache due to a possible performance issue is an endless source of cache invalidation bugs.

[raverbashing]

Yes don't cache everything needlessly, use it wisely

[abdusco]

Isn't dynamic programming (specifically memoization) a specialized type of caching? Am I missing something?

[hinkley]

Only in the sense that the lion is a specialized type of mammal, rather than king of the jungle.

Caches are global state in sheep’s clothing. In many languages and implementations, they can be mutable shared state, which leads to unexpected side effects and concurrency bugs that may cross transaction or user boundaries. It’s a covert channel where code interacts without ever talking to each other. In languages without static analysis you cannot determine quickly which pieces of code talk in this fashion. It’s all secretly coupled instead of overtly coupled. You only learn by vast experience, and in the interim you make mistakes, which makes the oldest team members appear capable and the newest unworthy of trust. But it’s the people who tilted this playing field that you can’t trust. In a word: toxic.

Done right, memoization shows up clearly in your sequence diagrams, near the heart of your architecture. The top level of the code knows what’s going on, and orchestrates communication. People walking in off the street can figure out what the hell is happening, and be productive in short order.

It can often force you to think about when your system of record and your source of truth diverge. Usually I see people cache low quality precursor data for a decision, and then they have to cook it every time.

The thing I liked most about AngularJS was that you were meant to fetch all of your data fairly early in an interaction, mis-en-place style. If the data you got was a little garbage, you cooked it before any interface code ever saw it. The view just saw the nice version.

Doing so affords another architectural tool. All of that cleanup code can be moved to the backend or the database in a single refactoring, getting it out of the client. And the overt coupling makes you contend with the fact that a piece of code talks to too many hints to get its job done. It’s a mirror some do t want to look in.

The problem is, all of this involves making decisions, and a lot of developers either never learned, or learned to distrust their decisions. And rather than finding way to mitigate a bad decision, far too many of us have instead spent years or decades learning how never to make a decision at all. We’d be a lot better off with strong opinions loosely held.

[amelius]

Perhaps you need an architecture which uses caches ... And you were both right.

[andy_ppp]

This is standard practice in the micro services world, bin ACID compliance and replace it with network partitions because you’re so fashionable you have no users and no data.

In the system I’m working on (it’s mongodb tastic) someone had added a try catch around everything (EVERYTHING) that reverts the service manually in the catch block. I don’t need to explain to people here how moronic rolling your own transactions like this is...

Everywhere using micro services appears to be the same :-/

[hinkley]

I don’t think we’ve quite cracked how to have a bunch of things behave the same without being the same thing. With DCVS, containers, monitoring systems and the like, we are nibbling at the edges but there’s a lot left to be desired.

You and I should be able to benefit from a set of corporate- or at least division-standard data retention services without sharing a database, let alone each other’s schema.

[tsjq]

Looks like every single engineer / lead wanted to have their favourite bleeding edge technology.