Hacker News new | ask | show | jobs
by cookiecaper 3365 days ago
The question is where the complexity has the biggest cost. In most cases, it should be pretty easy to finagle a multi-write process into your existing data layer, and that without introducing new technologies/stacks/layers. The logic is thus unified and simple, in a single place, in a format that the company already has significant expertise in.

That is much easier to track, trace, understand, and debug than a request that flows through 7 servers, 5 data layers (that have their own configs, nuances, snafus, caveats, etc.), and 2 proxies, each of which introduces a point of potential corruption/breakage, before it finally reaches the place it's trying to go.

Anyway, like I said in the grandparent, I'm sure there are times when this is the best way to accomplish something. It's hard to nitpick an unfortunately-potentially-appropriate specific solution in the general sense, except to say that its potential applicability is unfortunate.

The problem is that people do not see such complexity for the unfortunate byproduct of poor technical and/or organizational architecture that it is, but rather as evidence of their own expertise. That is exactly backwards. We must fix that false impression to restore sanity to the profession.

1 comments

Yup. I'm fully with you. You need have evidence of serious unavoidable problems before you go down the route of having lots of distributed systems and communication between them, because those systems are far harder to reason about globally, and debug. There's a high risk of undesirable emergent properties and cascading failure modes.