undefined | Better HN

0 pointskbenson1mo ago0 comments

> I said monorepo and monodeploys in this thread

And that helps when you are dealing with schema changes that need to be rolled out at AWS, your local DB, a Kafka cluster, how? The whole point of this article was how to approach the problem when there are different components in the system which make a monorepo and what it provides for this infeasible or impossible.

> I know it's not "practical" but that's not my point. My point is that there's a huge portion of problems with "systems" that are literally obviously solvable and with obvious solutions it's just I'm too lazy to write a production grade database from scratch, sorry guys.

The article talks about database solutions that help with this problem.

I'm uncertain how to interpret your responses in light of the article, when they seem to be ignoring most of what the article is about, which is solving exactly these problems you are talking about. Is your position that we shouldn't look for solutions to the harder problems because some people aren't even using the solutions to the easy problems?

0 comments

threethirtytwo1mo ago

The article is about coping mechanisms for a world where we already accepted fragmented systems: polyrepos, heterogeneous languages, independently versioned databases, queues, infra, and time-skewed deployments. Given that world, yes, you need sophisticated techniques to survive partial failure, temporal mismatch, and evolution over time.

That is not what I’m arguing against.

My point is more fundamental: we deliberately designed away static safety at the foundation, and then act surprised that “systems problems” exist.

Before Kafka versioning, schema migration strategies, backward compatibility patterns, or temporal reasoning even enter the picture, we already punched a hole:

Polyrepos break global static checking by construction.

Databases are untyped relative to application code

SQL is strings, not programs

Deployments are allowed to diverge by default

That entire class of failure is optional, not inherent.

When I say “we haven’t solved square one,” I’m saying: we skipped enforcing whole-system invariants, then rebranded the fallout as unavoidable distributed systems complexity.

So when you say “the article already offers solutions,” you’re misunderstanding what kind of solutions those are. They are mitigations for a world that already gave up on static guarantees, not solutions to the root design mistake.

I’m not claiming my position is practical to retrofit today. I’m claiming a huge portion of what we now call “hard systems problems” only exist because we normalized avoidable architectural holes decades ago.

You’re discussing how to live in the house after the foundation cracked.

I’m pointing out the crack was optional and we poured the concrete anyway.

I’m telling you this now so you are no longer uncertain and utterly clear about what I am saying and what my position is. If you are unclear please logically point out what isn’t clear because this phrase: “ The article talks about database solutions that help with this problem.” shows you missed the point. I am not talking about solutions that help with the problem, I am talking about solutions that make a lot of these problems non-existent within reality as we know it.

kbensonOP1mo ago

You say don't use databases, and that we had the option to use something different and did not, and chose this path.

I ask you what to use instead, and how to deal with datastore versioning.

You say you're talking about how we don't have type safety that extends to the remote systems we're interacting with.

I ask how that helps versioning problems with these systems where you need to deal with applying changes across distributes systems, which specifically is not solved by having types in lockstep definition between systems, because in application of change there are problems to work thought.

You note we did all this deliberately and we didn't have to. I keep asking you what the other option is, because you keep acting like there is one, but refusing to give an example of what that would be, because a monorepo is no solution for the problems being discussed here in the article, which to be clear, are not limited to code.

You've made it very clear you think we should have done "something" else, but refuse to articulate what that is. If it's not known, or not explored, then I posit we didn't "choose" this path, it's the path that was open to us.

> You’re discussing how to live in the house after the foundation cracked.

You keep saying we should have used something else for the foundation that wouldn't crack, but refuse to explain what this mythical material is.

What is your proposed alternative, or are you just waxing theoretical?

threethirtytwo1mo ago

You still don’t get what I’m saying, and at this point it’s not a disagreement, it’s a category error.

I am not saying the problem is impossible. I am saying the problem is obvious, stupid, and solvable in theory, and that the only actual solution is to rewrite the foundation from scratch. That is precisely why there is no practical path forward. The impracticality is the point.

When you keep asking me to name an alternative, you’re implicitly assuming I’m advocating for some incremental migration or deployable fix inside the current ecosystem. I am not. There isn’t one. If you want whole system static guarantees, you need a database that is designed from the beginning to be part of the same language and type system as the application. Queries are programs. Schemas are types. The datastore is a compiled artifact, not a remote string interpreter. That requires a fundamentally different database.

That is the alternative. And it is completely unrealistic to retrofit into the existing world. Which is why we are stuck.

So when you say I’m “waxing theoretical,” you’ve missed the entire point. The theory is the indictment. The fact that the solution is obvious but unusable is exactly the problem. We built ourselves into a corner decades ago, and everything we now call “systems engineering” is about managing the consequences of that decision.

The article is fine. It surveys techniques for surviving in the world as it exists. I am not disputing their usefulness. I am saying those techniques exist because we accepted a broken foundation and normalized it. That distinction matters.

You keep arguing as if I’m refusing to answer your question. I’m answering it directly. The answer just isn’t one you like. The only real fix is a ground up rewrite of the data layer and its relationship to code, and that’s never going to happen at scale. That’s the conclusion. Understand?

If you think that means the path we’re on was the only one available, then we fundamentally disagree about what “choice” means in system design.

You’re still trying to refute a design critique by demanding an escape hatch, which only proves you never understood what was being critiqued.

yencabulator1mo ago

> and time-skewed deployments.

Yeah, those pesky laws of physics, getting in the way of purity.

You simply cannot deploy simultaneously to an active fleet of servers.

threethirtytwo1mo ago

Then don't if it's impossible. Make it have eventual consistency. The deploy window is the zone of impurity but if the deploy completes, you're pure.

1 more reply

j / k navigate · click thread line to collapse

0 comments

threethirtytwo1mo ago

That is not what I’m arguing against.

My point is more fundamental: we deliberately designed away static safety at the foundation, and then act surprised that “systems problems” exist.

Before Kafka versioning, schema migration strategies, backward compatibility patterns, or temporal reasoning even enter the picture, we already punched a hole:

Polyrepos break global static checking by construction.

Databases are untyped relative to application code

SQL is strings, not programs

Deployments are allowed to diverge by default

That entire class of failure is optional, not inherent.

When I say “we haven’t solved square one,” I’m saying: we skipped enforcing whole-system invariants, then rebranded the fallout as unavoidable distributed systems complexity.

You’re discussing how to live in the house after the foundation cracked.

I’m pointing out the crack was optional and we poured the concrete anyway.

kbensonOP1mo ago

You say don't use databases, and that we had the option to use something different and did not, and chose this path.

I ask you what to use instead, and how to deal with datastore versioning.

You say you're talking about how we don't have type safety that extends to the remote systems we're interacting with.

> You’re discussing how to live in the house after the foundation cracked.

You keep saying we should have used something else for the foundation that wouldn't crack, but refuse to explain what this mythical material is.

What is your proposed alternative, or are you just waxing theoretical?

threethirtytwo1mo ago

You still don’t get what I’m saying, and at this point it’s not a disagreement, it’s a category error.

That is the alternative. And it is completely unrealistic to retrofit into the existing world. Which is why we are stuck.

If you think that means the path we’re on was the only one available, then we fundamentally disagree about what “choice” means in system design.

You’re still trying to refute a design critique by demanding an escape hatch, which only proves you never understood what was being critiqued.

yencabulator1mo ago

> and time-skewed deployments.

Yeah, those pesky laws of physics, getting in the way of purity.

You simply cannot deploy simultaneously to an active fleet of servers.

threethirtytwo1mo ago

Then don't if it's impossible. Make it have eventual consistency. The deploy window is the zone of impurity but if the deploy completes, you're pure.

1 more reply

j / k navigate · click thread line to collapse