Before the Boxes and Arrows
When people say system design, they usually mean boxes and arrows.
Load balancers. Databases. Caches. Big words.
But when I'm actually designing something, none of that comes first.
What comes first is... fear.
Fear of choosing the wrong thing. Fear that this design won't scale. Fear that someone smarter will look at it and think, "why did he do it like this?"
So I overthink.
I try to design for a million users that don't exist yet. I add abstractions I don't need. I prepare for failures that might never happen.
And the system becomes heavy before it even lives.
What I've slowly learned is this:
System design is more about psychology than architecture.
Most bad designs don't come from lack of knowledge. They come from insecurity.
We design for judgment, not for reality.
Good system design feels almost boring. Simple. Obvious. Slightly underwhelming.
And that scares us. Because simple looks easy, and easy looks dumb.
But simple is honest.
Every good system I've seen started small.
One clear responsibility. One clear flow. No ego.
You don't design systems by proving how much you know. You design them by respecting how little you actually need.
I've seen engineers spend weeks building the "right" architecture. Microservices everywhere. Event queues for everything. Kubernetes before the first user.
And then the startup dies. Not because the tech was bad. Because no one ever used it.
Meanwhile, some dude with a Next.js app and a single Postgres database shipped something that actually worked. Ugly code. No fancy patterns. Just... working software.
That taught me something I don't think I fully understood before:
Shipping beats designing. Every time.
Now when I design something, I ask myself one question first:
"What is the least smart version of this that still works?"
If it survives that, it can grow later.
I don't reach for Redis until the database is actually slow. I don't add a queue until I actually need async processing. I don't split services until one of them genuinely needs to scale independently.
And honestly? Most of the time, I never reach that point.
The simplest version is usually the final version.
Most systems don't fail because they can't scale.
They fail because they were never allowed to be simple.
So if you're sitting there, stressing about whether your architecture is "good enough", maybe take a breath.
Ask yourself what's the dumbest possible thing that would work.
Build that.
See if anyone cares.
Then worry about the boxes and arrows.