Stop Writing Code in a Bubble
Why understanding system design in 2026 matters more than ever, even if you're not building at scale yet
You can write perfect code and still build a system that collapses under load.
Back in 2010, I was building my first cloud-based distributed system. Cloud computing was just becoming mainstream, and I was responsible for global infrastructure that needed to work across regions. The moment everything clicked for me wasn’t when I wrote cleaner functions or optimized algorithms. It was when I deep-dived into the actual architecture of cloud systems and realized how much more accessible everything became once I understood the bigger picture.
Here’s what I wish I knew then: System design isn’t something you learn when you become a senior engineer. It’s something you should start learning from day one.
Today, I’m working on a startup. We’re not implementing most of these patterns yet. We don’t need Kafka streaming or multi-region replication or serverless at Meta’s scale. But understanding these systems still shapes every technical decision I make. It’s the difference between building something that works today and building something that can scale tomorrow without a complete rewrite.
The Mistakes I Made (So You Don’t Have To)
Early in my career, I wrote code without thinking about system design. I didn’t consider how data would be distributed across nodes. I didn’t plan for CI/CD pipelines. When we faced high I/O latency, I had no mental model for why a queue would solve the problem. I was coding in a vacuum, and it showed when things broke at scale.
The difference between a junior engineer who stays junior and one who grows fast? The latter learns to think in systems, not just in functions.
What The World’s Biggest Systems Teach Us About Design
If you study how the world’s biggest platforms work, you’ll notice patterns. These aren’t random architectural decisions, they’re battle-tested solutions to universal problems. Here’s what 2026 should be about: learning these patterns so you can apply them before you hit the wall.
The Foundation: Event-Driven Architecture
Start with Kafka and Slack. These systems teach you how to handle real-time data and communication at scale. When I built an ad network system years later, Kafka became the backbone, streaming events to handle high I/O throughput without choking. Real-time chat features like Slack (which I later implemented in my recent project) only make sense once you understand event streams, message queues, and how to decouple services so they don’t all fail together.
The lesson: asynchronous communication is not optional at scale, it’s the only way systems survive.
The Scale Layer: When “Good Enough” becomes “Not Even Close”
Then you move up to systems like YouTube, Meta, and Uber, where the numbers stop making sense.
YouTube supports 2.49 billion users on MySQL. Not some fancy distributed database, MySQL. How? Sharding, caching layers, read replicas, and a refusal to over-engineer early. They scaled vertically first, then horizontally, and only switched databases when absolutely necessary.
Meta handled 11.5 million serverless function calls per second. Think about that, per second. They do it with aggressive caching, edge computing, and a system architecture that assumes failure and plans for it.
Uber processes 1 million geo-matching requests per second to find nearby drivers. The trick isn’t magic, it’s geospatial indexing, sharding by location, and reducing latency at every layer.
The lesson: scale isn’t about one clever trick, it’s about making smart tradeoffs at every level of the stack.
The Storage Layer: Durability, Cost, and Retrieval
Look at AWS S3 and Google Docs. S3 is the backbone of the internet’s storage, designed for 99.999999999% durability. That’s eleven nines. It achieves this through replication, erasure coding, and lifecycle policies that automatically move cold data to cheaper storage. When I implemented S3 for data storage with lifecycle management, it cut costs by 60% without sacrificing reliability.
Google Docs handles real-time collaboration for millions of users simultaneously. Operational transformation, conflict resolution, and sync engines that reconcile edits in milliseconds. It’s not just about storing documents, it’s about making the system feel instant even when users are editing from opposite sides of the planet.
The lesson: how you store data determines how you retrieve it, and both determine your cost and reliability.
The Intelligence Layer: LLMs and Modern Compute
Finally, LLMs like ChatGPT teach us about compute-intensive workloads. Inference at scale requires GPUs, batching, prompt caching, and model optimization. The architecture isn’t about databases or queues, it’s about managing compute as efficiently as possible while keeping latency low enough for users to not notice.
The lesson: the next decade of system design will be shaped by AI workloads, and engineers who understand this early will build better products.
Why This Matters for You Right Now
You might be thinking, “I’m not building YouTube. Why do I need to know this?”
Because every product eventually faces scale. And if you don’t understand how distributed systems work, you’ll make decisions that box you in. You’ll pick the wrong database. You’ll build APIs that can’t handle traffic. You’ll design features that work perfectly for 100 users and collapse at 10,000.
I’ve seen engineers who can build beautiful features but can’t explain why their service crashes under load. I’ve seen teams rewrite entire systems because no one thought about data consistency when they started. The cost of learning system design late is rebuilding what you already built.
The benefit of learning it early is that you make better decisions from the start. You ask better questions in design reviews. You propose solutions that scale. You stop being the engineer who just writes tickets and become the engineer who shapes the system.
Where to Start in 2026
Pick three of these case studies and go deep. Not surface-level, actually deep. Understand the tradeoffs. Draw the architecture. Explain it to someone. Then look at the system you’re currently building and ask: what patterns apply here?
For me, understanding Kafka’s event streaming unlocked ad networks. Understanding S3’s storage tiers unlocked cost efficiency. Understanding real-time sync unlocked better chat features. The systems you study today shape the systems you build tomorrow.
System design isn’t gatekept knowledge for staff engineers. It’s the mental model that separates engineers who see code from engineers who see systems. And 2026 is the year you start seeing systems.
If you're looking for guidance on navigating your engineering career or thinking through technical decisions, feel free to reach out. I work with engineers who want to level up their system thinking and career trajectory. You can contact me at irwan@macrostack.dev
MacroStack is where good engineers become great. If you want to think bigger and build better, this is where you belong.