As a systems engineer who works in SysML near daily, these System Design pages really are not general enough to apply to any system. Really the focus is on software and it’s very opinionated. Arguably, the different “systems” could be “subsystems” described herein
I believe this sort of thing will continue as people use LLMs to produce artifacts.
It will produce beautiful and thoughtful-looking work to even those with a discerning eye, but keep picking at it and you’ll see that bias and unintentional deception is endemic.
It’s not that LLMs can’t be used thoughtfully, but that it is essentially a bird laying rotten egg solutions by default, and only through conscientious continued hand-held process, throwing away the rotten yolk regularly, can it be used, and even then with care and only in certain circumstances. But, as it’s crafted to in its very nature to deceive in order to provide what is desired, it will eventually fool even those that understand its nature, with larger and larger consequences.
I have seen disease and famine destroy, and I don’t want to prevent solutions, but this is a beast, a great deceiver; have we not learned by now the story that will be told now that Pandora’s box has been opened?
I've never seen these attempts at categorizing and operationalizing system design be effective in getting people or teams to design better systems. There's an exception to basically every rule, and good system designers often break any individual rule with good reason.
You have to grow system designers the hard way. Lots of iterations, go off and write up a design, get feedback, repeat. And then dogfood the design, whoever designed it should also do the brunt of the implementation and maintenance. That forced contact with reality leads to well designed systems, and people who produce them consistently. A second order effect is a culture of valuing well designed systems, people clustering around good system designers. No one wants to be on the project that is too complicated or unlikely to work or a high maintenance burden.
As more of an embedded and electronics engineer, I've mentally toyed with extending these software principles into broader engineering, and some of them work decently. However, there is questionable value in making things like bridges modular. Either way, I did need a system design almanac like this one.
> questionable value in making things like bridges modular
Aren't most bridges these days modular and made of prefab components assembled on site? Afaik that greatly sped up construction over the past few decades.
They're also modular in that there are built-in weakpoints designed to constrain failures without taking out the whole bridge. You can see that in action if you look at photos of the Bay Bridge after Loma Prieta. Collapsed sections, but most of the bridge stayed up.
Author here, appreciate the share :) I was not expecting this to get so much attention.
To clarify: this is indeed just a taxonomy of classic system-design principles. The periodic-table styling is a familiar metaphor; there is no claim that principles repeat periodically. The goal was to outline a mostly orthogonal set of design principles and highlight cross-domain connections across computer systems so it is easier to discuss designs precisely. Thanks for all the thoughtful feedback!
I came to say what others beat me to: this is not a periodic table, and calling it such is a legitimate disservice. It taints whatever value your content might hold because if it's presented as something that it's not, why should anyone trust it?
I strongly urge you to rename the project and most definitely update the body content of your README.md.
The best time was before you git pushed; the second best time is right now.
It always strikes me how much commonality exists across different software engineering disciplines—not to mention across fields outside of engineering (e.g., how double-entry bookkeeping mirrors immutable design principles, or how federalism resembles class-based OOP).
Great to see an attempt at describing this phenomenon. A great start to what will surely be an awesome resource.
I don't remember the exact book/article that prompted me, but I believe it's because everything software is designed by humans for humans. We invented formalism because it's a nice way to communicate truth about the world. Then we invented computers that act based on formal instructions. Then it's been us trying to replicate the world on top of computers. Paradigms are models of communication, data structures are models of information, algorithms are reusable instructions.
New elements can also be added to the periodic table of elements. Nh, Mc, Ts, and Og were all added in 2016 and discovered within the past 2ish decades
Exactly. It is intentionally open-ended: new "principles" can emerge, split, or retire as the taxonomy evolves. This is just version 1. The grid is a visual index and the fun part is mappin systems to "molecules" in different domains like OS, databases, computer architecture, distributed systems, programming languages, networking, and more..
My pet peeve on the internet (and the only one I consistently rant about) is "Periodic Table of X" The data is often visualized to look like the Periodic Table of Elements. At least this one doesn't make that mistake!
But then, are the system design principles periodic in some way? Does adding Y to one of the principles turn it into another? And if you add enough Ys, does it turn back into the same group again? Here, I find it's a resounding no.
Better to call it a Taxonomy of System Design instead.
I know it's a rant, but my explanation for the popularity of such visualization is their familiarity. I mean, I'd also prefer a more accurate use of references to science, but I guess you will agree that "A periodic table of X" sounds pretty cool and makes you read the article :)
Author here, great question :) If principles are the elements, we can think of each system as a "molecule" with some imagination. For example, an SQL database system has many principles:
1. Abstraction Lifting (Al) + Policy/Mechanism Separation (Pm): SQL states high-level intent with precise semantics, and logical operators are decoupled from physical operators.
2. Equivalence-based Planning (Ep) + Invariant-Guided Transformation (Ig): We apply algebraic rewrites that preserve semantics (e.g., join reordering, predicate pushdown) under stated invariants.
3. Cost-based Planning (Cm): We choose concrete physical operators and join orders using a cost model and so on..
The periodicity reflects the allowed solutions to the Schrödinger equation for electrons in atoms. It is not some branding teams' genius design innovation.
Ironically, you are in a superstate between "can" and "should".
Totally fair.. I am not claiming periodicity here :) I just wanted to use the "periodic table" as a visual metaphor. The goal is to outline a mostly orthogonal set of system design principles and illustrate cross-domain connections to students so that it is easier to compare trade-offs and discuss designs more precisely.
As a systems engineer who works in SysML near daily, these System Design pages really are not general enough to apply to any system. Really the focus is on software and it’s very opinionated. Arguably, the different “systems” could be “subsystems” described herein
I believe this sort of thing will continue as people use LLMs to produce artifacts.
It will produce beautiful and thoughtful-looking work to even those with a discerning eye, but keep picking at it and you’ll see that bias and unintentional deception is endemic.
It’s not that LLMs can’t be used thoughtfully, but that it is essentially a bird laying rotten egg solutions by default, and only through conscientious continued hand-held process, throwing away the rotten yolk regularly, can it be used, and even then with care and only in certain circumstances. But, as it’s crafted to in its very nature to deceive in order to provide what is desired, it will eventually fool even those that understand its nature, with larger and larger consequences.
I have seen disease and famine destroy, and I don’t want to prevent solutions, but this is a beast, a great deceiver; have we not learned by now the story that will be told now that Pandora’s box has been opened?
i feel bad for anyone who has to deal with sysml, cameo and all that proprietary crapfest bolted on. couldnt pay me enough to go back
I've never seen these attempts at categorizing and operationalizing system design be effective in getting people or teams to design better systems. There's an exception to basically every rule, and good system designers often break any individual rule with good reason.
You have to grow system designers the hard way. Lots of iterations, go off and write up a design, get feedback, repeat. And then dogfood the design, whoever designed it should also do the brunt of the implementation and maintenance. That forced contact with reality leads to well designed systems, and people who produce them consistently. A second order effect is a culture of valuing well designed systems, people clustering around good system designers. No one wants to be on the project that is too complicated or unlikely to work or a high maintenance burden.
As more of an embedded and electronics engineer, I've mentally toyed with extending these software principles into broader engineering, and some of them work decently. However, there is questionable value in making things like bridges modular. Either way, I did need a system design almanac like this one.
> questionable value in making things like bridges modular
Aren't most bridges these days modular and made of prefab components assembled on site? Afaik that greatly sped up construction over the past few decades.
They're also modular in that there are built-in weakpoints designed to constrain failures without taking out the whole bridge. You can see that in action if you look at photos of the Bay Bridge after Loma Prieta. Collapsed sections, but most of the bridge stayed up.
Author here, appreciate the share :) I was not expecting this to get so much attention.
To clarify: this is indeed just a taxonomy of classic system-design principles. The periodic-table styling is a familiar metaphor; there is no claim that principles repeat periodically. The goal was to outline a mostly orthogonal set of design principles and highlight cross-domain connections across computer systems so it is easier to discuss designs precisely. Thanks for all the thoughtful feedback!
I came to say what others beat me to: this is not a periodic table, and calling it such is a legitimate disservice. It taints whatever value your content might hold because if it's presented as something that it's not, why should anyone trust it?
I strongly urge you to rename the project and most definitely update the body content of your README.md.
The best time was before you git pushed; the second best time is right now.
Agreed, I just updated it to "Elements of System Design".
Ok, we'll put that in the title above as well. Thanks!
It always strikes me how much commonality exists across different software engineering disciplines—not to mention across fields outside of engineering (e.g., how double-entry bookkeeping mirrors immutable design principles, or how federalism resembles class-based OOP).
Great to see an attempt at describing this phenomenon. A great start to what will surely be an awesome resource.
I don't remember the exact book/article that prompted me, but I believe it's because everything software is designed by humans for humans. We invented formalism because it's a nice way to communicate truth about the world. Then we invented computers that act based on formal instructions. Then it's been us trying to replicate the world on top of computers. Paradigms are models of communication, data structures are models of information, algorithms are reusable instructions.
Somehow the TABLE is missing.
More like list of system design principles stylized as periodic table of elements icons.
There is one now in the table of contents.
I added it now :)
Unlike the real periodic table, here you can add new elements also
New elements can also be added to the periodic table of elements. Nh, Mc, Ts, and Og were all added in 2016 and discovered within the past 2ish decades
Exactly. It is intentionally open-ended: new "principles" can emerge, split, or retire as the taxonomy evolves. This is just version 1. The grid is a visual index and the fun part is mappin systems to "molecules" in different domains like OS, databases, computer architecture, distributed systems, programming languages, networking, and more..
My pet peeve on the internet (and the only one I consistently rant about) is "Periodic Table of X" The data is often visualized to look like the Periodic Table of Elements. At least this one doesn't make that mistake!
But then, are the system design principles periodic in some way? Does adding Y to one of the principles turn it into another? And if you add enough Ys, does it turn back into the same group again? Here, I find it's a resounding no.
Better to call it a Taxonomy of System Design instead.
/rant
I know it's a rant, but my explanation for the popularity of such visualization is their familiarity. I mean, I'd also prefer a more accurate use of references to science, but I guess you will agree that "A periodic table of X" sounds pretty cool and makes you read the article :)
Ok, now show me a molecule. The Periodic Table of Elements is a deep reference object, not a graphic design template.
Author here, great question :) If principles are the elements, we can think of each system as a "molecule" with some imagination. For example, an SQL database system has many principles:
1. Abstraction Lifting (Al) + Policy/Mechanism Separation (Pm): SQL states high-level intent with precise semantics, and logical operators are decoupled from physical operators.
2. Equivalence-based Planning (Ep) + Invariant-Guided Transformation (Ig): We apply algebraic rewrites that preserve semantics (e.g., join reordering, predicate pushdown) under stated invariants.
3. Cost-based Planning (Cm): We choose concrete physical operators and join orders using a cost model and so on..
it's both
just by it's ubiquity and success it has become a template for graphical design
The periodicity reflects the allowed solutions to the Schrödinger equation for electrons in atoms. It is not some branding teams' genius design innovation.
Ironically, you are in a superstate between "can" and "should".
It is _also_ a colorful collection of boxes that a billion+ people could instantly identify.
Cashing in on that global cultural awareness is just the kind of innovation a genius branding team needs.
It does annoy me when 'Periodic Tables of X' are just lists of color coded boxes, but I get it.
The problem - and it is a problem - is that this is not a good thing.
A billion+ people instantly identify police, but dressing like a cop is a crime.
FWIW, there are other styles which emphasise other aspects. https://en.wikipedia.org/wiki/Types_of_periodic_tables
Totally fair.. I am not claiming periodicity here :) I just wanted to use the "periodic table" as a visual metaphor. The goal is to outline a mostly orthogonal set of system design principles and illustrate cross-domain connections to students so that it is easier to compare trade-offs and discuss designs more precisely.
You keep doing you. It's a losing battle on my end. There will still be more Periodic Table of X on the internet after I've stopped yelling at clouds.
:)
Right, I'm thinking --- if you put it on a grid are there properties on rows? or columns?
If not, eeehhh
I wouldn't even call it a taxonomy. "A list organized into sections".
But that sounds far less grand...
Yes :)
A periodic table with no table and no periodicity.
Wouldn’t “Elements of System Design” have worked?
Yes, I just borrowed the periodic table metaphor. "Elements of System Design" is a better name.
[dead]
Forked