Distributed Systems Rizzed Me

September 2025

Growing Up Solving Problems

I spent a lot of time solving CCC-style questions and competitive programming problems at the start of my programming journey. It was satisfying in a very specific way seeing my code past all the test cases or finally solving the question after hours of thinking.

That kind of programming shaped how I think. It taught me how to break things down, reason under pressure, and stay calm when a problem looks impossible at first.

But looking at this period, there was something missing.

I wasn’t creating or building anything. When my peers were building products and learning new languages that were being used daily I was there just memorizing complex algoithms I would never probably used again after that specific question.

Discovering “Real” Programming

Eventually, I did what most people do next: I started learning how to build things.

HTML.
CSS.
JavaScript.
React.

Suddenly I could make buttons, pages, layouts, interactions. I could see what I was building. That felt new and exciting at first but strangely, it didn’t hook me the way problem-solving did.

Programming felt… fine.
Interesting, but not magnetic.

I could follow tutorials, build small projects, and understand how things worked — but I didn’t feel obsessed. I wasn’t thinking about it when I wasn’t coding. I wasn’t staying up late just to understand why something worked the way it did.

I thought maybe that’s just what software engineering was like.

Turns out, I was very wrong.

Falling into System Design

Everything changed when I started learning about system design and distributed systems.

Not frameworks.
Not syntax.
But systems.

Suddenly, the questions weren’t:

  • “What’s the right algorithm?”
  • “What’s the cleanest component or syntax for this?”

They were:

  • How does this scale?
  • What happens when this fails?
  • Why does this trade-off exist?
  • How is this even possible at this scale?

I started thinking about things I had taken for granted my whole life.

How does content reach me this fast?
Why is game latency so low even across continents?
How does a system keep working when parts of it are literally failing?

That curiosity hit differently.

Seeing the World Through Systems

Distributed systems made me realize something important:

Software isn’t just code. It’s a model of the real world.

Every system is a collection of compromises.

Consistency vs availability.
Latency vs durability.
Cost vs performance.
Monoliths vs microservices.

There is never a perfect answer, only a decision that fits this context, right now.

And that idea extends far beyond engineering.

Life is full of trade-offs too.

Do I spend time learning this deeply, or ship something quickly and learn later?
Do I optimize for today, or for the future?
Do I say yes to this opportunity, knowing I’m saying no to another?

Why Trade-Offs Fascinate Me

What I love most about system design is that there is no single correct solution.

Two engineers can design the same system differently and both be right as long as they understand and justify their trade-offs.

That’s powerful.

It rewards:

  • clear thinking
  • curiosity
  • humility
  • long-term perspective

It punishes blind optimization and shallow decisions.

Learning about caching strategies, queues, databases, and scaling patterns didn’t just teach me what to do — it taught me how to think.

Learning as a Habit

Lately, I’ve been diving deeper into this world.

I love watching ByteByteGo videos and pausing constantly to ask why.
I’ve started reading Designing Data-Intensive Applications, slowly, intentionally.
I try to recreate real-world systems in small projects, not because I need them, but because I want to understand them.

Every concept feels like opening a door:

  • stateless vs stateful services
  • eventual consistency
  • replication and failure
  • queues smoothing chaos
  • scaling before things break

There’s always more to learn. And somehow, that’s the best part.

Where I’m At Now

Right now, my passion is simple:

I want to build and understand distributed systems.

Not just pass interviews.
Not just follow patterns.
But really understand why the systems around us work — and sometimes don’t.

I don’t think I fell in love with programming because of syntax or frameworks.

I fell in love with it because systems showed me how much thought, creativity, and care goes into making the world quietly work.

And once I saw that, I couldn’t unsee it.

Closing Thought

Distributed systems taught me that perfection doesn’t exist but only trade-offs.

And honestly, that makes both software and life a lot more interesting.