16 Dec 2025
Hey devs,
It’s been almost three months since my last blog post, and no, I didn’t disappear or lose interest. I was very much on track, just not writing. In these past months, I learned a lot, made mistakes, fixed things, and honestly faced a few realities of building software that you only understand by doing.
That phase pushed me to step back from writing and focus on learning and building. Now that things are clearer, I’m back here to document that journey properly. From now on, I’ll try to post at least once every week, and this system design series is where I’m starting and also I will continue my design pattern series.
If you’ve been building software for a while, you’ve probably noticed this. Writing code is only half the job. The real challenge starts when your application grows, traffic increases, and small decisions begin to have big consequences.
That’s where system design comes in.
When I first started learning system design, I thought it was something you study just for interviews. Whiteboards, boxes, arrows, and fancy terms. But the more real projects I worked on, the more I realized this is not an interview skill. It’s a daily developer skill.
System design is what helps you turn requirements into systems that actually survive in production.
The problem I faced while learning system design.
Most resources either
You read about a concept, understand it at a high level, but when it’s time to apply it in a real project, things feel blurry.
That gap is exactly what pushed me to start this series.
This system design series is not about memorizing definitions or drawing random diagrams.
For every system design concept or pattern, I’ll break it down in three layers
1. A real-world problem
Before jumping into tech, we’ll start with a relatable real-world scenario. Something you already understand intuitively. This helps build the right mental model instead of forcing abstraction from day one.
2. A generic cloud architecture
Next, we’ll translate that real-world idea into a generic cloud setup. No AWS. No Azure. No GCP. Just pure system design thinking. Components, responsibilities, and data flow.
This step is important because it teaches you how to think, not what to memorize.
3. Mapping it to AWS, GCP, and Azure
Only after the concept is clear, we’ll map the same design to
You’ll see how the same idea shows up with different service names, but identical fundamentals. Once you see this a few times, cloud stops feeling overwhelming.
This approach does three important things
Instead of thinking
“I don’t know this AWS service”
You start thinking
“Oh, this is just caching, scaling, or async processing”
That shift is powerful.
This series is for
If you’ve ever looked at a system diagram and thought, “I get the idea, but I wouldn’t know how to build this”, this series is for you.
I’m learning system design the same way I learn everything else
This blog is my learning log. I’m writing to understand things better, and if it helps you along the way, that’s a win.
System design is not about knowing every service or every pattern. It’s about understanding how systems behave under load, failure, and growth.
In this series, we’ll focus on why a design exists, how it works in principle, and how it looks in the real world across AWS, GCP, and Azure.
If that sounds useful to you, stick around.
This is going to be a fun one.
Stay curious.
Let’s build better systems.