Why I'm Doing This
I've been writing code professionally for a while now, but there's a gap in my knowledge that keeps showing up in interviews and in my own projects: system design. I can build a feature, ship an API, write clean code — but ask me to design something that needs to handle millions of users, and I start hand-waving.
So I'm giving myself 30 days to fix that. This is Day 1 of a series where I'll document what I learn, the mistakes I make, and the "aha" moments along the way. If you're on a similar journey, follow along — maybe we can learn together.
What Even Is System Design?
At its core, system design is about answering one question: how do you build software that works reliably at scale?
That means thinking about things like:
- How does data move between a client and a server?
- What happens when one server isn't enough?
- How do you keep data consistent across multiple machines?
- What breaks first when traffic spikes 100x?
- How do you design for failure, not just for the happy path?
It's less about writing code and more about making trade-offs. Every decision in system design — cache vs. no cache, SQL vs. NoSQL, sync vs. async — comes with a cost. Today was about internalizing that mindset shift.
Topics I Covered Today
1. Client-Server Architecture
The absolute foundation. A client sends a request, a server processes it and sends back a response. Simple in theory, but I spent time really understanding the layers involved:
- DNS resolution
- Load balancers
- Application servers
- Databases
Mapping out a basic request lifecycle (browser → DNS → load balancer → server → database → back) made a lot of "why do we need X" questions click into place.
2. Vertical vs. Horizontal Scaling
- Vertical scaling = throwing more resources (CPU, RAM) at a single machine. Simple, but has a ceiling.
- Horizontal scaling = adding more machines. More complex (hello, distributed systems problems), but it's how you actually scale to millions of users.
Key takeaway: almost every large-scale system eventually needs to scale horizontally, and that decision ripples into everything else — session management, data consistency, caching strategy.
3. Latency vs. Throughput
Two terms I always mixed up:
- Latency — how long a single request takes
- Throughput — how many requests you can handle per unit of time
You can optimize for one at the expense of the other. Understanding which one matters more for a given system (e.g., a stock trading platform cares deeply about latency; a batch data pipeline cares more about throughput) is a design decision in itself.
4. The CAP Theorem (just the surface)
I only scratched the surface here, but the core idea stuck: in a distributed system, you can't have perfect Consistency, Availability, and Partition tolerance all at once. Since network partitions are a fact of life, real systems have to choose between prioritizing consistency or availability when a partition happens.
I know I'll be coming back to this one in more depth later in the series.
My Study Approach for These 30 Days
To keep this from turning into passive video-watching, I'm structuring each day like this:
- Learn one core concept (30–45 minutes of reading/videos)
- Sketch it out — diagrams, not just notes. System design is visual.
- Explain it simply — if I can't explain a concept in plain English, I don't actually understand it yet
- Write it down — hence this series
What's Next
Tomorrow I'm diving into databases: SQL vs. NoSQL, when to use each, and how replication and sharding actually work under the hood.
If you've done a deep dive into system design before, I'd love to hear:
- What tripped you up early on?
- Any resources you'd recommend?
- Anything you wish someone had told you on day 1?
Drop a comment below. See you on Day 2.
This is part of a 30-day series on learning system design from scratch. Follow along for the rest of the journey.
Top comments (0)