What we talk about when we talk about system design
maheshba.bitbucket.io
What we talk about when we talk about system design
1–10 of 37 posts
Re: What we talk about when we talk about system design
#2Extremely high-quality work here - I spend (what I think is) a significant amount of time trying to understand systems, in general and in detail, and this feels on first reading like something I'll be referring to repeatedly in future.
Already it suggests a surprising idea, which may or may not be fleshed out elsewhere, that a good way to understand an existing system is to try and solve the same problem without reference to how the existing system works:
> You will often expend more cycles understanding the existing design than you would solving the problem from first principles. ...
> Even good solutions can bias your thinking towards a particular part of the design space. ... A great time to look at other systems is after the Design phase, to see if you can map those solutions to your space. Even better, you can often reverse-engineer the details of solutions simply by understanding where they fit in your design space.
If it doesn't already exist somewhere else, we can call it Balakrishnan's Law - the best way to understand a problem is to solve it!
Re: What we talk about when we talk about system design
#3These are bullshit to me.
All i need is just simple webpack config to serve my customers.
The application is a monothlic. Who needs system design ?
Re: What we talk about when we talk about system design
#4These are bullshit to me. All i need is just simple webpack config to serve my customers. The application is a monothlic. Who needs system design ?
Everyone who designed everything you use on a daily basis that goes beyond some consumer app or web page.
Re: What we talk about when we talk about system design
#5These are bullshit to me. All i need is just simple webpack config to serve my customers. The application is a monothlic. Who needs system design ?
I understand your comment is tongue-in-cheek, but there's indeed a luddite-like movement that hides itself behind microservices cliches but under the surface they deny the very reason of existence of distributed systems in particular and the system design field in general. To them, the work of putting together a web app is a solved problem consisting of a single process doing everything under the sun, and the only acceptable hint of a software architecture is breaking the app in modules.
Re: What we talk about when we talk about system design
#6This article is excellent. I did not expect that. I'm what you might call an experienced software engineer (late 40s), who has designed a number of large systems. I found myself nodding enthusiastically as I was reading.
Re: What we talk about when we talk about system design
#7These are bullshit to me. All i need is just simple webpack config to serve my customers. The application is a monothlic. Who needs system design ?
comments like this make me wish for a block feature on hn
Re: What we talk about when we talk about system design
#8These are bullshit to me. All i need is just simple webpack config to serve my customers. The application is a monothlic. Who needs system design ?
I understand your comment is tongue-in-cheek, but there's indeed a luddite-like movement that hides itself behind microservices cliches but under the surface they deny the very reason of existence of distributed systems in particular and the system design field in general. To them, the work of putting together a web app is a solved problem consisting of a single process doing everything under the sun, and the only ac…
With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess. And worse still you can't even see a lot of the complexity easily as it's hidden in how the distributed system is configured.
A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It's more reliable, less brittle. It comes with less footguns.
Distributed systems are not a better technology, like weaving looms were, they are simply an alternative design that is presently overused by incompetent software architects.
So it's not a luddite movement, it's an anti-complexity-for-the-sake-of-complexity movement. Try to not call us luddites again. Personally I view people that advocate for such designs by default as incompetent and that they should never be let anywhere near system design as they clearly don't understand the costs.
Simpler is almost always better, and there needs to be extremely good reasons to switch to incredibly costly distributed design patterns.
Re: What we talk about when we talk about system design
#9Thanks for this article, I am a beginner in this space.
I think systems suffer from interaction permutations complexity and the approach to look for a fundamental building block fails, because There Is No Primal Particle™. So we try introduce fundamental particle such as "everything is function", "everything is a list", "everything is a type", "everything is a file". It doesn't work. We do it to keep it in our heads but as soon as the design hits a real interaction, we have to get detailed again.
The C++ spec is enormous and very detailed. Kubernetes.
How does multithreading interact with garbage collection? How does async Rust interact with the borrow checker? How does your type system interact with - everything else? How does DNS going down interact with the rest of your cluster? How does autoscaling fail if your Docker repository is down? Can you rebuild a machine if your debian packageserver is down? How does POSIX interact with security?
What's the building block between things itself?
I am currently trying to design tooling around state space exploration and new type generation from interaction combination information by modelling interactions directly. And the fixpoint of interactions between interactions. (I am inspired by the Nothing I understand of TLA)
My dream: I am told by the computer what interactions I need to handle to handle all the cases I throw at the computer.
Re: What we talk about when we talk about system design
#10Earlier quoted context omitted.
I understand your comment is tongue-in-cheek, but there's indeed a luddite-like movement that hides itself behind microservices cliches but under the surface they deny the very reason of existence of distributed systems in particular and the system design field in general. To them, the work of putting together a web app is a solved problem consisting of a single process doing everything under the sun, and the only ac…
With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess. And worse still you can't even see a lot of the complexity easily as it's hidden in how the distributed system is configured. A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It'…
> With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess.
The goals of system design are a) a system actually works, b) the system is not a colossal mess.
In a similar manner, the challenge of any engineering field is to not allow things to become overly complex.
> A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It's more reliable, less brittle. It comes with less footguns.
You're presuming that your average monolith is the result of a refined design. It is not. The main gripe that the luddite-like movement directs at systems design in general is basically the reality that software projects actually need planning and a working software architecture, where in monoliths they can just pile stuff in there without thought or criteria.